lkml.org 
[lkml]   [2008]   [May]   [2]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
SubjectRe: [LTP/VFS] fcntl SETLEASE fails on ramfs/tmpfs
From
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.


\
 
 \ /
  Last update: 2008-05-03 00:29    [W:0.074 / U:0.172 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site