linux-kernel - Re: Runtime trouble with commit dbd952127d (seccomp: introduce writer locking)

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]

Message-ID: <CA+55aFyus4Le7EeCEaJpcVVshtwK93Et1C0AkPaC=5QnXJYjGw@mail.gmail.com>
Date:	Sun, 10 Aug 2014 17:05:59 -0700
From:	Linus Torvalds <torvalds@...ux-foundation.org>
To:	Guenter Roeck <linux@...ck-us.net>
Cc:	Oleg Nesterov <oleg@...hat.com>, Kees Cook <keescook@...omium.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	Andy Lutomirski <luto@...capital.net>
Subject: Re: Runtime trouble with commit dbd952127d (seccomp: introduce writer locking)

On Sun, Aug 10, 2014 at 4:18 PM, Guenter Roeck <linux@...ck-us.net> 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

   BUG_ON(!spin_is_locked());

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".

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