I'm modifying a couple of drivers in order to implement a small piece of low-level convenience functionality, and in doing so tainting my kernel due to out-of-tree modules. I'm well aware that in most cases it shouldn't be a problem, although before reporting a bug or other issue I should reproduce it with an untainted kernel. However, I have also seen a few places, such as in the accepted answer of What is a tainted Linux kernel? (first paragraph), that having a tainted kernel may have worsened/fewer debugging features. I have not been able to find any official documentation to back that claim up nor do any of the places I've seen it have any additional information.

Is this a just an internet rumor, or is there something I need to be aware of for when I find myself trying to track down an issue in my system?


1 Answer 1


A tainted kernel only has very slight differences in behaviour, and only to protect itself, never to disable features just because it’s tainted:

  • the check for hung uninterruptible tasks aborts early if the kernel is tainted with TAINT_DIE (i.e. an Oops or BUG() has occurred);
  • trace events and enums aren’t set up for tainted kernel modules where the taint could result in incorrect trace data; if a module is tainted for reasons other than being out-of-tree, staging, or unsigned, its state could be invalid and tracing it might cause more problems (think for example of modules which are force-inserted in spite of an ABI mismatch).
  • Thanks, that's really helpful
    – Traveller
    Aug 29, 2022 at 9:50

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .