1. 08 Nov, 2013 8 commits
  2. 07 Nov, 2013 1 commit
  3. 06 Nov, 2013 1 commit
    • Oskar Schirmer's avatar
      ASoC: fsl: imx-pcm-fiq: remove bogus period delta calculation · 68f9672b
      Oskar Schirmer authored
      Originally snd_hrtimer_callback() used iprtd->period_time for
      some jiffies based estimation to determine the right moment
      to call snd_pcm_period_elapsed(). As timer drifts may well be a
      problem, this was changed in commit b4e82b5b to be based
      on buffer transmission progress, using iprtd->offset and
      runtime->buffer_size to calculate the amount of data since last
      period had elapsed.
      
      Unfortunately, iprtd->offset counts in bytes, while
      runtime->buffer_size counts frames, so adding these to find some
      delta is like comparing apples and oranges, and eventually results
      in negative delta values every now and then. This is no big harm,
      because it simply causes snd_pcm_period_elapsed() being called
      more often than necessary, as negative delta is taken for a
      large unsigned value by implicit conversion rule.
      Nonetheless, the calculation is broken, so one would replace
      the runtime->buffer_size by its equivalent in bytes.
      
      But then, there are chances snd_pcm_period_elapsed() is called
      late, because calculating the moment for the elapsed period
      into delta is based against the iprtd->last_offset, which is not
      necessarily the first byte of the period in question, but some
      random byte which the FIQ handler left us with in r8/r9 by
      accident. Again, negative impact is low, as there are plenty of
      periods already prefilled with data, and snd_pcm_period_elapsed()
      will probably be called latest when the following period is
      reached. However, the calculation is conceptually broken, and we
      are best off removing the clever stuff altogether.
      
      snd_pcm_period_elapsed() is now simply called once everytime
      snd_hrtimer_callback() is run, which may not be most accurate,
      but at least this way we are quite sure we dont miss an end of
      period. There is not much extra effort wasted by superfluous
      calls to snd_pcm_period_elapsed(), as the timer frequency
      closely matches the period size anyway.
      Signed-off-by: default avatarOskar Schirmer <oskar@scara.com>
      Signed-off-by: default avatarMark Brown <broonie@linaro.org>
      68f9672b
  4. 04 Nov, 2013 1 commit
  5. 03 Nov, 2013 3 commits
  6. 02 Nov, 2013 2 commits
  7. 01 Nov, 2013 21 commits
  8. 31 Oct, 2013 3 commits
    • Linus Torvalds's avatar
      Merge branch 'akpm' (fixes from Andrew Morton) · 4f794ee8
      Linus Torvalds authored
      Merge four more fixes from Andrew Morton.
      
      * emailed patches from Andrew Morton <akpm@linux-foundation.org>:
        lib/scatterlist.c: don't flush_kernel_dcache_page on slab page
        mm: memcg: fix test for child groups
        mm: memcg: lockdep annotation for memcg OOM lock
        mm: memcg: use proper memcg in limit bypass
      4f794ee8
    • Ming Lei's avatar
      lib/scatterlist.c: don't flush_kernel_dcache_page on slab page · 3d77b50c
      Ming Lei authored
      Commit b1adaf65 ("[SCSI] block: add sg buffer copy helper
      functions") introduces two sg buffer copy helpers, and calls
      flush_kernel_dcache_page() on pages in SG list after these pages are
      written to.
      
      Unfortunately, the commit may introduce a potential bug:
      
       - Before sending some SCSI commands, kmalloc() buffer may be passed to
         block layper, so flush_kernel_dcache_page() can see a slab page
         finally
      
       - According to cachetlb.txt, flush_kernel_dcache_page() is only called
         on "a user page", which surely can't be a slab page.
      
       - ARCH's implementation of flush_kernel_dcache_page() may use page
         mapping information to do optimization so page_mapping() will see the
         slab page, then VM_BUG_ON() is triggered.
      
      Aaro Koskinen reported the bug on ARM/kirkwood when DEBUG_VM is enabled,
      and this patch fixes the bug by adding test of '!PageSlab(miter->page)'
      before calling flush_kernel_dcache_page().
      Signed-off-by: default avatarMing Lei <ming.lei@canonical.com>
      Reported-by: default avatarAaro Koskinen <aaro.koskinen@iki.fi>
      Tested-by: default avatarSimon Baatz <gmbnomis@gmail.com>
      Cc: Russell King - ARM Linux <linux@arm.linux.org.uk>
      Cc: Will Deacon <will.deacon@arm.com>
      Cc: Aaro Koskinen <aaro.koskinen@iki.fi>
      Acked-by: default avatarCatalin Marinas <catalin.marinas@arm.com>
      Cc: FUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp>
      Cc: Tejun Heo <tj@kernel.org>
      Cc: "James E.J. Bottomley" <JBottomley@parallels.com>
      Cc: Jens Axboe <axboe@kernel.dk>
      Cc: <stable@vger.kernel.org>	[3.2+]
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      3d77b50c
    • Johannes Weiner's avatar
      mm: memcg: fix test for child groups · 696ac172
      Johannes Weiner authored
      When memcg code needs to know whether any given memcg has children, it
      uses the cgroup child iteration primitives and returns true/false
      depending on whether the iteration loop is executed at least once or
      not.
      
      Because a cgroup's list of children is RCU protected, these primitives
      require the RCU read-lock to be held, which is not the case for all
      memcg callers.  This results in the following splat when e.g.  enabling
      hierarchy mode:
      
        WARNING: CPU: 3 PID: 1 at kernel/cgroup.c:3043 css_next_child+0xa3/0x160()
        CPU: 3 PID: 1 Comm: systemd Not tainted 3.12.0-rc5-00117-g83f11a9c-dirty #18
        Hardware name: LENOVO 3680B56/3680B56, BIOS 6QET69WW (1.39 ) 04/26/2012
        Call Trace:
          dump_stack+0x54/0x74
          warn_slowpath_common+0x78/0xa0
          warn_slowpath_null+0x1a/0x20
          css_next_child+0xa3/0x160
          mem_cgroup_hierarchy_write+0x5b/0xa0
          cgroup_file_write+0x108/0x2a0
          vfs_write+0xbd/0x1e0
          SyS_write+0x4c/0xa0
          system_call_fastpath+0x16/0x1b
      
      In the memcg case, we only care about children when we are attempting to
      modify inheritable attributes interactively.  Racing with deletion could
      mean a spurious -EBUSY, no problem.  Racing with addition is handled
      just fine as well through the memcg_create_mutex: if the child group is
      not on the list after the mutex is acquired, it won't be initialized
      from the parent's attributes until after the unlock.
      Signed-off-by: default avatarJohannes Weiner <hannes@cmpxchg.org>
      Acked-by: default avatarMichal Hocko <mhocko@suse.cz>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      696ac172