linux-toradex.git/fs, branch v2.6.33.5

nilfs2: fix sync silent failure

2010-05-26T21:32:12+00:00

commit 973bec34bfc1bc2465646181653d67f767d418c8 upstream.

As of 32a88aa1, __sync_filesystem() will return 0 if s_bdi is not set.
And nilfs does not set s_bdi anywhere.  I noticed this problem by the
warning introduced by the recent commit 5129a469 ("Catch filesystem
lacking s_bdi").

 WARNING: at fs/super.c:959 vfs_kern_mount+0xc5/0x14e()
 Hardware name: PowerEdge 2850
 Modules linked in: nilfs2 loop tpm_tis tpm tpm_bios video shpchp pci_hotplug output dcdbas
 Pid: 3773, comm: mount.nilfs2 Not tainted 2.6.34-rc6-debug #38
 Call Trace:
  [] warn_slowpath_common+0x60/0x90
  [] warn_slowpath_null+0xd/0x10
  [] vfs_kern_mount+0xc5/0x14e
  [] do_kern_mount+0x32/0xbd
  [] do_mount+0x671/0x6d0
  [] ? __get_free_pages+0x1f/0x21
  [] ? copy_mount_options+0x2b/0xe2
  [] ? strndup_user+0x48/0x67
  [] sys_mount+0x61/0x8f
  [] sysenter_do_call+0x12/0x32

This ensures to set s_bdi for nilfs and fixes the sync silent failure.

Signed-off-by: Ryusuke Konishi 
Acked-by: Jens Axboe 
Signed-off-by: Linus Torvalds 
Signed-off-by: Greg Kroah-Hartman

CacheFiles: Fix error handling in cachefiles_determine_cache_security()

2010-05-26T21:32:11+00:00

commit 7ac512aa8237c43331ffaf77a4fd8b8d684819ba upstream.

cachefiles_determine_cache_security() is expected to return with a
security override in place.  However, if set_create_files_as() fails, we
fail to do this.  In this case, we should just reinstate the security
override that was set by the caller.

Furthermore, if set_create_files_as() fails, we should dispose of the
new credentials we were in the process of creating.

Signed-off-by: David Howells 
Signed-off-by: Linus Torvalds 
Signed-off-by: Greg Kroah-Hartman

Btrfs: check for read permission on src file in the clone ioctl

2010-05-26T21:32:09+00:00

commit 5dc6416414fb3ec6e2825fd4d20c8bf1d7fe0395 upstream.

The existing code would have allowed you to clone a file that was
only open for writing

Signed-off-by: Chris Mason 
Signed-off-by: Greg Kroah-Hartman

inotify: don't leak user struct on inotify release

2010-05-26T21:32:08+00:00

commit b3b38d842fa367d862b83e7670af4e0fd6a80fc0 upstream.

inotify_new_group() receives a get_uid-ed user_struct and saves the
reference on group->inotify_data.user.  The problem is that free_uid() is
never called on it.

Issue seem to be introduced by 63c882a0 (inotify: reimplement inotify
using fsnotify) after 2.6.30.

Signed-off-by: Pavel Emelyanov 
Eric Paris 
Signed-off-by: Andrew Morton 
Signed-off-by: Eric Paris 
Signed-off-by: Greg Kroah-Hartman

inotify: race use after free/double free in inotify inode marks

2010-05-26T21:32:08+00:00

commit e08733446e72b983fed850fc5d8bd21b386feb29 upstream.

There is a race in the inotify add/rm watch code.  A task can find and
remove a mark which doesn't have all of it's references.  This can
result in a use after free/double free situation.

Task A					Task B
------------				-----------
inotify_new_watch()
 allocate a mark (refcnt == 1)
 add it to the idr
					inotify_rm_watch()
					 inotify_remove_from_idr()
					  fsnotify_put_mark()
					      refcnt hits 0, free
 take reference because we are on idr
 [at this point it is a use after free]
 [time goes on]
 refcnt may hit 0 again, double free

The fix is to take the reference BEFORE the object can be found in the
idr.

Signed-off-by: Eric Paris 
Signed-off-by: Greg Kroah-Hartman

cifs: guard against hardlinking directories

2010-05-26T21:32:07+00:00

commit 3d69438031b00c601c991ab447cafb7d5c3c59a6 upstream.

When we made serverino the default, we trusted that the field sent by the
server in the "uniqueid" field was actually unique. It turns out that it
isn't reliably so.

Samba, in particular, will just put the st_ino in the uniqueid field when
unix extensions are enabled. When a share spans multiple filesystems, it's
quite possible that there will be collisions. This is a server bug, but
when the inodes in question are a directory (as is often the case) and
there is a collision with the root inode of the mount, the result is a
kernel panic on umount.

Fix this by checking explicitly for directory inodes with the same
uniqueid. If that is the case, then we can assume that using server inode
numbers will be a problem and that they should be disabled.

Fixes Samba bugzilla 7407

Signed-off-by: Jeff Layton 
Reviewed-and-Tested-by: Suresh Jayaraman 
Signed-off-by: Steve French 
Signed-off-by: Greg Kroah-Hartman

revert "procfs: provide stack information for threads" and its fixup commits

2010-05-26T21:32:04+00:00

commit 34441427aab4bdb3069a4ffcda69a99357abcb2e upstream.

Originally, commit d899bf7b ("procfs: provide stack information for
threads") attempted to introduce a new feature for showing where the
threadstack was located and how many pages are being utilized by the
stack.

Commit c44972f1 ("procfs: disable per-task stack usage on NOMMU") was
applied to fix the NO_MMU case.

Commit 89240ba0 ("x86, fs: Fix x86 procfs stack information for threads on
64-bit") was applied to fix a bug in ia32 executables being loaded.

Commit 9ebd4eba7 ("procfs: fix /proc//stat stack pointer for kernel
threads") was applied to fix a bug which had kernel threads printing a
userland stack address.

Commit 1306d603f ('proc: partially revert "procfs: provide stack
information for threads"') was then applied to revert the stack pages
being used to solve a significant performance regression.

This patch nearly undoes the effect of all these patches.

The reason for reverting these is it provides an unusable value in
field 28.  For x86_64, a fork will result in the task->stack_start
value being updated to the current user top of stack and not the stack
start address.  This unpredictability of the stack_start value makes
it worthless.  That includes the intended use of showing how much stack
space a thread has.

Other architectures will get different values.  As an example, ia64
gets 0.  The do_fork() and copy_process() functions appear to treat the
stack_start and stack_size parameters as architecture specific.

I only partially reverted c44972f1 ("procfs: disable per-task stack usage
on NOMMU") .  If I had completely reverted it, I would have had to change
mm/Makefile only build pagewalk.o when CONFIG_PROC_PAGE_MONITOR is
configured.  Since I could not test the builds without significant effort,
I decided to not change mm/Makefile.

I only partially reverted 89240ba0 ("x86, fs: Fix x86 procfs stack
information for threads on 64-bit") .  I left the KSTK_ESP() change in
place as that seemed worthwhile.

Signed-off-by: Robin Holt 
Cc: Stefani Seibold 
Cc: KOSAKI Motohiro 
Cc: Michal Simek 
Cc: Ingo Molnar 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds 
Signed-off-by: Greg Kroah-Hartman

xfs: add a shrinker to background inode reclaim

2010-05-12T22:02:53+00:00

commit 9bf729c0af67897ea8498ce17c29b0683f7f2028 upstream

On low memory boxes or those with highmem, kernel can OOM before the
background reclaims inodes via xfssyncd. Add a shrinker to run inode
reclaim so that it inode reclaim is expedited when memory is low.

This is more complex than it needs to be because the VM folk don't
want a context added to the shrinker infrastructure. Hence we need
to add a global list of XFS mount structures so the shrinker can
traverse them.

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

jfs: fix diAllocExt error in resizing filesystem

2010-05-12T22:02:50+00:00

commit 2b0b39517d1af5294128dbc2fd7ed39c8effa540 upstream.

Resizing the filesystem would result in an diAllocExt error in some
instances because changes in bmp->db_agsize would not get noticed if
goto extendBmap was called.

Signed-off-by: Bill Pemberton 
Signed-off-by: Dave Kleikamp 
Cc: jfs-discussion@lists.sourceforge.net
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Greg Kroah-Hartman

ext4: correctly calculate number of blocks for fiemap

2010-05-12T22:02:49+00:00

commit aca92ff6f57c000d1b4523e383c8bd6b8269b8b1 upstream.

ext4_fiemap() rounds the length of the requested range down to
blocksize, which is is not the true number of blocks that cover the
requested region.  This problem is especially impressive if the user
requests only the first byte of a file: not a single extent will be
reported.

We fix this by calculating the last block of the region and then
subtract to find the number of blocks in the extents.

Signed-off-by: Leonard Michlmayr 
Signed-off-by: "Theodore Ts'o" 
Signed-off-by: Greg Kroah-Hartman