Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S936373AbcJFX7c (ORCPT ); Thu, 6 Oct 2016 19:59:32 -0400 Received: from mail-oi0-f47.google.com ([209.85.218.47]:34548 "EHLO mail-oi0-f47.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S935057AbcJFX7W (ORCPT ); Thu, 6 Oct 2016 19:59:22 -0400 MIME-Version: 1.0 In-Reply-To: References: <20161005054407.GC7297@1wt.eu> <20161005190604.GA8116@1wt.eu> From: Linus Torvalds Date: Thu, 6 Oct 2016 16:59:20 -0700 X-Google-Sender-Auth: tsxXwFqQjzfRRGrhaaS0veVWZ2E Message-ID: Subject: Re: BUG_ON() in workingset_node_shadows_dec() triggers To: Kees Cook Cc: Willy Tarreau , Paul Gortmaker , Johannes Weiner , Andrew Morton , Antonio SJ Musumeci , Miklos Szeredi , Linux Kernel Mailing List , stable Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1452 Lines: 36 On Thu, Oct 6, 2016 at 4:05 PM, Kees Cook wrote: > > 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. I think you must have changed something else too. I can't think of what else there is than the crazy "oops_in+_progress" hacks. We used to reset the preempt counter too, but with that being per-thread I don't think that even matters. So I think you may have some voodoo programming there. An an oops (but not a do_exit()) will add a taint, and there's the notifications that might do random things (mainly kgdb and tracing). But that should be pretty much it. > 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. Not true. That kind of thinking just says "we can never change BUG at all". You'll never fix anything that way. We should just switch BUG() over and be done with it. The whole point it that since it should never trigger in the first place, the semantics on BUG() should never matter. And if you have some code that depends on the semantics of BUG(), that code is buggy crap *by*definition*. And there's no way we'll let that kind of shit determine kernel development. That would be insane. Linus