lkml.org 
[lkml]   [2011]   [Oct]   [12]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
SubjectRe: RFC: virtualbox tainting.
From
On Wed, Oct 12, 2011 at 10:18 AM, Alex Riesen <raa.lkml@gmail.com> wrote:
> On Wed, Oct 12, 2011 at 16:08, Parag Warudkar <parag.lkml@gmail.com> wrote:
>> On Wed, Oct 12, 2011 at 3:55 AM, Alex Riesen <raa.lkml@gmail.com> wrote:
>>> On Wed, Oct 12, 2011 at 02:57, Parag Warudkar <parag.lkml@gmail.com> wrote:
>>>> Why can't the automatic bug filing tools have a user space list of
>>>> offending modules that it can use to opt out of automatically filing
>>>> kernel bugs? ...
>>>
>>> Maybe because an oops is not always conveniently accompanied by enough
>>> information
>>> to opt-out.
>>>
>>
>> In which case the reporting of the OOPS is useless anyways
>> irrespective of whether or not vboxdrv was loaded. So the tool  can
>
> Of course not. There is a lot of insight in the instruction dump,
> which may be still present, or in stack trace.
>

How likely is an OOPS to just have the useful instruction dump but no
other info?
I think the likelihood is in the same ballpark as the likelihood of
vboxdrv being loaded but OOPS being caused by something else.

In both cases we end up losing a OOPS or two - not a big deal IMHO.

Generally the tainted flag is followed by module list, followed by the
IP, Regs, stack trace and then instruction dump.
I would think that if it got around to printing the instruction dump
it would have already printed the module list which is enough for user
space tool to opt out.

Parag
--
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/

\
 
 \ /
  Last update: 2011-10-12 17:03    [W:0.037 / U:8.992 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site