on den 12.10.2005 Klokka 13:01 (+0200) skreiv Miklos Szeredi: > However I don't really like that the filesystem is reentered from > lookup_instantiate_filp() via __dentry_open() and ->open(). Is this > necessary? If filesystems need to be able to change the value of f_mapping, then yes, however if none of the potential users of lookup_instantiate_filp() care about doing so, then we can get rid of it. I don't care either way since we will not be supporting non-intent based opens for NFSv4. > I see you've fixed the O_TRUNC problem. The accmode==3 case is still > slightly broken, since now the file is being opened in read-write mode > instead of no-read-no-write mode. This probably won't break anything > too badly though. It is non-portable and it was never supported on NFSv4 anyway. If someone cares, they can fix it, but I don't see much need. > Equivalent and simpler: > > flags = nd->intent.open.flags - 1; > > Note, that the access bits of intent.open.flags will never both be > zero, so this is safe. Agreed. Cheers, Trond - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
- Follow-Ups:
- Re: [RFC] atomic create+open
- From: Miklos Szeredi <[email protected]>
- Re: [RFC] atomic create+open
- References:
- [RFC] atomic create+open
- From: Miklos Szeredi <[email protected]>
- Re: [RFC] atomic create+open
- From: Trond Myklebust <[email protected]>
- Re: [RFC] atomic create+open
- From: Miklos Szeredi <[email protected]>
- Re: [RFC] atomic create+open
- From: Miklos Szeredi <[email protected]>
- Re: [RFC] atomic create+open
- From: Trond Myklebust <[email protected]>
- Re: [RFC] atomic create+open
- From: Miklos Szeredi <[email protected]>
- Re: [RFC] atomic create+open
- From: Trond Myklebust <[email protected]>
- Re: [RFC] atomic create+open
- From: Miklos Szeredi <[email protected]>
- Re: [RFC] atomic create+open
- From: Trond Myklebust <[email protected]>
- Re: [RFC] atomic create+open
- From: Miklos Szeredi <[email protected]>
- Re: [RFC] atomic create+open
- From: Trond Myklebust <[email protected]>
- Re: [RFC] atomic create+open
- From: Miklos Szeredi <[email protected]>
- Re: [RFC] atomic create+open
- From: Trond Myklebust <[email protected]>
- Re: [RFC] atomic create+open
- From: Miklos Szeredi <[email protected]>
- Re: [RFC] atomic create+open
- From: Trond Myklebust <[email protected]>
- Re: [RFC] atomic create+open
- From: Miklos Szeredi <[email protected]>
- Re: [RFC] atomic create+open
- From: Trond Myklebust <[email protected]>
- Re: [RFC] atomic create+open
- From: Miklos Szeredi <[email protected]>
- Re: [RFC] atomic create+open
- From: Trond Myklebust <[email protected]>
- Re: [RFC] atomic create+open
- From: Miklos Szeredi <[email protected]>
- [RFC] atomic create+open
- Prev by Date: Re: blocking file lock functions (lockf,flock,fcntl) do not return after timer signal
- Next by Date: Re: Process with many NPTL threads terminates slowly on core dump signal
- Previous by thread: Re: [RFC] atomic create+open
- Next by thread: Re: [RFC] atomic create+open
- Index(es):