From: Petr Mladek <pmladek@suse.com>
To: Sergey Senozhatsky <sergey.senozhatsky@gmail.com>
Cc: Guenter Roeck <linux@roeck-us.net>,
Shreyas Joshi <shreyas.joshi@biamp.com>,
rostedt@goodmis.org, shreyasjoshi15@gmail.com,
linux-kernel@vger.kernel.org,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
Linus Torvalds <torvalds@linux-foundation.org>
Subject: Re: [PATCH] printk: handle blank console arguments passed in.
Date: Thu, 8 Oct 2020 11:01:55 +0200 [thread overview]
Message-ID: <20201008090155.GB16837@alley> (raw)
In-Reply-To: <20201008055238.GA554@jagdpanzerIV.localdomain>
On Thu 2020-10-08 14:52:38, Sergey Senozhatsky wrote:
> On (20/10/08 01:29), Sergey Senozhatsky wrote:
> > On (20/10/07 08:57), Guenter Roeck wrote:
> > > On 10/7/20 5:30 AM, Sergey Senozhatsky wrote:
> >
> > [..]
> >
> > > I can see to options: Link /dev/console to /dev/null if there is no console,
> > > or do something like
> > >
> > > if (IS_ERR(file)) {
> > > pr_warn("Warning: unable to open an initial console.\n");
> > > file = filp_open("/dev/null", O_RDWR, 0);
> > > if (IS_ERR(file))
> > > return;
> > > }
> >
> > As far as I can tell, /dev/null does not exist yet on this stage
> > (at least not in my system). But generally the idea looks interesting.
>
> Hmm. How about this. console= is undocumented and unspecified - it
> may work sometimes or it may kill the system (and theoretically even
> corrupt some files, depending on what fd 1 and fd 2 point to). So
> maybe we can document console= and handle it in printk, rather than
> somewhere deep in init/main.c
>
> IOW add one more flag (yeah, I know) and set it when console_setup()
> sees console= boot param. The idea is allow console registration,
> but all consoles should be disabled (cleared CON_ENABLED bit). This
> would be easier to document, at least.
>
> Schematically:
>
> ---
> diff --git a/kernel/printk/printk.c b/kernel/printk/printk.c
> index 929e86a01148..b71ff9d87693 100644
> --- a/kernel/printk/printk.c
> +++ b/kernel/printk/printk.c
> @@ -281,6 +281,7 @@ static struct console_cmdline console_cmdline[MAX_CMDLINECONSOLES];
>
> static int preferred_console = -1;
> static bool has_preferred_console;
> +static bool mute_consoles = false;
> int console_set_on_cmdline;
> EXPORT_SYMBOL(console_set_on_cmdline);
>
> @@ -2141,6 +2142,9 @@ static int __add_preferred_console(char *name, int idx, char *options,
> struct console_cmdline *c;
> int i;
>
> + if (mute_consoles)
> + return;
> +
> /*
> * See if this tty is not yet registered, and
> * if we have a slot free.
Interesting idea. Well, it looks like yet another mess:
+ it would show the consoles in /proc/consoles
even thought they will be basically unusable
+ it is yet another way to affect the amount of messages
on console. We already have console_loglevel, ignore_loglevel.
+ this effect is far from obvious when using console=""
IMHO, we should try to understand why it actually crashes first.
It might help to solve the problem some cleaner way.
Thanks a lot for digging into it.
Best Regards,
Petr
next prev parent reply other threads:[~2020-10-08 9:01 UTC|newest]
Thread overview: 40+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-03-09 5:29 [PATCH] printk: handle blank console arguments passed in Shreyas Joshi
2020-03-17 1:34 ` Shreyas Joshi
2020-03-17 1:39 ` Steven Rostedt
2020-03-17 2:01 ` Sergey Senozhatsky
2020-03-17 2:17 ` Shreyas Joshi
2020-03-17 8:22 ` Sergey Senozhatsky
2020-05-22 6:46 ` Shreyas Joshi
2020-05-22 6:53 ` Shreyas Joshi
2020-05-22 10:00 ` Petr Mladek
2020-10-06 2:59 ` Sergey Senozhatsky
2020-10-06 3:35 ` Guenter Roeck
2020-10-06 5:08 ` Greg Kroah-Hartman
2020-10-06 11:17 ` Guenter Roeck
2020-10-06 6:59 ` Sergey Senozhatsky
2020-10-06 9:54 ` Petr Mladek
2020-10-06 13:33 ` Sergey Senozhatsky
2020-10-06 14:22 ` Guenter Roeck
2020-10-06 16:08 ` Sergey Senozhatsky
2020-10-06 9:52 ` Petr Mladek
2020-10-06 10:45 ` Guenter Roeck
2020-10-06 13:43 ` Petr Mladek
2020-10-06 16:35 ` Petr Mladek
2020-10-06 17:15 ` Sergey Senozhatsky
2020-10-07 7:28 ` Petr Mladek
2020-10-07 12:30 ` Sergey Senozhatsky
2020-10-07 14:39 ` Sergey Senozhatsky
2020-10-07 15:57 ` Guenter Roeck
2020-10-07 16:29 ` Sergey Senozhatsky
2020-10-08 5:52 ` Sergey Senozhatsky
2020-10-08 9:01 ` Petr Mladek [this message]
2020-10-08 10:56 ` Sergey Senozhatsky
2020-10-08 12:05 ` Sergey Senozhatsky
2020-10-22 11:38 ` Petr Mladek
2020-10-22 13:32 ` Sergey Senozhatsky
2020-10-08 8:50 ` Petr Mladek
2020-10-08 12:20 ` Sergey Senozhatsky
2020-10-08 12:37 ` Sergey Senozhatsky
2020-05-15 15:24 ` Petr Mladek
2020-05-20 11:50 ` Sergey Senozhatsky
2020-05-22 6:40 ` Shreyas Joshi
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20201008090155.GB16837@alley \
--to=pmladek@suse.com \
--cc=gregkh@linuxfoundation.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux@roeck-us.net \
--cc=rostedt@goodmis.org \
--cc=sergey.senozhatsky@gmail.com \
--cc=shreyas.joshi@biamp.com \
--cc=shreyasjoshi15@gmail.com \
--cc=torvalds@linux-foundation.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox