Re: [patch 041/234] Report that kernel is tainted if there was an OOPS

[Pavel Emelianov <xemul@openvz.org>]

Russell King wrote:
> On Wed, Jul 18, 2007 at 09:29:39AM +0400, Pavel Emelianov wrote:
>> Russell King wrote:
>>> On Tue, Jul 17, 2007 at 04:03:42AM -0700, akpm@linux-foundation.org wrote:
>>>> From: Pavel Emelianov <xemul@openvz.org>
>>>>
>>>> If the kernel OOPSed or BUGed then it probably should be considered as
>>>> tainted.  Thus, all subsequent OOPSes and SysRq dumps will report the
>>>> tainted kernel.  This saves a lot of time explaining oddities in the
>>>> calltraces.
>>> A bug causes an oops.  Oops are counted.  So, why do we need this
>>> additional complexity when we already have the '#' counter in oops
>>> dumps?
>>>
>>> For instance, on ARM:
>>>
>>> Unable to handle kernel NULL pointer dereference at virtual address 
>>> 00000090
>>> pgd = c0004000
>>> [00000090] *pgd=00000000
>>> Internal error: Oops: 817 [#1]
>>>                          ^^^^
>>> This is the oops counter.  Anything oops report from anyone other than the
>>> first should always be questioned.  Also note that this counter is not
>>> re-settable at run time, unlike the taint flags.
>>>
>> Press SysRq-P and you won't see any oops-counters, but just the info that 
>> the kernel is tainted. This is helpful to know that kernel oopsed when
>> observing the SysRq-p output. This is just one of the reasons.
> 
> Maybe it'd make more sense to print the oops counter in places where
> the tainted status is printed?
> 

Maybe. But the "tainted" mask is a common way to tell people that the 
kernel is not clean. Besides, the "D" taint flag and "non-zero" oops 
counter both mean the same thing, while "D" looks better.

Pavel