From: Guenter Roeck <linux@roeck-us.net>
To: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Oleg Nesterov <oleg@redhat.com>,
Kees Cook <keescook@chromium.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
Andy Lutomirski <luto@amacapital.net>
Subject: Re: Runtime trouble with commit dbd952127d (seccomp: introduce writer locking)
Date: Sun, 10 Aug 2014 16:18:13 -0700 [thread overview]
Message-ID: <53E7FDB5.4070607@roeck-us.net> (raw)
In-Reply-To: <CA+55aFz3vW_qnrwa6kWMsN1pGbjnyGXGBNhH=DO0berKgyOtgQ@mail.gmail.com>
On 08/10/2014 02:10 PM, Linus Torvalds wrote:
> On Sun, Aug 10, 2014 at 1:51 PM, Guenter Roeck <linux@roeck-us.net> wrote:
>> That means that the broken configuration is (CONFIG_DEBUG_SPINLOCK=n,
>> CONFIG_SMP=n).
>> It also means that the BUG_ON checks introduced with the seccomp commit
>> will cause this configuration to fail hard at least for architectures where
>> CONFIG_SMP
>> can be disabled, and if those architectures use
>> include/linux/spinlock_types_up.h.
>
> 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.
>
git grep 'BUG_ON.*!spin_is_locked'
suggests that this may be a spreading sickness ... unless the other users
know for sure that SMP will always be configured.
What is the better fix ? Add NR_CPUS != 1 to the test, as mm does,
or remove it entirely ? Or something else ?
Guenter
next prev parent reply other threads:[~2014-08-10 23:18 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-08-10 1:47 Runtime trouble with commit dbd952127d (seccomp: introduce writer locking) Guenter Roeck
2014-08-10 3:18 ` Kees Cook
2014-08-10 5:37 ` Guenter Roeck
2014-08-10 18:35 ` Guenter Roeck
2014-08-10 19:33 ` Oleg Nesterov
2014-08-10 20:51 ` Guenter Roeck
2014-08-10 21:10 ` Linus Torvalds
2014-08-10 23:18 ` Guenter Roeck [this message]
2014-08-11 0:05 ` Linus Torvalds
2014-08-11 11:48 ` Oleg Nesterov
2014-08-11 14:11 ` Guenter Roeck
2014-08-11 19:51 ` Kees Cook
2014-08-11 20:26 ` Guenter Roeck
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=53E7FDB5.4070607@roeck-us.net \
--to=linux@roeck-us.net \
--cc=keescook@chromium.org \
--cc=linux-kernel@vger.kernel.org \
--cc=luto@amacapital.net \
--cc=oleg@redhat.com \
--cc=torvalds@linux-foundation.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox