Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
Date:   Thu, 22 Oct 2020 22:32:28 +0900
From:   Sergey Senozhatsky <sergey.senozhatsky@gmail.com>
To:     Petr Mladek <pmladek@suse.com>
Cc:     Sergey Senozhatsky <sergey.senozhatsky@gmail.com>,
        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.
Message-ID: <20201022133228.GA160085@jagdpanzerIV.localdomain>
References: <24f7a6bc-c917-2bb7-0e86-9d729c18e812@roeck-us.net>
 <20201006134328.GD32369@alley>
 <20201006163514.GE32369@alley>
 <20201006171504.GA64770@jagdpanzerIV.localdomain>
 <20201007072853.GF32369@alley>
 <20201007123044.GA509@jagdpanzerIV.localdomain>
 <be66237b-e7b2-0321-c00c-cd6fba6e3b58@roeck-us.net>
 <20201007162942.GA440@jagdpanzerIV.localdomain>
 <20201008055238.GA554@jagdpanzerIV.localdomain>
 <20201022113805.GA32486@alley>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20201022113805.GA32486@alley>
Precedence: bulk

On (20/10/22 13:38), Petr Mladek wrote:
> > 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
> 
> I have dig more into it. If I get it correctly, /dev/console is really
> used as stdin, stdout, and stderr for the init process. It has been
> like this from the very beginning.
> 
> In theory, it might be possible to fallback into /dev/null. But it
> would not solve the problem when anyone tries to use /dev/console
> later.
> 
> IMHO, creating /dev/console really _should not_ fail. It means
> that we should register some console.

Yes, I didn't find out exactly why the kernel panics yet. Got
interrupted. What I did notice (when we don't have stdin/out/err)
was init process installing "/" as fd 0, and then doing things
like fprintf(stderr, "running early hook"), perhaps some of those
fprintf()-s end up in the wrong place.

> > 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.
> 
> It seems that introducing a new option/flag is the best solution
> after all. All other flags are manipulated on different situations
> and it would not be easy to define a sane behavior.
> 
> I like the proposed "mute_consoles". Well, I have it associated rather
> with CONSOLE_LOGLEVEL_SILENT than with disabled console.
> 
> I have played with it and am going to send two patches as RFC.

Cool, thanks. I'll reply to that RFC patch set; there are some
more ideas, that we can discuss.

	-ss