Messages in this thread | | | Date | Tue, 29 Jul 2008 21:00:27 -0400 | From | Erez Zadok <> | Subject | Re: [PATCH -mm] unionfs: build fixes |
| |
In message <Pine.LNX.4.64.0807291907440.13365@blonde.site>, Hugh Dickins writes: > Get unionfs building and working in mmotm with the 2.6.27-rc1 VFS changes: > permission() has been replaced by inode_permission() without nameidata arg; > unionfs_permission() without nameidata arg; vfs_symlink() without mode arg; > LOOKUP_ACCESS no longer defined; and kmem_cache_create() no longer passes > kmem_cachep to the init_once() constructor. > > Note: while okay for inclusion in -mm for now, unionfs_permission() mods > will need review and perhaps correction by Erez: without a nameidata arg, > some locking vanishes from unionfs_permission(), and a MNT_NOEXEC check on > its lower_inode; I have not studied the VFS changes enough to tell whether > that amounts to a real issue for unionfs, or just removal of dead code.
Thanks Hugh. You beat me by few hours. :-) I've been testing similar fixes for several days already (and was waiting for the dust to settle in the merge window, b/c patches flying b/t linus's tree, -next, and -mm).
I've also looked at the inode_permission() locking, and tested it, and I think it should be safe as long as the refcnt on the inode doesn't go to zero. In fact, I think unionfs_permission can be possibly further trimmed.
> Signed-off-by: Hugh Dickins <hugh@veritas.com> > Cc: Erez Zadok <ezk@cs.sunysb.edu> > --- > This should follow git-unionfs.patch > I notice my unionfs-fix-memory-leak.patch > and fsstack-fsstack_copy_inode_size-locking.patch > are currently commented out, yet I don't recall the > mm-commits dispatch rider bringing me a telegram to explain why?
Both of those patches are in my tree now (not yet pushed to korg).
Note: your fsstack-fsstack_copy_inode_size-locking patch should really go to mainline, but the one you sent depends on code in unionfs. So temporarily I'm folding it into my tree. In a couple of days (once I switch from using git to something like quilt) I'll extract it out into a separate patch which can be applied cleanly against linux-next, so that Andrew can hopefully send it upstream.
Erez.
| |