Messages in this thread | | | Date | Wed, 12 Oct 2011 11:00:18 -0400 | Subject | Re: RFC: virtualbox tainting. | From | Parag Warudkar <> |
| |
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/
| |