lkml.org 
[lkml]   [2015]   [Jun]   [8]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH] debug: Deprecate BUG_ON() use in new code, introduce CRASH_ON()
Am 08.06.2015 um 11:11 schrieb Ingo Molnar:
>
> * Ingo Molnar <mingo@kernel.org> 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


\
 
 \ /
  Last update: 2015-06-08 11:41    [W:0.721 / U:0.008 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site