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

[Linus Torvalds]

On Sun, Aug 10, 2014 at 4:18 PM, Guenter Roeck <linux@xxxxxxxxxxxx> 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@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/