linux-kernel - Re: [PATCH 2/7] fs/locks: Replace lg

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:   Tue, 6 Sep 2016 10:59:42 +0200
From:   Peter Zijlstra <peterz@...radead.org>
To:     Andreas Mohr <andi@...as.de>
Cc:     der.herr@...r.at, Al Viro <viro@...IV.linux.org.uk>,
        mingo@...hat.com, torvalds@...ux-foundation.org, dave@...olabs.net,
        Oleg Nesterov <oleg@...hat.com>, riel@...hat.com,
        tj@...nel.org, paulmck@...ux.vnet.ibm.com,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCH 2/7] fs/locks: Replace lg_global with a percpu-rwsem

On Tue, Sep 06, 2016 at 10:36:01AM +0200, Andreas Mohr wrote:
> There might be further archives (other than gmane.org or some such),
> however so far lkml.org seemed to be quite ok
> and with IMHO better usability than some others

Agreed, in that I liked the interface best too, however:

> (although it has degraded a lot indeed in recent times,
> judging from
> many server/connection issues and
> not listing details any more due to SPAM etc.).

this has gotten to the point where it often simply doesn't show messages
anymore, threads are incomplete etc..

> > > A possibly good way to commit-micro-manage this would be:
> > > 1. commit shoves things into a newly created encapsulation/wrapper helper
> > >    stuff_lock(&flc_lock);  /* <---- naming surely can be improved here */
> > 
> > No, because not all instances of flc_flock need the percpu-rwsem held,
> > creating such a wrapper could mistakenly create the impression it
> > should.
> 
> OK, that aspect sounds valid.
> However with a helper appropriately named to be focussing on
> that use case (protecting that section communication),
> it might be less of a concern.

Dunno, I'd struggling to come up with a sensible name for such a
construct. I'll leave that to others. If it really is desired we can
always do so later.