cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
Highlighted
Explorer
Explorer
30,844 Views
Registered: ‎10-08-2016

Loading out-of-tree module taints kernel; 2017.3

Jump to solution

I'm upgrading from Petalinux 2016.4 to 2017.3 and one of the elements of the upgrade is a DMA Proxy driver.  I got no errors at build time, and at runtime running "modprobe dma-proxy" leaves two entries in the /dev folder that look right, and the sequence of printk messages displayed by dmesg look right except for one: Loading out-of-tree module taints kernel.  Is this something to worry about?  I don't know if I always got it with 2016.4 and just never noticed it.  Is there a way to eliminate it?

0 Kudos
1 Solution

Accepted Solutions
Highlighted
Mentor
Mentor
33,310 Views
Registered: ‎02-24-2014

I have a box that does this too..    so I looked it up and found this excellent explanation:

 

When the kernel is tainted, it means that it is in a state that is not supported by the community. Most kernel developers will ignore bug reports involving tainted kernels, and community members may ask that you correct the tainting condition before they can proceed with diagnosing problems related to the kernel. In addition, some debugging functionality and API calls may be disabled when the kernel is tainted.

In most cases involving proprietary drivers, you can safely ignore the taint condition, but some scenarios which cause the kernel to become tainted may be indicative of serious system problems.

The feature is intended to identify conditions which may make it difficult to properly troubleshoot a kernel problem. For example, the loading of a proprietary module can make kernel debug output unreliable because kernel developers don't have access to the module's source code and therefore cannot determine what the module may have done to the kernel. Likewise, if the kernel had previously experienced an error condition or if a serious hardware error had occurred, the debug information generated by the kernel may not be reliable.

The kernel may become tainted for any of several reasons, including (but not limited to) the following:

  • The use of a proprietary (or non-GPL-compatible) kernel module—this is the most common cause of tainted kernels and usually results from loading proprietary NVIDIA or AMD video drivers
  • The use of stagingdrivers, which are part of the kernel source code but are not fully tested
  • The use of out-of-treemodules that are not included with the Linux kernel source code
  • Forcible loading or unloading of a kernel module (such as forcibly inserting a module not built for the current version of the kernel)
  • The use of an SMP (multiprocessor) kernel on certain unsupported uniprocessor CPUs, primarily older AMD Athlon processors
  • Overriding of the ACPIDSDT, sometimes needed to correct for power-management bugs (see here for details)
  • Certain critical error conditions, such as machine check exceptionsand kernel oopses
  • Certain serious bugs in the system firmware (BIOS, UEFI) which the kernel must work around

 

Each of these conditions is represented by a particular flag in the kernel. Some Linux vendors, such as SUSE, add additional taint flags to indicate conditions such as loading a module that is not supported by the vendor.

More information is available in the kernel documentation. The taint flags listed there are (with _ a stand-in for 'blank')

  • G|P: G if all modules loaded have a GPL or compatible license, otherwise a proprietary module has been loaded. Modules without a MODULE_LICENSE or with a MODULE_LICENSE that is not recognised by insmod as GPL compatible are assumed to be proprietary.
  • F|_: if any module was force loaded by "insmod -f" otherwise if all modules were loaded normally.
  • S|_: if the oops occurred on an SMP kernel running on hardware that hasn't been certified as safe to run multiprocessor. Currently this occurs only on various Athlons that are not SMP capable.
  • R|_: if a module was force unloaded by rmmod -f, otherwise if all modules were unloaded normally.
  • M|_: if any processor has reported a Machine Check Exception, otherwise no Machine Check Exceptions have occurred.
  • B|_: if a page-release function has found a bad page reference or some unexpected page flags.
  • U|_: if a user or user application specifically requested that the Tainted flag be set.
  • D|_: if the kernel has died recently, i.e. there was an OOPS or BUG.
  • A|_: if the ACPI table has been overridden.
  • W|_: if a warning has previously been issued by the kernel (Though some warnings may set more specific taint flags.)
  • C|_: if a staging driver has been loaded.
  • I|_: if the kernel is working around a severe bug in the platform firmware (BIOS or similar).
  • O|_: if an externally-built ("out-of-tree") module has been loaded.
  • E|_: if an unsigned module has been loaded in a kernel supporting module signature.
  • L|_: if a soft lockup has previously occurred on the system.
  • K|_: if the kernel has been live patched.
