Re: [PATCH] printk: handle blank console arguments passed in.

[Sergey Senozhatsky]

On (20/10/07 09:28), Petr Mladek wrote:
> 
> 		/*
> 		 * Dirty hack to prevent using any console with tty
> 		 * binding as a fallback and adding the empty
> 		 * name into console_cmdline array.
> 		 */
> 		preferred_console = MAX_CMDLINECONSOLES;

Let me dump my findings so far. I still don't understand what exactly
crashes the laptop (blank screen is not very helpful).

So, things start with the "preferred_console = -1". In console_setup()
we call __add_preferred_console(). Since we have no consoles, the
name matching loop is not executed, and console selection counter remains
at 0. After the loop, despite the fact that we don't have the console
(`name' is empty), we still set `preferred_console', to 0. This affects
register_console(). Since we have `preferred_console >= 0' we don't
execute the newcon->setup(), but, more importantly, we don't set the
newcon->flags |= CON_ENABLED. Now, we call try_enable_new_console():
since there are no consoles, the ->match() loop is not executed.
newcone does not have CON_ENABLED set, so try_enable_new_console()
returns -ENOENT. Both for user_specified=true and for fallback
user_specified=false cases. At this point we hit error-return path
from register_console() - we don't add newcon to the list of console
drivers. The console drivers list, thus, remains empty. So far so good.

Now. Things get strange in init/main.c

We have that kernel_init_freeable()->console_on_rootfs() control path.

console_on_rootfs() attempts to filp_open()->tty_open() /dev/console.
This ends up in printk's console_device(), which iterates the list of
console drivers and returns associated console->device back to tty. The
problem is that console drivers list is empty, so the function returns
NULL, and filp_open("/dev/console") fails. But the console_on_rootfs()
comment says that this function should never fail (!). This sort of
makes me wonder if "console=" is actually legal.

What this filp_open() failure means in particular, is that we never
create stdin/out/err fds, because we error-out and don't invoke
init_dup(file).

Things look different in older kernels. For instance, even in 5.4
the corresponding code looks as follows:

	/* Open the /dev/console on the rootfs, this should never fail */
	if (ksys_open((const char __user *) "/dev/console", O_RDWR, 0) < 0)
		pr_err("Warning: unable to open an initial console.\n");

	(void) ksys_dup(0);
	(void) ksys_dup(0);

Somehow, the fact that we don't init_dup(file) causes problems on my
laptop, but, at the moment, I can't tell exactly where. Perhaps more
experienced people will be like "darn, this is trivial, the problem is
here, here and there".

Hint: I can crash my laptop when I remove the "console=" boot param and
comment out init_dup(file) calls in console_on_rootfs().

I guess the problem is somewhat related to missing stdin/out/err fds.

Any ideas?

	-ss