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  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:	Sun, 10 Aug 2014 17:05:59 -0700
From:	Linus Torvalds <>
To:	Guenter Roeck <>
Cc:	Oleg Nesterov <>, Kees Cook <>,
	"" <>,
	Andy Lutomirski <>
Subject: Re: Runtime trouble with commit dbd952127d (seccomp: introduce writer locking)

On Sun, Aug 10, 2014 at 4:18 PM, Guenter Roeck <> wrote:
> On 08/10/2014 02:10 PM, Linus Torvalds wrote:
>> Yes. This is why we have "assert_spin_locked()". You can't use
>> BUG_ON(spin_is_locked()), and !spin_is_locked() tends to be even worse
>> unless you can prove that nobody else can get the lock simultaneously.

Ignore that '!spin_is_locked()' is even worse part. We have indeed had
cases where people checked that something is not locked (and then did
bad things if somebody *else* locked it), but that's not what that
BUG_ON(!locked) tests, so


concept is fine (to test that the caller got the lock), it's just that
you have to use "assert_spin_locked()" for it because of all these
"the spinlock may not even _exist_" cases.

> git grep 'BUG_ON.*!spin_is_locked'
> suggests that this may be a spreading sickness ..

So that should just be converted to assert_spin_is_locked().

And we should probably try to get rid of users of "spin_is_locked()".
The problem is that there tends to be a few (very few) valid reasons
for using it, but then people mis-use it for testing the spinlock
state, and they *always* get it wrong.

The two wrong cases are exactly the "we're on UP, and there is no
spinlock state at all" and the "somebody requires it to be unlocked by
*that* process, but does crazy things if another process has happened
to lock it".

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

Powered by blists - more mailing lists