linux-kernel - Re: [patch 04/33] fs: brlock vfsmount

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] [thread-next>] [day] [month] [year] [list]

Date:	Mon, 28 Sep 2009 15:21:03 +0200
From:	Peter Zijlstra <peterz@...radead.org>
To:	Nick Piggin <npiggin@...e.de>
Cc:	Al Viro <viro@...IV.linux.org.uk>, linux-fsdevel@...r.kernel.org,
	linux-kernel@...r.kernel.org
Subject: Re: [patch 04/33] fs: brlock vfsmount_lock

On Sun, 2009-09-27 at 21:56 +0200, Nick Piggin wrote:
> On Tue, Sep 22, 2009 at 04:17:51PM +0100, Al Viro wrote:
> > On Fri, Sep 04, 2009 at 04:51:45PM +1000, npiggin@...e.de wrote:
> > > Use a brlock for the vfsmount lock.
> > 
> > I like it, but I'd like to see how costly it becomes on heavily SMP boxen.
> > Creation/removal of bindings as load...
> 
> I could test that... Is there some realistic scenario I can try
> to implement that exercises this? (failing that, I'll happily
> do a microbenchmark).
> 
> I was thinking it *might* be possible to do RCU... but especially
> coming up with a scheme that avoids synchronize_rcu() in the
> umount path is not trivial, so perhaps the simple read/write
> annotations with brlock behind the scenes is a more reasonable step.
> 
> I do also actually owe you some documentation with this one too,
> which I will get around to adding.

The thing that worries me is that the write-side is very heavy and the
read sides are spinning on it, yielding rather large spin times on large
smp boxen.

It wouldn't nearly be as bad if the read sides could block..

FWIW, spin_lock_nested is limited to 8 subclasses, so your current
implementation will explode on anything larger than an 8-way.

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