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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <20080502222624.GR21918@fieldses.org>
Date:	Fri, 2 May 2008 18:26:24 -0400
From:	"J. Bruce Fields" <bfields@...ldses.org>
To:	Al Viro <viro@...IV.linux.org.uk>
Cc:	Matthew Wilcox <matthew@....cx>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Bryan Wu <cooloney@...nel.org>, linux-kernel@...r.kernel.org,
	torvalds@...ux-foundation.org, willy@...ian.org,
	uclinux-dist-devel@...ckfin.uclinux.org, richterd@...i.umich.edu
Subject: Re: [LTP/VFS] fcntl SETLEASE fails on ramfs/tmpfs

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@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/