Red Hat Bugzilla – Bug 1214730
abrt reporting kernel is tainted when it is not
Last modified: 2018-05-31 15:43:17 EDT
Description of problem: In abrt oops data, the kernel is reports as tainted, though this is a fresh 7.1 install with nothing else added. dmesg:[ 7019.437238] CPU: 1 PID: 14620 Comm: kworker/u17:0 Not tainted 3.10.0-229.1.2.el7.x86_64 #1 not-reportable:A kernel problem occurred, but your kernel has been tainted (flags:GW). Kernel maintainers are unable to diagnose tainted reports. $ cat kernel_tainted_long Proprietary module has not been loaded. Taint on warning. $ cat kernel_tainted_short GW From the backtrace: CPU: 1 PID: 14620 Comm: kworker/u17:0 Tainted: G W -------------- 3.10.0-22 9.1.2.el7.x86_64 #1 Version-Release number of selected component (if applicable): 7.1 (3.10.0-229.1.2.el7.x86_64) How reproducible: - Unknown Expected results: - kernel not reported to be tainted if it is truly not. Additional info: - attaching abrt tarball.
iirc, ABRT won't report on a tainted kernel by default. If there was a kernel warning (and it looks as if there was one regarding bluetooth issues), then that would taint the kernel.
(In reply to Charles Haithcock from comment #3) > iirc, ABRT won't report on a tainted kernel by default. If there was a > kernel warning (and it looks as if there was one regarding bluetooth > issues), then that would taint the kernel. Correct and W is a taint flag [1][2]. 1: http://abrt.readthedocs.org/en/latest/faq.html#what-is-tainted-kernel-and-why-is-my-kernel-tainted 2: " * 'W' - Taint on warning." - http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/kernel/panic.c#n245
(In reply to Charles Haithcock from comment #3) > iirc, ABRT won't report on a tainted kernel by default. If there was a > kernel warning (and it looks as if there was one regarding bluetooth > issues), then that would taint the kernel. This explanation is correct. Closing as not a bug.
Just because there is a taint flag set doesn't mean the problem shouldn't be reported. We want to avoid reporting problems when proprietary modules are loaded in the kernel, for instance. That's a valid reason abrt to refuse reporting an issue. The W flag means there was a kernel problem. Kernel problems should be reported.
It it easy fix to enable reporting oopses with arbitrary tainted flags, however I examined this deeply and discovered interesting facts. * as W taint flag means warning has already occured, it is not interesting for reporting W tainted oopses because we only care about 1 occurence, which was probably already filed by abrt, so reporting W flaged oopses wouldn't even help resolving particular problem and so makes no sense. (https://bugzilla.redhat.com/show_bug.cgi?id=786280#c2) * enabling reporting of W tainted oopses is in direct contradiction with resolution of bug 786280, which prevents flood of useles identical or follow-on reports. My conclusion of these two facts is not to enable reporting of W tainted oopses. * Regarding G flag, it occurs only besides other taint flags, without W it makes no sense too. So lets move a step back, to bug opening comment. In opening message is written: "In abrt oops data, the kernel is reports as tainted, though this is a fresh 7.1 install with nothing else added." this is not in contradiction with content of not-reportable: "A kernel problem occurred, but your kernel has been tainted (flags:GW). Kernel maintainers are unable to diagnose tainted reports." That kernel is tainted, doesn't imply something had to be loaded into it, however I agree that this message can be confusing in this situation. I propose to extend the not-reportable message to this form: " A kernel problem occurred, but your kernel has been tainted (flags:GW). Kernel maintainers are unable to diagnose tainted reports. Kernel may become tainted for one of following reasons: * The use of a proprietary (or non-GPL-compatible) kernel module. * The use of staging drivers, which are part of the kernel source code but are not fully tested. * The use of out-of-tree modules 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 ACPI DSDT, sometimes needed to correct for power-management bugs. * Certain critical error conditions, such as machine check exceptions and kernel oopses. * Certain serious bugs in the system firmware (BIOS, UEFI) which the kernel must work around. "
Pull request: https://github.com/abrt/abrt/pull/1245
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://access.redhat.com/errata/RHBA-2018:0949