linux-kernel - Re: [PATCH v2] early_printk: consolidate random copies of identical code

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: <5138EF7F.1050003@windriver.com>
Date:	Thu, 7 Mar 2013 14:50:23 -0500
From:	Paul Gortmaker <paul.gortmaker@...driver.com>
To:	Andrew Morton <akpm@...ux-foundation.org>
CC:	Mike Frysinger <vapier@...too.org>, Ingo Molnar <mingo@...nel.org>,
	Randy Dunlap <rdunlap@...radead.org>,
	<linux-kernel@...r.kernel.org>,
	Thomas Gleixner <tglx@...utronix.de>,
	Russell King <linux@....linux.org.uk>,
	Michal Simek <monstr@...str.eu>,
	Ralf Baechle <ralf@...ux-mips.org>,
	Benjamin Herrenschmidt <benh@...nel.crashing.org>,
	Paul Mundt <lethal@...ux-sh.org>,
	"David S. Miller" <davem@...emloft.net>,
	Chris Metcalf <cmetcalf@...era.com>,
	Richard Weinberger <richard@....at>
Subject: Re: [PATCH v2] early_printk: consolidate random copies of identical
 code

On 13-03-07 02:25 PM, Andrew Morton wrote:
> On Thu, 7 Mar 2013 14:15:54 -0500 Paul Gortmaker <paul.gortmaker@...driver.com> wrote:
> 
>> [v2: essentially unchanged since v1, so I've left the acked/reviewed
>>  tags.  There was a compile fail[1] for a randconfig with EARLY_PRINTK=y
>>  and PRINTK=n, because the early_console struct and early_printk calls
>>  were nested within an #ifdef CONFIG_PRINTK -- moving that whole block
>>  exactly as-is to be outside the #ifdef CONFIG_PRINTK fixes the randconfig
>>  and still works for everyday sane configs too.]
>>  [1] http://marc.info/?l=linux-next&m=136219350914998&w=2   
> 
> You did this:
> 
> --- a/kernel/printk.c~early_printk-consolidate-random-copies-of-identical-code-v2
> +++ a/kernel/printk.c
> @@ -759,29 +759,6 @@ module_param(ignore_loglevel, bool, S_IR
>  MODULE_PARM_DESC(ignore_loglevel, "ignore loglevel setting, to"
>  	"print all kernel messages to the console.");
>  
> -#ifdef CONFIG_EARLY_PRINTK
> -struct console *early_console;
> -
> -void early_vprintk(const char *fmt, va_list ap)
> -{
> -	if (early_console) {
> -		char buf[512];
> -		int n = vscnprintf(buf, sizeof(buf), fmt, ap);
> -
> -		early_console->write(early_console, buf, n);
> -	}
> -}
> -
> -asmlinkage void early_printk(const char *fmt, ...)
> -{
> -	va_list ap;
> -
> -	va_start(ap, fmt);
> -	early_vprintk(fmt, ap);
> -	va_end(ap);
> -}
> -#endif
> -
>  #ifdef CONFIG_BOOT_PRINTK_DELAY
>  
>  static int boot_delay; /* msecs delay after each printk during bootup */
> @@ -1743,6 +1720,29 @@ static size_t cont_print_text(char *text
>  
>  #endif /* CONFIG_PRINTK */
>  
> +#ifdef CONFIG_EARLY_PRINTK
> +struct console *early_console;
> +
> +void early_vprintk(const char *fmt, va_list ap)
> +{
> +	if (early_console) {
> +		char buf[512];
> +		int n = vscnprintf(buf, sizeof(buf), fmt, ap);
> +
> +		early_console->write(early_console, buf, n);
> +	}
> +}
> +
> +asmlinkage void early_printk(const char *fmt, ...)
> +{
> +	va_list ap;
> +
> +	va_start(ap, fmt);
> +	early_vprintk(fmt, ap);
> +	va_end(ap);
> +}
> +#endif
> +
>  static int __add_preferred_console(char *name, int idx, char *options,
>  				   char *brl_options)
>  {
> _
> 
> Problem is, that won't fix the various compilation problems we've had. 
> See yesterday's lkml thread "linux-next: build failure after merge of
> the final tree (akpm tree related)"

Thanks for the pointer -- I'd only found Randy's original report
and had not seen this yet.  I'll go build test on sparc and have
a look there.

This brings up a recurring question.  I was tempted to just go make
CONFIG_EARLY_PRINTK depend on CONFIG_PRINTK, but lately I've faced
pushback when trying to "fix" things like seeing ARM OMAP USB options
for an x86 build[1], and GOLDFISH virt drivers being offered even
when the end user already said no to GOLDFISH[2].

Do we want to use dependencies to reflect the real world layout of
platforms/systems, or do we want to go the minimal dependency
approach, where we are building sparc specific drivers on mips just
because we can?

I think the former is better from a user specific point of view, as
the maze of Kconfig is better as a tree topology with branches that
have clear dependencies that exclude them, versus it being a flat
monolithic space where anything can select anything.

Arguments I've heard for the latter seem to be developer centric
(i.e forcing wider build coverage on the population as a whole, etc)

Thanks,
Paul.

[1] https://lkml.org/lkml/2013/2/27/204
[2] http://marc.info/?l=linux-kernel&m=136198970523568&w=3


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