Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.kernel > #61218 > unrolled thread

Bug#865153: reportbug: please include kernel taint flags

Back to article view | Back to linux.debian.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Bug#865153: reportbug: please include kernel taint flags Sandro Tosi <morph@debian.org> - 2018-06-17 21:30 +0200
    Bug#865153: reportbug: please include kernel taint flags Adam Borowski <kilobyte@angband.pl> - 2018-06-18 00:10 +0200
    Bug#865153: reportbug: please include kernel taint flags Ben Hutchings <ben@decadent.org.uk> - 2018-06-19 21:40 +0200

#61218 — Bug#865153: reportbug: please include kernel taint flags

Hello Adam,

On Mon, Jun 19, 2017 at 12:48 PM Adam Borowski <kilobyte@angband.pl> wrote:
>
> Package: reportbug
> Version: 7.1.7
> Severity: wishlist
>
> Hi!
> The "System Information" part of reportbug's output doesn't currently
> mention the kernel's taint state.  A bunch of these flags show that
> something on the system is going pretty badly, thus they're definitely
> of interest to someone reading such a bug report.
>
> The state can be read via /proc/sys/kernel/tainted which provides a decimal
> integer value, with bits meaning the following:
>
>        'P',    /* TAINT_PROPRIETARY_MODULE */
>        'F',    /* TAINT_FORCED_MODULE */
>        'S',    /* TAINT_CPU_OUT_OF_SPEC */
>        'R',    /* TAINT_FORCED_RMMOD */
>        'M',    /* TAINT_MACHINE_CHECK */
>        'B',    /* TAINT_BAD_PAGE */
>        'U',    /* TAINT_USER */
>        'D',    /* TAINT_DIE */
>        'A',    /* TAINT_OVERRIDDEN_ACPI_TABLE */
>        'W',    /* TAINT_WARN */
>        'C',    /* TAINT_CRAP */
>        'I',    /* TAINT_FIRMWARE_WORKAROUND */
>        'O',    /* TAINT_OOT_MODULE */
>        'E',    /* TAINT_UNSIGNED_MODULE */
>        'L',    /* TAINT_SOFTLOCKUP */
>        'K',    /* TAINT_LIVEPATCH */

this seems to be defined at
https://github.com/torvalds/linux/blob/master/include/linux/kernel.h#L549
which saw 2 lines added 2 months ago, and one 7 months ago (ok it's
not much, as previous changes were 4 years ago, but still since you
can install a custom kernel in stable, it means reportbug will not be
able to report correct information). i'm kinda at uneasy to add the
decoding of the bit string in reportbug if this will change often.

i think it would be ok to have an external tool that could produce the
tainted information parsing the header files and the tainted file, and
then include this tool output in reportbug systems information
section.

adding debian-kernel@l.d.o to gather some of their insight on the matter too

-- 
Sandro "morph" Tosi
My website: http://sandrotosi.me/
Me at Debian: http://wiki.debian.org/SandroTosi
G+: https://plus.google.com/u/0/+SandroTosi

[toc] | [next] | [standalone]

#61221

On Sun, Jun 17, 2018 at 03:17:38PM -0400, Sandro Tosi wrote:
> On Mon, Jun 19, 2017 at 12:48 PM Adam Borowski <kilobyte@angband.pl> wrote:
> > [Add kernel taint state to reportbug]

> > The state can be read via /proc/sys/kernel/tainted which provides a decimal
> > integer value, with bits meaning the following:
> >
> >        'P',    /* TAINT_PROPRIETARY_MODULE */
> >        'F',    /* TAINT_FORCED_MODULE */
> >        'S',    /* TAINT_CPU_OUT_OF_SPEC */
> > [...]
> 
> this seems to be defined at
> https://github.com/torvalds/linux/blob/master/include/linux/kernel.h#L549
> which saw 2 lines added 2 months ago, and one 7 months ago (ok it's
> not much, as previous changes were 4 years ago, but still since you
> can install a custom kernel in stable, it means reportbug will not be
> able to report correct information). i'm kinda at uneasy to add the
> decoding of the bit string in reportbug if this will change often.

You can show unknown flags as bit numbers, that's somewhat unsightly but
conveys all required information.  I'd say the benefit of showing known
flags (ie, the vast majority of cases) is worth having to update the list
from time to time.
 
> i think it would be ok to have an external tool that could produce the
> tainted information parsing the header files and the tainted file, and
> then include this tool output in reportbug systems information
> section.

If you mean trying to get data from the locally installed kernel, this is
not going to work.  The mapping of bits to letters comes from a file that's
not exported in the headers -- and even if it was, unless you use dkms,
there's little point in installing headers for the exact kernel you have.

If you mean parsing the kernel's source at build time, that would work.
You need actual kernel source rather than just headers, though.

> adding debian-kernel@l.d.o to gather some of their insight on the matter too

I asked on OFTC/#kernelnewbies, was told that manual updates require so
little work that it's a waste to write any complex automated machinery.


Meow!
-- 
⢀⣴⠾⠻⢶⣦⠀ There's an easy way to tell toy operating systems from real ones.
⣾⠁⢰⠒⠀⣿⡁ Just look at how their shipped fonts display U+1F52B, this makes
⢿⡄⠘⠷⠚⠋⠀ the intended audience obvious.  It's also interesting to see OSes
⠈⠳⣄⠀⠀⠀⠀ go back and forth wrt their intended target.

[toc] | [prev] | [next] | [standalone]

#61228

[Multipart message — attachments visible in raw view] — view raw

On Sun, 2018-06-17 at 15:17 -0400, Sandro Tosi wrote:
> Hello Adam,
> 
> On Mon, Jun 19, 2017 at 12:48 PM Adam Borowski <kilobyte@angband.pl> wrote:
> > 
> > Package: reportbug
> > Version: 7.1.7
> > Severity: wishlist
> > 
> > Hi!
> > The "System Information" part of reportbug's output doesn't currently
> > mention the kernel's taint state.  A bunch of these flags show that
> > something on the system is going pretty badly, thus they're definitely
> > of interest to someone reading such a bug report.
[...]
> this seems to be defined at
> https://github.com/torvalds/linux/blob/master/include/linux/kernel.h#L549
> which saw 2 lines added 2 months ago, and one 7 months ago (ok it's
> not much, as previous changes were 4 years ago, but still since you
> can install a custom kernel in stable, it means reportbug will not be
> able to report correct information). i'm kinda at uneasy to add the
> decoding of the bit string in reportbug if this will change often.
> 
> i think it would be ok to have an external tool that could produce the
> tainted information parsing the header files and the tainted file, and
> then include this tool output in reportbug systems information
> section.
>
> adding debian-kernel@l.d.o to gather some of their insight on the matter too

Kernel taint flags were introduced in 2002 and since then no flags have
ever been deleted or renumbered (although one flag was renamed to be
more general).  So I think that this is quite a stable interface.  For
any new and unknown flag, you could report it by number e.g. print
8393216 (bits 9, 12, 23 set) as "W O [23]".

Ben.

-- 
Ben Hutchings
Klipstein's 4th Law of Prototyping and Production:
                               A fail-safe circuit will destroy others.

[toc] | [prev] | [standalone]

Back to top | Article view | linux.debian.kernel

csiph-web