kernel.git/fs/cifs, branch linux-2.6.28.y

CIFS: Fix memory overwrite when saving nativeFileSystem field during mount

2009-05-02T17:56:37Z

upstream commit: b363b3304bcf68c4541683b2eff70b29f0446a5b CIFS can allocate a few bytes to little for the nativeFileSystem field during tree connect response processing during mount. This can result in a "Redzone overwritten" message to be logged. Signed-off-by: Sridhar Vinay Acked-by: Shirish Pargaonkar Signed-off-by: Steve French [chrisw: minor backport to CHANGES file] Signed-off-by: Chris Wright Signed-off-by: Greg Kroah-Hartman

cifs: fix buffer format byte on NT Rename/hardlink

2009-05-02T17:56:35Z

upstream commit: fcc7c09d94be7b75c9ea2beb22d0fae191c6b4b9 Discovered at Connnectathon 2009... The buffer format byte and the pad are transposed in NT_RENAME calls (which are used to set hardlinks). Most servers seem to ignore this fact, but NetApp filers throw back an error due to this problem. This patch fixes it. Signed-off-by: Jeff Layton Signed-off-by: Steve French Signed-off-by: Chris Wright Signed-off-by: Greg Kroah-Hartman

Fix oops in cifs_strfromUCS_le mounting to servers which do not specify their OS

2009-03-17T00:31:58Z

commit 69765529d701c838df19ea1f5ad2f33a528261ae upstream. Fixes kernel bug #10451 http://bugzilla.kernel.org/show_bug.cgi?id=10451 Certain NAS appliances do not set the operating system or network operating system fields in the session setup response on the wire. cifs was oopsing on the unexpected zero length response fields (when trying to null terminate a zero length field). This fixes the oops. Acked-by: Jeff Layton Signed-off-by: Steve French Signed-off-by: Greg Kroah-Hartman

cifs: make sure we allocate enough storage for socket address

2009-02-06T21:47:18Z

commit a9ac49d303f967be0dabd97cb722c4a13109c6c2 upstream. cifs_mount declares a struct sockaddr on the stack and then casts it to the proper address type. The storage allocated is fine for ipv4, but is too small for ipv6 addresses. Declare it as "struct sockaddr_storage" instead of struct sockaddr". This bug was manifesting itself as oopses and address corruption when mounting IPv6 addresses. Signed-off-by: Jeff Layton Tested-by: Stefan Bader Signed-off-by: Steve French Signed-off-by: Greg Kroah-Hartman

fs: symlink write_begin allocation context fix

2009-01-18T18:43:46Z

commit 54566b2c1594c2326a645a3551f9d989f7ba3c5e upstream. With the write_begin/write_end aops, page_symlink was broken because it could no longer pass a GFP_NOFS type mask into the point where the allocations happened. They are done in write_begin, which would always assume that the filesystem can be entered from reclaim. This bug could cause filesystem deadlocks. The funny thing with having a gfp_t mask there is that it doesn't really allow the caller to arbitrarily tinker with the context in which it can be called. It couldn't ever be GFP_ATOMIC, for example, because it needs to take the page lock. The only thing any callers care about is __GFP_FS anyway, so turn that into a single flag. Add a new flag for write_begin, AOP_FLAG_NOFS. Filesystems can now act on this flag in their write_begin function. Change __grab_cache_page to accept a nofs argument as well, to honour that flag (while we're there, change the name to grab_cache_page_write_begin which is more instructive and does away with random leading underscores). This is really a more flexible way to go in the end anyway -- if a filesystem happens to want any extra allocations aside from the pagecache ones in ints write_begin function, it may now use GFP_KERNEL (rather than GFP_NOFS) for common case allocations (eg. ocfs2_alloc_write_ctxt, for a random example). [kosaki.motohiro@jp.fujitsu.com: fix ubifs] [kosaki.motohiro@jp.fujitsu.com: fix fuse] Signed-off-by: Nick Piggin Reviewed-by: KOSAKI Motohiro Signed-off-by: KOSAKI Motohiro Signed-off-by: Andrew Morton [ Cleaned up the calling convention: just pass in the AOP flags untouched to the grab_cache_page_write_begin() function. That just simplifies everybody, and may even allow future expansion of the logic. - Linus ] Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman

CIFS: make sure that DFS pathnames are properly formed

2009-01-18T18:43:44Z

commit c6fbba0546d3ead18d4a623e76e28bcbaa66a325 upstream. The paths in a DFS request are supposed to only have a single preceding backslash, but we are sending them with a double backslash. This is exposing a bug in Windows where it also sends a path in the response that has a double backslash. The existing code that builds the mount option string however expects a double backslash prefix in a couple of places when it tries to use the path returned by build_path_from_dentry. Fix compose_mount_options to expect properly formed DFS paths (single backslash at front). Also clean up error handling in that function. There was a possible NULL pointer dereference and situations where a partially built option string would be returned. Tested against Samba 3.0.28-ish server and Samba 3.3 and Win2k8. Signed-off-by: Jeff Layton Signed-off-by: Steve French Signed-off-by: Greg Kroah-Hartman

cifs: fix buffer overrun in parse_DFS_referrals

2008-12-17T22:59:55Z

While testing a kernel with memory poisoning enabled, I saw some warnings about the redzone getting clobbered when chasing DFS referrals. The buffer allocation for the unicode converted version of the searchName is too small and needs to take null termination into account. Signed-off-by: Jeff Layton Acked-by: Steve French Signed-off-by: Linus Torvalds

[CIFS] fix regression in cifs_write_begin/cifs_write_end

2008-11-26T19:32:33Z

The conversion to write_begin/write_end interfaces had a bug where we were passing a bad parameter to cifs_readpage_worker. Rather than passing the page offset of the start of the write, we needed to pass the offset of the beginning of the page. This was reliably showing up as data corruption in the fsx-linux test from LTP. It also became evident that this code was occasionally doing unnecessary read calls. Optimize those away by using the PG_checked flag to indicate that the unwritten part of the page has been initialized. CC: Nick Piggin Acked-by: Dave Kleikamp Signed-off-by: Jeff Layton Signed-off-by: Steve French

[CIFS] Do not attempt to close invalidated file handles

2008-11-20T20:14:13Z

If a connection with open file handles has gone down and come back up and reconnected without reopening the file handle yet, do not attempt to send an SMB close request for this handle in cifs_close. We were checking for the connection being invalid in cifs_close but since the connection may have been reconnected we also need to check whether the file handle was marked invalid (otherwise we could close the wrong file handle by accident). Acked-by: Jeff Layton Signed-off-by: Steve French

[CIFS] fix check for dead tcon in smb_init

2008-11-18T16:33:48Z

This was recently changed to check for need_reconnect, but should actually be a check for a tidStatus of CifsExiting. Signed-off-by: Jeff Layton Signed-off-by: Steve French