Re: [LTP/VFS] fcntl SETLEASE fails on ramfs/tmpfs

[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.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/