public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Al Viro <viro@ZenIV.linux.org.uk>
To: Matthew Wilcox <matthew@wil.cx>
Cc: Andrew Morton <akpm@linux-foundation.org>,
	Bryan Wu <cooloney@kernel.org>,
	linux-kernel@vger.kernel.org, torvalds@linux-foundation.org,
	willy@debian.org, uclinux-dist-devel@blackfin.uclinux.org,
	"J. Bruce Fields" <bfields@fieldses.org>
Subject: Re: [LTP/VFS] fcntl SETLEASE fails on ramfs/tmpfs
Date: Thu, 1 May 2008 07:33:39 +0100	[thread overview]
Message-ID: <20080501063339.GU5882@ZenIV.linux.org.uk> (raw)
In-Reply-To: <20080429222141.GD14976@parisc-linux.org>

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.

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.

  reply	other threads:[~2008-05-01  6:34 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-04-29  3:42 [LTP/VFS] fcntl SETLEASE fails on ramfs/tmpfs Bryan Wu
2008-04-29 20:54 ` Andrew Morton
2008-04-29 21:42   ` J. Bruce Fields
2008-04-29 22:01     ` Mike Frysinger
2008-04-29 22:11       ` J. Bruce Fields
2008-04-29 22:15         ` Mike Frysinger
2008-04-29 23:21     ` david m. richter
2008-04-30 17:50       ` J. Bruce Fields
2008-04-30 18:14         ` david m. richter
2008-05-01  6:24     ` Al Viro
2008-05-02 22:22       ` J. Bruce Fields
2008-04-29 22:21   ` Matthew Wilcox
2008-05-01  6:33     ` Al Viro [this message]
2008-05-02 22:26       ` J. Bruce Fields

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20080501063339.GU5882@ZenIV.linux.org.uk \
    --to=viro@zeniv.linux.org.uk \
    --cc=akpm@linux-foundation.org \
    --cc=bfields@fieldses.org \
    --cc=cooloney@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=matthew@wil.cx \
    --cc=torvalds@linux-foundation.org \
    --cc=uclinux-dist-devel@blackfin.uclinux.org \
    --cc=willy@debian.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox