Messages in this thread | | | Date | Fri, 2 May 2008 18:26:24 -0400 | Subject | Re: [LTP/VFS] fcntl SETLEASE fails on ramfs/tmpfs | From | "J. Bruce Fields" <> |
| |
On Thu, May 01, 2008 at 07:33:39AM +0100, Al Viro wrote: > On Tue, Apr 29, 2008 at 04:21:42PM -0600, Matthew Wilcox wrote: > > On Tue, Apr 29, 2008 at 01:54:54PM -0700, Andrew Morton wrote: > > > I guess we should make the generic_setlease() heuristic smarter. > > > > > > Of course the _reason_ for that heuristic is uncommented and lost in time. > > > And one wonders what locking prevents it from being totally racy, and if > > > "none", what happens when the race hits. Sigh. > > > > It's hardly "lost in time" when you can ask the original author. > > > > If there are multiple processes with this file open, you can't place a > > lease on it. > > ... except that it has nofsckingthing in common with the checks in > question. Number of processes having a file open has has nothing to > do dentry or inode refcounts; indeed, if you have opened file once > it'd have only one struct file. Moreover, e.g. stat(2) on its name > will bump dentry refcount just fine. Moreover, if you have two threads > with common descriptor table, not even *file* refcount will help you.
Your point about unclear requirements is taken, but I doubt anyone needs exclusion between leases and threads that share the file descriptor on which the lease was taken.
--b.
> BTW, ->fl_owner in those suckers is fairly useless - open files, take > leases, fork, have parent exit. Voila - you've got a bunch of file_lock > with ->fl_owner pointing to freed files_struct. Fortunately it's never > going to be dereferenced, but results of comparisons are unreliable as > hell.
| |