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

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

[PATCH] sanitize ->permission() prototype

2008-07-27T00:53:14Z

* kill nameidata * argument; map the 3 bits in ->flags anybody cares about to new MAY_... ones and pass with the mask. * kill redundant gfs2_iop_permission() * sanitize ecryptfs_permission() * fix remaining places where ->permission() instances might barf on new MAY_... found in mask. The obvious next target in that direction is permission(9) folded fix for nfs_permission() breakage from Miklos Szeredi Signed-off-by: Al Viro

SL*B: drop kmem cache argument from constructor

2008-07-26T19:00:07Z

Kmem cache passed to constructor is only needed for constructors that are themselves multiplexeres. Nobody uses this "feature", nor does anybody uses passed kmem cache in non-trivial way, so pass only pointer to object. Non-trivial places are: arch/powerpc/mm/init_64.c arch/powerpc/mm/hugetlbpage.c This is flag day, yes. Signed-off-by: Alexey Dobriyan Acked-by: Pekka Enberg Acked-by: Christoph Lameter Cc: Jon Tollefson Cc: Nick Piggin Cc: Matt Mackall [akpm@linux-foundation.org: fix arch/powerpc/mm/hugetlbpage.c] [akpm@linux-foundation.org: fix mm/slab.c] [akpm@linux-foundation.org: fix ubifs] Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds

remove unused #include 's

2008-07-25T17:53:34Z

Remove some unused #include 's. Signed-off-by: Adrian Bunk Cc: Ralf Baechle Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds

Remove BKL from remote_llseek v2

2008-07-02T21:06:27Z

- Replace remote_llseek with generic_file_llseek_unlocked (to force compilation failures in all users) - Change all users to either use generic_file_llseek_unlocked directly or take the BKL around. I changed the file systems who don't use the BKL for anything (CIFS, GFS) to call it directly. NCPFS and SMBFS and NFS take the BKL, but explicitely in their own source now. I moved them all over in a single patch to avoid unbisectable sections. Open problem: 32bit kernels can corrupt fpos because its modification is not atomic, but they can do that anyways because there's other paths who modify it without BKL. Do we need a special lock for the pos/f_version = 0 checks? Trond says the NFS BKL is likely not needed, but keep it for now until his full audit. v2: Use generic_file_llseek_unlocked instead of remote_llseek_unlocked and factor duplicated code (suggested by hch) Cc: Trond.Myklebust@netapp.com Cc: swhiteho@redhat.com Cc: sfrench@samba.org Cc: vandrove@vc.cvut.cz Signed-off-by: Andi Kleen Signed-off-by: Andi Kleen Signed-off-by: Jonathan Corbet

fs: replace remaining FUNCTION occurrences

2008-04-30T15:29:54Z

__FUNCTION__ is gcc-specific, use __func__ Signed-off-by: Harvey Harrison Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds

NULL noise: fs/, mm/, kernel/*

2008-03-30T21:18:41Z

Signed-off-by: Al Viro Signed-off-by: Linus Torvalds

fs/smbfs/inode.c: fix warning message deprecating smbfs

2008-02-14T00:21:19Z

Fix the warning message regarding smbfs to "smbfs is deprecated and will be removed from the 2.6.27 kernel. Please migrate to cifs" instead of "smbfs is deprecated and will be removedfrom the 2.6.27 kernel. Please migrate to cifs" Signed-off-by: Sergio Luis Screwed-up-by: Andrew Morton Cc: Steven French Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds

smbfs: fix calculation of kernel_recvmsg size parameter in smb_receive()

2008-02-06T18:41:02Z

smb_receive calls kernel_recvmsg with a size that's the minimum of the amount of buffer space in the kvec passed in or req->rq_rlen (which represents the length of the response). This does not take into account any data that was read in a request earlier pass through smb_receive. If the first pass through smb_receive receives some but not all of the response, then the next pass can call kernel_recvmsg with a size field that's too big. kernel_recvmsg can overrun into the next response, throwing off the alignment and making it unrecognizable. This causes messages like this to pop up in the ring buffer: smb_get_length: Invalid NBT packet, code=69 as well as other errors indicating that the response is unrecognizable. Typically this is seen on a smbfs mount under heavy I/O. This patch changes the code to use (req->rq_rlen - req->rq_bytes_recvd) instead instead of just req->rq_rlen, since that should represent the amount of unread data in the response. I think this is correct, but an ACK or NACK from someone more familiar with this code would be appreciated... Signed-off-by: Jeff Layton Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds

deprecate smbfs in favour of cifs

2008-02-05T22:37:15Z

smbfs is a bit buggy and has no maintainer. Change it to shout at the user on the first five mount attempts - tell them to switch to CIFS. Come December we'll mark it BROKEN and see what happens. [olecom@flower.upol.cz: documentation update] Cc: Urban Widmark Acked-by: Steven French Signed-off-by: Oleg Verych Cc: Jeff Layton Cc: Adrian Bunk Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds