linux-kernel - Re: [PATCH 0/6] loglevel=pci:8,acpi:8,apic=8 support v5

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20080917092526.GC3770@x200.localdomain>
Date:	Wed, 17 Sep 2008 13:25:26 +0400
From:	Alexey Dobriyan <adobriyan@...il.com>
To:	Ingo Molnar <mingo@...e.hu>
Cc:	Yinghai Lu <yhlu.kernel@...il.com>,
	Thomas Gleixner <tglx@...utronix.de>,
	"H. Peter Anvin" <hpa@...or.com>,
	Andrew Morton <akpm@...ux-foundation.org>,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH 0/6] loglevel=pci:8,acpi:8,apic=8 support v5

On Wed, Sep 17, 2008 at 10:47:54AM +0200, Ingo Molnar wrote:
> 
> * Alexey Dobriyan <adobriyan@...il.com> wrote:
> 
> > On Wed, Sep 17, 2008 at 12:10:09AM -0700, Yinghai Lu wrote:
> > >     KERN_PCI
> > >     KERN_ACPI
> > > v4: fix some checkpatch error and warning
> > > v5: add default with DEFINE_LOGLEVE_SETUP_DEF
> > >     KERN_APIC
> > > 
> > > usage:
> > > 	in .h to have
> > > 		#define KERN_PCI "<pci>"
> > > 	in .c to have
> > > 		DEFINE_LOGLEVEL_SETUP(pci, KERN_PCI, "pci:");
> > > 	then could use
> > > 		printk(KERN_DEBUG KERN_PCI fmt, ...);
> > > 	and command line
> > > 		loglevel=3,pci:8
> > > 
> > > you can add different printk to different files of one subsys if you like
> > > not just one susbsys one tag, and don't need to update kernel.h to add more tags
> > 
> > I think all of this is overdesigned and stupid.
> > 
> > People expecting that loglevels are exactly right so they can calm 
> > messages are like security-savvy people who expect all security 
> > relevant bugfixes carry CVE tag.
> > 
> > grep says there are 50757 printk calls, only 32129 of them carry KERN_ 
> > tag.
> >
> > Oh, and new and improved logs:
> > 
> > 	[    0.340326] pci 0000:00:01.0: PME# supported from D0 D3hot D3cold
> > 	[    0.340326] pci 0000:00:01.0: PME# disabled
> > 	[    0.340326] <pci>PCI: 0000:00:1a.0 reg 20 io port: [dc00, dc1f]
> > 	[    0.340413] <pci>PCI: 0000:00:1a.1 reg 20 io port: [e000, e01f]
> > 	[    0.340549] <pci>PCI: 0000:00:1a.7 reg 10 32bit mmio: [febffc00, febfffff]
> > 		       ^^^^^^^^^
> > How this can be an improvement for those who boot with ignore_loglevel,
> > I don't know.
> 
> the subsystem tags should be cut out by dmesg by default, just like the 
> normal <1> tags are cut out.

Or just leave ACPI:, PCI:. Tags are already in place in some sense.

> about your general point: it's valid observations. The idea would be to 
> end this never ending unstable conflict of people adding printks for 
> debug reasons versus people removing printks who'd like to have a nice 
> looking bootup log.

Simply nice looking log is irrational. I can understand if by default
messages do not fit into printk buffer before userspace can save them.
This is indeed harmful and loses information.

OTOH, all these loglevel games ultimately lead to missed messages (by design).
I remember myself wasting time debugging wrong path simply because box
wasn't booted with ignore_loglevel and critical debugging printk wasn't on
serial console, but only in dmesg.

So, in some cases useless information will not be shown, but in some
absolutely critical information will not be shown.

> Both point of views are correct in different usecases - and IMO the best 
> solution is the consolidation hpa suggested and what Yinghai is working 
> towards: to replace all the current ad-hoc debug printouts (with 
> different switchlets strewn all across the kernel) with an ASCII based 
> generic printk facility and a generic boot line option.

> people adding printks without any KERN_ tag is fine -

According to checkpatch.pl, it isn't.

> this facility is  only interesting to subsystems who'd like to make use
> of it. (core code,  ec. - the items that have a disproportionate weight
> in terms of system  stability, and which thus have a disproportionate
> need to stay  debuggable and regression-free)
> 
> [ and we also need a dynamic facility to change the filters via debugfs 
>   btw - it should be possible to modify these printk filters after 
>   bootup, runtime. Many subsystems have debug printks that make sense to 
>   enable/disable after the system has booted up. ]
> 
> and it's bad and a showstopper if the default output of 'dmesg' 
> degrades, like your noticed - those are bugs in the concept and need to 
> be fixed.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/