linux-kernel - Re: [patch 00/27] [rfc] vfs scalability patchset

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]

Date:	Thu, 30 Apr 2009 08:14:54 +0200
From:	Nick Piggin <npiggin@...e.de>
To:	"Eric W. Biederman" <ebiederm@...ssion.com>
Cc:	Christoph Hellwig <hch@...radead.org>,
	Al Viro <viro@...IV.linux.org.uk>,
	linux-fsdevel@...r.kernel.org, linux-kernel@...r.kernel.org,
	Peter Zijlstra <peterz@...radead.org>
Subject: Re: [patch 00/27] [rfc] vfs scalability patchset

On Tue, Apr 28, 2009 at 04:32:13AM -0700, Eric W. Biederman wrote:
> Christoph Hellwig <hch@...radead.org> writes:
> 
> > On Sat, Apr 25, 2009 at 09:06:49AM +0100, Al Viro wrote:
> >> Maybe...  What Eric proposed is essentially a reuse of s_list for per-inode
> >> list of struct file.  Presumably with something like i_lock for protection.
> >> So that's not a conflict.
> >
> > But what do we actually want it for?  Right now it's only used for
> > ttys, which Nick has split out, and for remount r/o.  For the normal
> > remount r/o case it will go away once we have proper per-sb writer
> > counts.  And the fource remount r/o from sysrq is completely broken.
> 
> The plan is to post my updated patches tomorrow after I have slept.
> 
> What I am looking at is that the tty layer is not a special case.  Any
> subsystem that wants any revoke kind of functionality starts wanting
> the list of files that are open.  My current list where we have
> something like this is: sysfs, proc, sysctl, tun, tty, sound.

How's this coming along? It would be good to get this change out
and reviewed ASAP, and ahead of the rest of your patchset IMO.
Hopefully we can get it into Al's tree for 2.6.31 if it all falls
out nicely.

BTW. I would just keep the single files_lock spinlock in the
first patch that would move to per-inode lists, and then a 2nd
patch could swap out the locking without making any other changes
(or else you could just leave the locking global and we can
evaluate it in the context of the rest of the vfs scalability
work).

--
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/