Re: BUG_ON() in workingset_node_shadows_dec() triggers

[Kees Cook]

On Thu, Oct 6, 2016 at 3:29 PM, Linus Torvalds
<torvalds@xxxxxxxxxxxxxxxxxxxx> wrote:
> On Thu, Oct 6, 2016 at 3:07 PM, Kees Cook <keescook@xxxxxxxxxxxx> wrote:
>> The "cleanest" way to handle it seemed to be the lock-busting logic
>> already built into BUG, so I moved to that.
>
> Heh. The lock-busting logic in BUG() has always been broken. It's been
> random hacks. It doesn't actually work in any general case, it just
> occasionally happens to get things right. Mostly it tries to handle
> the console locking (the whole "oops_in_progress" magic) so that if
> you have a BUG_ON() in bad areas, at least you still end up getting
> output.

It seems to handle other things too, file descriptors, I think? Some
giant warning, I think about fds, went away when I switched from
do_exit() to BUG(). I'd have to go look more closely.

> But no, it's not reliable in any way, shape or form. That's really why
> you want to continue after a BUG().

Yeah, agreed about the unreliability. It's why I'm a fan of
panic_on_oops. :P (Except when doing lots of tests under lkdtm, then I
like having multiple Oopses without rebooting, but perhaps that is
literally the only use-case...)

>> By far the most problematic is "stop kernel execution from
>> continuing", but that's currently the behavior that BUG depends on, so
>> replacing BUG with anything needs to either fix the surrounding logic
>> to fail sanely or we have the keep the feature.
>
> Well, I'm not sure how much we actually end up depending on it,
> considering that we now have two examples of BUG() implementations
> that actually do _not_ depend on stopping execution: both the sound
> subsystem and the XFS version of BUG_ON() end up not actually doing
> the BUG() thing.

Yeah, for sure. I didn't mean to imply they all depended on it, just
that finding those that do will require manual inspection. We'll not
be able to do a flag-day on BUG until we fix everything.

-Kees

-- 
Kees Cook
Nexus Security