kernel.git/fs/namei.c, branch linux-2.6.28.y

System call wrappers part 29

2009-01-18T18:44:01Z

commit 2e4d0924eb0c403ce4014fa139d1d61bf2c44fee upstream. Signed-off-by: Heiko Carstens Signed-off-by: Greg Kroah-Hartman

System call wrappers part 20

2009-01-18T18:43:57Z

commit 3cdad42884bbd95d5aa01297e8236ea1bad70053 upstream. Signed-off-by: Heiko Carstens Signed-off-by: Greg Kroah-Hartman

System call wrappers part 15

2009-01-18T18:43:56Z

commit a26eab2400f0477bfac0255600552394855016f7 upstream. Signed-off-by: Heiko Carstens Signed-off-by: Greg Kroah-Hartman

System call wrappers part 14

2009-01-18T18:43:56Z

commit 3480b25743cb7404928d57efeaa3d085708b04c2 upstream. Signed-off-by: Heiko Carstens 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

don't unlink an active swapfile

2008-11-20T02:49:59Z

Peter Cordes is sorry that he rm'ed his swapfiles while they were in use, he then had no pathname to swapoff. It's a curious little oversight, but not one worth a lot of hackery. Kudos to Willy Tarreau for turning this around from a discussion of synthetic pathnames to how to prevent unlink. Mimic immutable: prohibit unlinking an active swapfile in may_delete() (and don't worry my little head over the tiny race window). Signed-off-by: Hugh Dickins Cc: Willy Tarreau Acked-by: Christoph Hellwig Cc: Peter Cordes Cc: Bodo Eggert <7eggert@gmx.de> Cc: David Newall Cc: Peter Zijlstra Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds

[PATCH] move executable checking into ->permission()

2008-10-23T09:13:25Z

For execute permission on a regular files we need to check if file has any execute bits at all, regardless of capabilites. This check is normally performed by generic_permission() but was also added to the case when the filesystem defines its own ->permission() method. In the latter case the filesystem should be responsible for performing this check. Move the check from inode_permission() inside filesystems which are not calling generic_permission(). Create a helper function execute_ok() that returns true if the inode is a directory or if any execute bits are present in i_mode. Also fix up the following code: - coda control file is never executable - sysctl files are never executable - hfs_permission seems broken on MAY_EXEC, remove - hfsplus_permission is eqivalent to generic_permission(), remove Signed-off-by: Miklos Szeredi

[PATCH vfs-2.6 6/6] vfs: add LOOKUP_RENAME_TARGET intent

2008-10-23T09:13:20Z

This adds LOOKUP_RENAME_TARGET intent for lookup of rename destination. LOOKUP_RENAME_TARGET is going to be used like LOOKUP_CREATE. But since the destination of rename() can be existing directory entry, so it has a difference. Although that difference doesn't matter in my usage, this tells it to user of this intent. Signed-off-by: OGAWA Hirofumi

[PATCH vfs-2.6 5/6] vfs: remove LOOKUP_PARENT from non LOOKUP_PARENT lookup

2008-10-23T09:13:19Z

lookup_hash() with LOOKUP_PARENT is bogus. And this prepares to add new intent on those path. The user of LOOKUP_PARENT intent is nfs only, and it checks whether nd->flags has LOOKUP_CREATE or LOOKUP_OPEN, so the result is same. Signed-off-by: OGAWA Hirofumi

[PATCH vfs-2.6 2/6] vfs: add d_ancestor()

2008-10-23T09:13:16Z

This adds d_ancestor() instead of d_isparent(), then use it. If new_dentry == old_dentry, is_subdir() returns 1, looks strange. "new_dentry == old_dentry" is not subdir obviously. But I'm not checking callers for now, so this keeps current behavior. Signed-off-by: OGAWA Hirofumi