kernel/git/stable/linux.git/fs, branch linux-2.6.39.y

proc: restrict access to /proc/PID/io

2011-08-03T19:42:51+00:00

commit 1d1221f375c94ef961ba8574ac4f85c8870ddd51 upstream. /proc/PID/io may be used for gathering private information. E.g. for openssh and vsftpd daemons wchars/rchars may be used to learn the precise password length. Restrict it to processes being able to ptrace the target process. ptrace_may_access() is needed to prevent keeping open file descriptor of "io" file, executing setuid binary and gathering io information of the setuid'ed process. Signed-off-by: Vasiliy Kulikov Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman

FS-Cache: Fix __fscache_uncache_all_inode_pages()'s outer loop

2011-08-03T19:42:50+00:00

commit b307d4655a71749ac3f91c6dbe33d28cc026ceeb upstream. The compiler, at least for ix86 and m68k, validly warns that the comparison: next <= (loff_t)-1 is always true (and it's always true also for x86-64 and probably all other arches - as long as pgoff_t isn't wider than loff_t). The intention appears to be to avoid wrapping of "next", so rather than eliminating the pointless comparison, fix the loop to indeed get exited when "next" would otherwise wrap. On m68k the following warning is observed: fs/fscache/page.c: In function '__fscache_uncache_all_inode_pages': fs/fscache/page.c:979: warning: comparison is always false due to limited range of data type Reported-by: Geert Uytterhoeven Reported-by: Jan Beulich Signed-off-by: Jan Beulich Signed-off-by: David Howells Cc: Suresh Jayaraman Cc: Geert Uytterhoeven Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman

cifs: lower default and max wsize to what 2.6.39 can handle

2011-08-03T19:42:49+00:00

This patch is intended for 2.6.39-stable kernels only and is needed to fix a regression introduced in 2.6.39. Prior to 2.6.39, when signing was enabled on a socket the client only sent single-page writes. This changed with commit ca83ce3, which made signed and unsigned connections use the same codepaths for write calls. This caused a regression when working with windows servers. Windows machines will reject writes larger than the MaxBufferSize when signing is active, but do not clear the CAP_LARGE_WRITE_X flag in the protocol negotiation. The upshot is that when signing is active, windows servers often reject large writes from the client in 2.6.39. Because 3.0 adds support for larger wsize values, simply cherry picking the upstream patches that fix the wsize negotiation isn't sufficient to fix this issue. We also need to alter the maximum and default values to something suitable for 2.6.39. This patch also accounts for the change in field name from sec_mode to secMode that went into 3.0. Signed-off-by: Jeff Layton Signed-off-by: Greg Kroah-Hartman

cifs: fix wsize negotiation to respect max buffer size and active signing (try #4)

2011-08-03T19:42:48+00:00

commit 1190f6a067bf27b2ee7e06ec0776a17fe0f6c4d8 upstream. Hopefully last version. Base signing check on CAP_UNIX instead of tcon->unix_ext, also clean up the comments a bit more. According to Hongwei Sun's blog posting here: http://blogs.msdn.com/b/openspecification/archive/2009/04/10/smb-maximum-transmit-buffer-size-and-performance-tuning.aspx CAP_LARGE_WRITEX is ignored when signing is active. Also, the maximum size for a write without CAP_LARGE_WRITEX should be the maxBuf that the server sent in the NEGOTIATE request. Fix the wsize negotiation to take this into account. While we're at it, alter the other wsize definitions to use sizeof(WRITE_REQ) to allow for slightly larger amounts of data to potentially be written per request. Signed-off-by: Jeff Layton Signed-off-by: Steve French Signed-off-by: Greg Kroah-Hartman

vfs: fix race in rcu lookup of pruned dentry

2011-08-03T19:42:48+00:00

Backport of commit 59430262401bec02d415179c43dbe5b8819c09ce done by Hugh Dickins Don't update *inode in __follow_mount_rcu() until we'd verified that there is mountpoint there. Kudos to Hugh Dickins for catching that one in the first place and eventually figuring out the solution (and catching a braino in the earlier version of patch). Signed-off-by: Linus Torvalds Cc: Hugh Dickins Signed-off-by: Al Viro

cifs: clean up wsize negotiation and allow for larger wsize

2011-08-03T19:42:46+00:00

commit f7910cbd9fa319ee4501074f1f3b5ce23c4b1518 upstream. Now that we can handle larger wsizes in writepages, fix up the negotiation of the wsize to allow for that. find_get_pages only seems to give out a max of 256 pages at a time, so that gives us a reasonable default of 1M for the wsize. If the server however does not support large writes via POSIX extensions, then we cap the wsize to (128k - PAGE_CACHE_SIZE). That gives us a size that goes up to the max frame size specified in RFC1001. Finally, if CAP_LARGE_WRITE_AND_X isn't set, then further cap it to the largest size allowed by the protocol (USHRT_MAX). Signed-off-by: Jeff Layton Reviewed-and-Tested-by: Pavel Shilovsky Signed-off-by: Steve French Signed-off-by: Greg Kroah-Hartman

xfs [stable only]: restart busy extent search after node removal

2011-08-03T19:42:45+00:00

A user on #xfs reported that a log replay was oopsing in __rb_rotate_left() with a null pointer deref, and provided an xfs_metadump image for reproduction and testing. I traced this down to the fact that in xfs_alloc_busy_insert(), we erased a node with rb_erase() when the new node overlapped, but left the erased node specified as the parent node for the new insertion. So when we try to insert a new node with an erased node as its parent, obviously things go very wrong. Upstream, 97d3ac75e5e0ebf7ca38ae74cebd201c09b97ab2 xfs: exact busy extent tracking actually fixed this, but as part of a much larger change. Here's the relevant code from that commit: * We also need to restart the busy extent search from the * tree root, because erasing the node can rearrange the * tree topology. */ rb_erase(&busyp->rb_node, &pag->pagb_tree); busyp->length = 0; return false; We can do essentially the same thing to older codebases by restarting the tree search after the erase. This should apply to .35.y through .39.y, and was tested on .39 with the oopsing replay reproducer. Signed-off-by: Eric Sandeen Reviewed-by: Dave Chinner Reviewed-by: Alex Elder Signed-off-by: Greg Kroah-Hartman

ext4: fix oops in ext4_quota_off()

2011-08-03T19:42:43+00:00

commit 0b26859027ce0005ef89520af20351360e51ad76 upstream. If quota is not enabled when ext4_quota_off() is called, we must not dereference quota file inode since it is NULL. Check properly for this. This fixes a bug in commit 21f976975cbe (ext4: remove unnecessary [cm]time update of quota file), which was merged for 2.6.39-rc3. Reported-by: Amir Goldstein Signed-off-by: Amir Goldstein Signed-off-by: Jan Kara Signed-off-by: "Theodore Ts'o" Cc: Chris Dunlop Signed-off-by: Greg Kroah-Hartman

GFS2: make sure fallocate bytes is a multiple of blksize

2011-08-03T19:42:38+00:00

commit 6905d9e4dda6112f007e9090bca80507da158e63 upstream. The GFS2 fallocate code chooses a target size to for allocating chunks of space. Whenever it can't find any resource groups with enough space free, it halves its target. Since this target is in bytes, eventually it will no longer be a multiple of blksize. As long as there is more space available in the resource group than the target, this isn't a problem, since gfs2 will use the actual space available, which is always a multiple of blksize. However, when gfs couldn't fallocate a bigger chunk than the target, it was using the non-blksize aligned number. This caused a BUG in later code that required blksize aligned offsets. GFS2 now ensures that bytes is always a multiple of blksize Signed-off-by: Benjamin Marzinski Signed-off-by: Steven Whitehouse Signed-off-by: Greg Kroah-Hartman

NFSv4.1: update nfs4_fattr_bitmap_maxsz

2011-08-03T19:42:33+00:00

commit e5012d1f3861d18c7f3814e757c1c3ab3741dbcd upstream. Attribute IDs assigned in RFC 5661 now require three bitmaps. Fixes hitting a BUG_ON in xdr_shrink_bufhead when getting ACLs. Signed-off-by: Andy Adamson Signed-off-by: Trond Myklebust Signed-off-by: Greg Kroah-Hartman