Jeff Mahoney: > Ok, yeah. fput() expects the file to have an instantiated dentry, which > may not exist. I've switched the code to use release_open_intent instead > and exported that in our kernel.
Essentially your approch has no difference from current code. Of course, I don't think it bad. Calling release_open_intent() may be more promising. > As for the lookup_one_len vs __lookup_hash issue, have you run into > problems with NFS2/3 as well as NFSv4? nfs_lookup looks like it can deal > with a NULL nameidata. NFSv4's nfs_atomic_lookup most definitely can't. Yes, there WAS a problem. I've checked the history of fs/nfs/dir.c now and found the reference to nameidata in nfs_lookup() was removed in linux-2.6.23. If you read fs/nfs/dir.c in 2.6.22 or older, you would know nfs_lookup() required non-NULL nameidata. Anyway I understand I should change several things in aufs/fs/aufs25 based upon your patch, including Kconfig.in and sysfs.c too probably. > I wonder because while I'm keen to support NFS with aufs on openSUSE, > but NFS4 isn't as much of a concern on LiveCDs. Unfortunately or fortunately, aufs is used in several fields other than live cd. :-) Actually I had bug reports or requests around nfsv4. (But I don't know they are still using aufs with nfsv4) The atomic open may not be important. I just wanted to keep the native feature of branch fs. While it introduces complicated code into aufs, I don't have a plan to drop it. There may exist a atomic open capable filesystem which I don't know yet. > Subject: aufs: Factor out __lookup_one_len > > The existing code acknowledges that it's just open coding __lookup_one_l= > en, > so why not just copy the function entirely and call it. If the code is > ever merged with mainline, it will be an obvious thing to rename > and export rather than having two copies of it. Because I began supporting nfs before __lookup_one_len() was born which was introduced in 2.6.22. As I left the comment, I have a plan to export the original one in fs/namei.c, instead of having a copy. And I still prefer exporting. But it never mean that your patch is bad. I will change aufs as you expect. > Subject: aufs: Handle NFSv4 enablement separately from NFSv2/3 Separating nfsv4 and supporting v2/v3 natively in linux-2.6.23 is a good change. Since CONFIG_NFS_V4 is separated, this approach suits better. By the way, it is Wednesday which is weekly feature freeze day I set. So your patches will be merged two weeks later. Some of them will be changed slightly, but the others will not. Anyway I appriciate your patches. Junjiro R. Okajima ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/
