Skip to content

L
linux
Switch branch/tag
  1. 01 Oct, 2010 1 commit
    • Ira W. Snyder's avatar
      kfifo: fix scatterlist usage · 399f1e30
      Ira W. Snyder authored 
      The kfifo_dma family of functions use sg_mark_end() on the last element in
their scatterlist.  This forces use of a fresh scatterlist for each DMA
operation, which makes recycling a single scatterlist impossible.

Change the behavior of the kfifo_dma functions to match the usage of the
dma_map_sg function.  This means that users must respect the returned
nents value.  The sample code is updated to reflect the change.

This bug is trivial to cause: call kfifo_dma_in_prepare() such that it
prepares a scatterlist with a single entry comprising the whole fifo.
This is the case when you map the entirety of a newly created empty fifo.
This causes the setup_sgl() function to mark the first scatterlist entry
as the end of the chain, no matter what comes after it.

Afterwards, add and remove some data from the fifo such that another call
to kfifo_dma_in_prepare() will create two scatterlist entries.  It returns
nents=2.  However, due to the previous sg_mark_end() call, sg_is_last()
will now return true for the first scatterlist element.  This causes the
sample code to print a single scatterlist element when it should print
two.

By removing the call to sg_mark_end(), we make the API as similar as
possible to the DMA mapping API.  All users are required to respect the
returned nents.
Signed-off-by: default avatarIra W. Snyder <iws@ovro.caltech.edu>
Cc: Stefani Seibold <stefani@seibold.net>
Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      399f1e30
  3. 30 Sep, 2010 4 commits
  5. 29 Sep, 2010 8 commits
    • Linus Torvalds's avatar
      Merge branch 'for-linus' of git://oss.sgi.com/xfs/xfs · 4193d916
      Linus Torvalds authored 
      * 'for-linus' of git://oss.sgi.com/xfs/xfs:
  xfs: force background CIL push under sustained load
      4193d916
    • Linus Torvalds's avatar
      Merge branch 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/sameo/mfd-2.6 · 9d457c60
      Linus Torvalds authored 
      * 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/sameo/mfd-2.6:
  mfd: Fix max8925 irq control bit incorrect setting
  mfd: Ignore non-GPIO IRQs when setting wm831x IRQ types
      9d457c60
    • Daniel J Blueman's avatar
      fix OMAP2 MTD build failure · f12f662f
      Daniel J Blueman authored 
      Fix build failure from recent interface change and merge.

Tested on OMAP3430.
Signed-off-by: default avatarDaniel J Blueman <daniel.blueman@gmail.com>
Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      f12f662f
    • Dave Chinner's avatar
      xfs: force background CIL push under sustained load · 80168676
      Dave Chinner authored 
      I have been seeing occasional pauses in transaction throughput up to
30s long under heavy parallel workloads. The only notable thing was
that the xfsaild was trying to be active during the pauses, but
making no progress. It was running exactly 20 times a second (on the
50ms no-progress backoff), and the number of pushbuf events was
constant across this time as well.  IOWs, the xfsaild appeared to be
stuck on buffers that it could not push out.

Further investigation indicated that it was trying to push out inode
buffers that were pinned and/or locked. The xfsbufd was also getting
woken at the same frequency (by the xfsaild, no doubt) to push out
delayed write buffers. The xfsbufd was not making any progress
because all the buffers in the delwri queue were pinned. This scan-
and-make-no-progress dance went one in the trace for some seconds,
before the xfssyncd came along an issued a log force, and then
things started going again.

However, I noticed something strange about the log force - there
were way too many IO's issued. 516 log buffers were written, to be
exact. That added up to 129MB of log IO, which got me very
interested because it's almost exactly 25% of the size of the log.
He delayed logging code is suppose to aggregate the minimum of 25%
of the log or 8MB worth of changes before flushing. That's what
really puzzled me - why did a log force write 129MB instead of only
8MB?

Essentially what has happened is that no CIL pushes had occurred
since the previous tail push which cleared out 25% of the log space.
That caused all the new transactions to block because there wasn't
log space for them, but they kick the xfsaild to push the tail.
However, the xfsaild was not making progress because there were
buffers it could not lock and flush, and the xfsbufd could not flush
them because they were pinned. As a result, both the xfsaild and the
xfsbufd could not move the tail of the log forward without the CIL
first committing.

The cause of the problem was that the background CIL push, which
should happen when 8MB of aggregated changes have been committed, is
being held off by the concurrent transaction commit load. The
background push does a down_write_trylock() which will fail if there
is a concurrent transaction commit holding the push lock in read
mode. With 8 CPUs all doing transactions as fast as they can, there
was enough concurrent transaction commits to hold off the background
push until tail-pushing could no longer free log space, and the halt
would occur.

It should be noted that there is no reason why it would halt at 25%
of log space used by a single CIL checkpoint. This bug could
definitely violate the "no transaction should be larger than half
the log" requirement and hence result in corruption if the system
crashed under heavy load. This sort of bug is exactly the reason why
delayed logging was tagged as experimental....

The fix is to start blocking background pushes once the threshold
has been exceeded. Rework the threshold calculations to keep the
amount of log space a CIL checkpoint can use to below that of the
AIL push threshold to avoid the problem completely.
Signed-off-by: default avatarDave Chinner <dchinner@redhat.com>
Reviewed-by: default avatarAlex Elder <aelder@sgi.com>
Reviewed-by: default avatarChristoph Hellwig <hch@lst.de>
      80168676
    • Kevin Liu's avatar
      mfd: Fix max8925 irq control bit incorrect setting · 90182317
      Kevin Liu authored 
      In max8925_irq_sync_unlock(), irq control bit is set at the same time.
Zero means enabling irq, and one means disabling irq.

The original code is:
	irq_chg[0] &= irq_data->enable;

It should be changed to:
	irq_chg[0] &= ~irq_data->enable;

Otherwise, irq control bit is mess.
Signed-off-by: default avatarKevin Liu <kliu5@marvell.com>
Signed-off-by: default avatarHaojian Zhuang <haojian.zhuang@marvell.com>
Signed-off-by: default avatarSamuel Ortiz <sameo@linux.intel.com>
      90182317
    • Mark Brown's avatar
      mfd: Ignore non-GPIO IRQs when setting wm831x IRQ types · c9d66d35
      Mark Brown authored 
      The driver was originally tested with an additional patch which
made this unneeded but that patch had issuges and got lost on the
way to mainline, causing problems when the errors are reported.
Signed-off-by: default avatarMark Brown <broonie@opensource.wolfsonmicro.com>
Signed-off-by: default avatarSamuel Ortiz <sameo@linux.intel.com>
Cc: stable@kernel.org
      c9d66d35
    • Linus Torvalds's avatar
      Linux 2.6.36-rc6 · 899611ee
      Linus Torvalds authored
      899611ee
    • David Howells's avatar
      MN10300: Handle missing sys_cacheflush() when caching disabled · 62bdb288
      David Howells authored 
      When caching is disabled on the MN10300 arch, the sys_cacheflush()
function is removed by conditional stuff in the makefiles, but is still
referred to by the syscall table.

Provide a null version that just returns 0 when caching is disabled (or
-EINVAL if the arguments are silly).
Signed-off-by: default avatarDavid Howells <dhowells@redhat.com>
Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      62bdb288
  7. 28 Sep, 2010 9 commits
  9. 27 Sep, 2010 18 commits
GitLab Nexedi Edition | About GitLab | About Nexedi | 沪ICP备2021021310号-2 | 沪ICP备2021021310号-7