linux-kernel - Re: [PATCHv3 0/9] Mark literal strings in __init / _

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: <20140822082459.GA8771@gmail.com>
Date:	Fri, 22 Aug 2014 10:24:59 +0200
From:	Ingo Molnar <mingo@...nel.org>
To:	Mathias Krause <minipli@...glemail.com>
Cc:	Andrew Morton <akpm@...ux-foundation.org>,
	Thomas Gleixner <tglx@...utronix.de>,
	Ingo Molnar <mingo@...hat.com>,
	"H. Peter Anvin" <hpa@...or.com>, Joe Perches <joe@...ches.com>,
	Rasmus Villemoes <linux@...musvillemoes.dk>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	Linus Torvalds <torvalds@...ux-foundation.org>
Subject: Re: [PATCHv3 0/9] Mark literal strings in __init / __exit code


* Mathias Krause <minipli@...glemail.com> wrote:

> > It feels like a burdensome hack that kernel developers are 
> > forced to use different printing facilities, depending on 
> > the life cycle of a method. We want to simplify init 
> > annotations, we don't want to complicate them!
> 
> Does this:
> 
>     pi_info("mkiss: AX.25 Multikiss, Hans Albas PE1AYX\n");
> 
> really look more complicated compared to this?:
> 
>     static const char banner[] __initconst = KERN_INFO \
>         "mkiss: AX.25 Multikiss, Hans Albas PE1AYX\n";
>     printk(banner);
> 
> The latter can be found in drivers/net/hamradio/mkiss.c. Aged 
> code, admitted. But we have a few more of those and the 
> pi_info() looks way more appealing to me by doing the very 
> same thing ;)

My point is that both are complicated, compared to using the 
regular printk() variants.

In general printk()s should not be aware of what function 
context they are in.

> > And if tooling isn't ready for this, then wouldn't the 
> > right solution be to improve tooling - instead of 
> > complicating the kernel?
> 
> Plugin based approaches for this have been mentioned before 
> but those suffer from the same "global view" problem. So, 
> IMHO it's not that easy to solve it at the toolchain level. 

It might be solved via a regular tooling feature, or via 
tooling extension based on plugins.

Regardless of how it's implemented on the tooling side, my 
point remains: this kind of optimization is done on the tooling 
side in a natural fashion, while it's an ongoing maintenance 
concern on the kernel side.

So it should be done on the tooling side, especially as the 
benefits appear to be marginal.

Thanks,

	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/