linux-kernel - Re: [rfc] lock bitops

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:	Wed, 09 May 2007 07:23:15 +1000
From:	Benjamin Herrenschmidt <benh@...nel.crashing.org>
To:	Matthew Wilcox <matthew@....cx>
Cc:	Nick Piggin <npiggin@...e.de>, linux-arch@...r.kernel.org,
	Andrew Morton <akpm@...ux-foundation.org>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: [rfc] lock bitops

On Tue, 2007-05-08 at 09:06 -0600, Matthew Wilcox wrote:
> On Tue, May 08, 2007 at 01:37:09PM +0200, Nick Piggin wrote:
> > --
> > Introduce test_and_set_bit_lock / clear_bit_unlock bitops with lock semantics.
> > Add non-trivial for powerpc and ia64. Convert page lock, buffer lock,
> > bit_spin_lock, tasklet locks to use the new locks.
> 
> The names are a bit clumsy.  How about naming them after the effect,
> rather than the implementation?  It struck me that really these things
> are bit mutexes -- you can sleep while holding the lock.  How about
> calling them bit_mutex_trylock() and bit_mutex_unlock()?

Hrm... spin_trylock vs. mutex_trylock ... what difference ? :-)

Note that if we're gonna generalize the usage as a mutex, we might want
to extend the unlock semantic to return the first word flag atomically
so that the caller can test for other bits without having to read
the word back (which might be a performance hit on CPUs without store
forwarding). That's already what Nick's new unlock_page() does (testing
the flag again right after unlock). At first, I though it would make
clear_bit_unlock() semantics a bit too clumsy but maybe it's worth it.

Ben.


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