linux-stable.git/fs, branch v3.0.8

hfsplus: Fix kfree of wrong pointers in hfsplus_fill_super() error path

2011-10-25T05:10:17+00:00

commit f588c960fcaa6fa8bf82930bb819c9aca4eb9347 upstream.

Commit 6596528e391a ("hfsplus: ensure bio requests are not smaller than
the hardware sectors") changed the pointers used for volume header
allocations but failed to free the correct pointers in the error path
path of hfsplus_fill_super() and hfsplus_read_wrapper.

The second hunk came from a separate patch by Pavel Ivanov.

Reported-by: Pavel Ivanov 
Signed-off-by: Seth Forshee 
Signed-off-by: Christoph Hellwig 
Signed-off-by: Linus Torvalds 
Signed-off-by: Greg Kroah-Hartman

xfs: revert to using a kthread for AIL pushing

2011-10-25T05:10:16+00:00

commit 0030807c66f058230bcb20d2573bcaf28852e804 upstream

Currently we have a few issues with the way the workqueue code is used to
implement AIL pushing:

 - it accidentally uses the same workqueue as the syncer action, and thus
   can be prevented from running if there are enough sync actions active
   in the system.
 - it doesn't use the HIGHPRI flag to queue at the head of the queue of
   work items

At this point I'm not confident enough in getting all the workqueue flags and
tweaks right to provide a perfectly reliable execution context for AIL
pushing, which is the most important piece in XFS to make forward progress
when the log fills.

Revert back to use a kthread per filesystem which fixes all the above issues
at the cost of having a task struct and stack around for each mounted
filesystem.  In addition this also gives us much better ways to diagnose
any issues involving hung AIL pushing and removes a small amount of code.

Signed-off-by: Christoph Hellwig 
Reported-by: Stefan Priebe 
Tested-by: Stefan Priebe 
Signed-off-by: Greg Kroah-Hartman

xfs: force the log if we encounter pinned buffers in .iop_pushbuf

2011-10-25T05:10:16+00:00

commit 17b38471c3c07a49f0bbc2ecc2e92050c164e226 upstream

We need to check for pinned buffers even in .iop_pushbuf given that inode
items flush into the same buffers that may be pinned directly due operations
on the unlinked inode list operating directly on buffers.  To do this add a
return value to .iop_pushbuf that tells the AIL push about this and use
the existing log force mechanisms to unpin it.

Signed-off-by: Christoph Hellwig 
Reported-by: Stefan Priebe 
Tested-by: Stefan Priebe 
Signed-off-by: Greg Kroah-Hartman

xfs: do not update xa_last_pushed_lsn for locked items

2011-10-25T05:10:16+00:00

commit bc6e588a8971aa74c02e42db4d6e0248679f3738 upstream

If an item was locked we should not update xa_last_pushed_lsn and thus skip
it when restarting the AIL scan as we need to be able to lock and write it
out as soon as possible.  Otherwise heavy lock contention might starve AIL
pushing too easily, especially given the larger backoff once we moved
xa_last_pushed_lsn all the way to the target lsn.

Signed-off-by: Christoph Hellwig 
Reported-by: Stefan Priebe 
Tested-by: Stefan Priebe 
Signed-off-by: Greg Kroah-Hartman

xfs: use a cursor for bulk AIL insertion

2011-10-25T05:10:16+00:00

commit 1d8c95a363bf8cd4d4182dd19c01693b635311c2 upstream


xfs: use a cursor for bulk AIL insertion

Delayed logging can insert tens of thousands of log items into the
AIL at the same LSN. When the committing of log commit records
occur, we can get insertions occurring at an LSN that is not at the
end of the AIL. If there are thousands of items in the AIL on the
tail LSN, each insertion has to walk the AIL to find the correct
place to insert the new item into the AIL. This can consume large
amounts of CPU time and block other operations from occurring while
the traversals are in progress.

To avoid this repeated walk, use a AIL cursor to record
where we should be inserting the new items into the AIL without
having to repeat the walk. The cursor infrastructure already
provides this functionality for push walks, so is a simple extension
of existing code. While this will not avoid the initial walk, it
will avoid repeating it tens of thousands of times during a single
checkpoint commit.

This version includes logic improvements from Christoph Hellwig.

Signed-off-by: Dave Chinner 
Reviewed-by: Christoph Hellwig 
Signed-off-by: Alex Elder 
Signed-off-by: Greg Kroah-Hartman

xfs: start periodic workers later

2011-10-25T05:10:15+00:00

commit 2bcf6e970f5a88fa05dced5eeb0326e13d93c4a1 upstream

Start the periodic sync workers only after we have finished xfs_mountfs
and thus fully set up the filesystem structures.  Without this we can
call into xfs_qm_sync before the quotainfo strucute is set up if the
mount takes unusually long, and probably hit other incomplete states
as well.

Also clean up the xfs_fs_fill_super error path by using consistent
label names, and removing an impossible to reach case.

Signed-off-by: Christoph Hellwig 
Reported-by: Arkadiusz Miskiewicz 
Reviewed-by: Alex Elder 
Signed-off-by: Greg Kroah-Hartman

CIFS: Fix ERR_PTR dereference in cifs_get_root

2011-10-25T05:10:15+00:00

commit 5b980b01212199833ee8023770fa4cbf1b85e9f4 upstream.

move it to the beginning of the loop.

Signed-off-by: Pavel Shilovsky 
Reviewed-by: Jeff Layton 
Signed-off-by: Steve French 
Cc: Josh Boyer 
Signed-off-by: Greg Kroah-Hartman

hfsplus: ensure bio requests are not smaller than the hardware sectors

2011-10-25T05:10:15+00:00

commit 6596528e391ad978a6a120142cba97a1d7324cb6 upstream.

Currently all bio requests are 512 bytes, which may fail for media
whose physical sector size is larger than this. Ensure these
requests are not smaller than the block device logical block size.

BugLink: http://bugs.launchpad.net/bugs/734883
Signed-off-by: Seth Forshee 
Signed-off-by: Christoph Hellwig 
Cc: Josh Boyer 
Signed-off-by: Greg Kroah-Hartman

fuse: fix memory leak

2011-10-25T05:10:14+00:00

commit 5dfcc87fd79dfb96ed155b524337dbd0da4f5993 upstream.

kmemleak is reporting that 32 bytes are being leaked by FUSE:

  unreferenced object 0xe373b270 (size 32):
  comm "fusermount", pid 1207, jiffies 4294707026 (age 2675.187s)
  hex dump (first 32 bytes):
    01 00 00 00 00 00 00 00 01 00 00 00 00 00 00 00  ................
    00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
  backtrace:
    [] kmemleak_alloc+0x27/0x50
    [] kmem_cache_alloc+0xc5/0x180
    [] fuse_alloc_forget+0x1e/0x20
    [] fuse_alloc_inode+0xb0/0xd0
    [] alloc_inode+0x1c/0x80
    [] iget5_locked+0x8f/0x1a0
    [] fuse_iget+0x72/0x1a0
    [] fuse_get_root_inode+0x8a/0x90
    [] fuse_fill_super+0x3ef/0x590
    [] mount_nodev+0x3f/0x90
    [] fuse_mount+0x15/0x20
    [] mount_fs+0x1c/0xc0
    [] vfs_kern_mount+0x41/0x90
    [] do_kern_mount+0x39/0xd0
    [] do_mount+0x2e5/0x660
    [] sys_mount+0x66/0xa0

This leak report is consistent and happens once per boot on
3.1.0-rc5-dirty.

This happens if a FORGET request is queued after the fuse device was
released.

Reported-by: Sitsofe Wheeler 
Signed-off-by: Miklos Szeredi 
Tested-by: Sitsofe Wheeler 
Signed-off-by: Linus Torvalds 
Cc: Josh Boyer 
Signed-off-by: Greg Kroah-Hartman

exec: do not call request_module() twice from search_binary_handler()

2011-10-16T21:14:54+00:00

commit 912193521b719fbfc2f16776febf5232fe8ba261 upstream.

Currently, search_binary_handler() tries to load binary loader module
using request_module() if a loader for the requested program is not yet
loaded.  But second attempt of request_module() does not affect the result
of search_binary_handler().

If request_module() triggered recursion, calling request_module() twice
causes 2 to the power of MAX_KMOD_CONCURRENT (= 50) repetitions.  It is
not an infinite loop but is sufficient for users to consider as a hang up.

Therefore, this patch changes not to call request_module() twice, making 1
to the power of MAX_KMOD_CONCURRENT repetitions in case of recursion.

Signed-off-by: Tetsuo Handa 
Reported-by: Richard Weinberger 
Tested-by: Richard Weinberger 
Cc: Al Viro 
Signed-off-by: Andrew Morton 
Cc: Maxim Uvarov 
Signed-off-by: Linus Torvalds