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-arch" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
