Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932311AbbFHJW3 (ORCPT ); Mon, 8 Jun 2015 05:22:29 -0400 Received: from h1446028.stratoserver.net ([85.214.92.142]:42732 "EHLO mail.ahsoftware.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753121AbbFHJWN (ORCPT ); Mon, 8 Jun 2015 05:22:13 -0400 Message-ID: <55755EBB.7020105@ahsoftware.de> Date: Mon, 08 Jun 2015 11:22:03 +0200 From: Alexander Holler User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Ingo Molnar CC: Richard Weinberger , Linus Torvalds , Tejun Heo , Louis Langholtz , Linux Kernel Mailing List , Trivial patch monkey , Rusty Russell , Andrew Morton , Peter Zijlstra , Thomas Gleixner , Greg Kroah-Hartman Subject: Re: [PATCH] debug: Deprecate BUG_ON() use in new code, introduce CRASH_ON() References: <1433721270-9182-1-git-send-email-lou_langholtz@me.com> <20150608000007.GA3543@mtj.duckdns.org> <20150608071215.GA369@gmail.com> <557546E6.5030304@ahsoftware.de> <5575558E.5070706@ahsoftware.de> <20150608090509.GA19160@gmail.com> <20150608091132.GA19566@gmail.com> In-Reply-To: <20150608091132.GA19566@gmail.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1794 Lines: 42 Am 08.06.2015 um 11:11 schrieb Ingo Molnar: > > * Ingo Molnar wrote: > >> Firstly, the changelog of the patch that Greg rejected told nothing about all >> that thinking, so at minimum it's a deficient changelog. >> >> Secondly and more importantly, instead of doing a BUG_ON() you could have done: >> >> if (WARN_ON_ONCE(port->itty)) >> return; >> >> This would probably have prevented the tty related memory corruption just as >> much, at the cost of a (small and infrequent) memory leak. >> >> I.e. instead of crashing the machine, you need to try to find the least >> destructive approach if a bug is detected. > > Also note that BUG_ON() will make data corruption _worse_ statistically. Why? > Because most data corruptions are unlikely to be perfectly detected by a BUG_ON(), > and the BUG_ON() delays the finding of the underlying bug, so the bug will hit > more people before it's fixed for good. > > So even in the cases where you could argue that the system needs to stop, because > we have evidence of data corruption, it's statistically the better approach to > continue and get kernel log info back to developers. Risking more, maybe even worse problems like corrupting file systems or similiar in order to have a slightly chance of save log info? Sorry, that isn't something I would propose. Anyway, CRASH_ON didn't exist, so I only had the choice between BUG_ON and WARN_ON, and for the latter you need a proper exit path which isn't always easy to find. So I appreciate CRASH_ON, thanks. Alexander Holler -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/