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: <20080917084754.GC24035@elte.hu>
Date:	Wed, 17 Sep 2008 10:47:54 +0200
From:	Ingo Molnar <mingo@...e.hu>
To:	Alexey Dobriyan <adobriyan@...il.com>
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

* 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.

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.

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 - 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.

	Ingo
--
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/