Re: [PATCH 2/2] printk: Only unregister boot consoles when necessary

[Andrew Morton]

On Thu, 29 Oct 2015 09:26:07 +0100 Thierry Reding <thierry.reding@xxxxxxxxx> wrote:

> From: Thierry Reding <treding@xxxxxxxxxx>
> 
> Boot consoles are typically replaced by proper consoles during the boot
> process. This can be problematic if the boot console data is part of the
> init section that is reclaimed late during boot. If the proper console
> does not register before this point in time, the boot console will need
> to be removed (so that the freed memory is not accessed), leaving the
> system without output for some time.
> 
> There are various reasons why the proper console may not register early
> enough, such as deferred probe or the driver being a loadable module. If
> that happens, there is some amount of time where no console messages are
> visible to the user, which in turn can mean that they won't see crashes
> or other potentially useful information.
> 
> To avoid this situation, only remove the boot console when it resides in
> the init section. Code exists to replace the boot console by the proper
> console when it is registered, keeping a seamless transition between the
> boot and proper consoles.

OK.

> --- a/kernel/printk/printk.c
> +++ b/kernel/printk/printk.c
> @@ -48,6 +48,7 @@
>  #include <linux/uio.h>
>  
>  #include <asm/uaccess.h>
> +#include <asm-generic/sections.h>
>  
>  #define CREATE_TRACE_POINTS
>  #include <trace/events/printk.h>
> @@ -2661,7 +2662,8 @@ static int __init printk_late_init(void)
>  
>  	for_each_console(con) {
>  		if (!keep_bootcon && con->flags & CON_BOOT) {
> -			unregister_console(con);
> +			if (init_section_contains(con, sizeof(*con)))
> +				unregister_console(con);
>  		}

It's a bit hacky.  It might be nicer to add a new CON_foo flag
specifying the treatment but a) there are waaay too many consoles in
the kernel and b) it's fragile to require every register_console()
caller to remember to do this, and to maintain the CON_foo as code
evolves.  So I guess we go with hacky.


There is no way in which a reader can work out why this code is here,
without forcing them to go off and wrestle with git-blame.  Can we
please add a comment to save them from this fate?
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/