Don't forget to close a thread when possible by accepting a post as a solution.

View solution in original post

2 Replies
Highlighted
Mentor
Mentor
33,311 Views
Registered: ‎02-24-2014

I have a box that does this too..    so I looked it up and found this excellent explanation:

 

When the kernel is tainted, it means that it is in a state that is not supported by the community. Most kernel developers will ignore bug reports involving tainted kernels, and community members may ask that you correct the tainting condition before they can proceed with diagnosing problems related to the kernel. In addition, some debugging functionality and API calls may be disabled when the kernel is tainted.

In most cases involving proprietary drivers, you can safely ignore the taint condition, but some scenarios which cause the kernel to become tainted may be indicative of serious system problems.

The feature is intended to identify conditions which may make it difficult to properly troubleshoot a kernel problem. For example, the loading of a proprietary module can make kernel debug output unreliable because kernel developers don't have access to the module's source code and therefore cannot determine what the module may have done to the kernel. Likewise, if the kernel had previously experienced an error condition or if a serious hardware error had occurred, the debug information generated by the kernel may not be reliable.

The kernel may become tainted for any of several reasons, including (but not limited to) the following:

  • The use of a proprietary (or non-GPL-compatible) kernel module—this is the most common cause of tainted kernels and usually results from loading proprietary NVIDIA or AMD video drivers
  • The use of stagingdrivers, which are part of the kernel source code but are not fully tested
  • The use of out-of-treemodules that are not included with the Linux kernel source code
  • Forcible loading or unloading of a kernel module (such as forcibly inserting a module not built for the current version of the kernel)
  • The use of an SMP (multiprocessor) kernel on certain unsupported uniprocessor CPUs, primarily older AMD Athlon processors
  • Overriding of the ACPIDSDT, sometimes needed to correct for power-management bugs (see here for details)
  • Certain critical error conditions, such as machine check exceptionsand kernel oopses
  • Certain serious bugs in the system firmware (BIOS, UEFI) which the kernel must work around

 

Each of these conditions is represented by a particular flag in the kernel. Some Linux vendors, such as SUSE, add additional taint flags to indicate conditions such as loading a module that is not supported by the vendor.

More information is available in the kernel documentation. The taint flags listed there are (with _ a stand-in for 'blank')

  • G|P: G if all modules loaded have a GPL or compatible license, otherwise a proprietary module has been loaded. Modules without a MODULE_LICENSE or with a MODULE_LICENSE that is not recognised by insmod as GPL compatible are assumed to be proprietary.
  • F|_: if any module was force loaded by "insmod -f" otherwise if all modules were loaded normally.
  • S|_: if the oops occurred on an SMP kernel running on hardware that hasn't been certified as safe to run multiprocessor. Currently this occurs only on various Athlons that are not SMP capable.
  • R|_: if a module was force unloaded by rmmod -f, otherwise if all modules were unloaded normally.
  • M|_: if any processor has reported a Machine Check Exception, otherwise no Machine Check Exceptions have occurred.
  • B|_: if a page-release function has found a bad page reference or some unexpected page flags.
  • U|_: if a user or user application specifically requested that the Tainted flag be set.
  • D|_: if the kernel has died recently, i.e. there was an OOPS or BUG.
  • A|_: if the ACPI table has been overridden.
  • W|_: if a warning has previously been issued by the kernel (Though some warnings may set more specific taint flags.)
  • C|_: if a staging driver has been loaded.
  • I|_: if the kernel is working around a severe bug in the platform firmware (BIOS or similar).
  • O|_: if an externally-built ("out-of-tree") module has been loaded.
  • E|_: if an unsigned module has been loaded in a kernel supporting module signature.
  • L|_: if a soft lockup has previously occurred on the system.
  • K|_: if the kernel has been live patched.
Don't forget to close a thread when possible by accepting a post as a solution.

View solution in original post

Highlighted
Explorer
Explorer
30,764 Views
Registered: ‎10-08-2016

Thanks.  Looks like I just learn to live with it.

0 Kudos