From: Benjamin Herrenschmidt <benh@kernel.crashing.org>
To: Petr Mladek <pmladek@suse.com>
Cc: Sergey Senozhatsky <sergey.senozhatsky.work@gmail.com>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH v3 2/3] printk: Fix preferred console selection with multiple matches
Date: Tue, 11 Feb 2020 16:33:57 +0100 [thread overview]
Message-ID: <52b18db7c4c74fc759bf455e7e4acfb1a404951b.camel@kernel.crashing.org> (raw)
In-Reply-To: <20200211144134.fyxxphyr32dkmhsw@pathway.suse.cz>
On Tue, 2020-02-11 at 15:41 +0100, Petr Mladek wrote:
>
> > diff --git a/kernel/printk/printk.c b/kernel/printk/printk.c
> > index 17602d7b7ffc..5cf47a7b880c 100644
> > --- a/kernel/printk/printk.c
> > +++ b/kernel/printk/printk.c
> > @@ -2674,8 +2679,13 @@ static int try_enable_new_console(struct console *newcon)
> > /*
> > * Some consoles, such as pstore and netconsole, can be enabled even
> > * without matching.
> > + *
> > + * Note: We only do this test on the !user_specified pass so that such
> > + * a statically enabled console that isn't user specified gets a chance
> > + * to have its match() or setup() function called on our second pass
> > + * through this function.
>
> I had some troubles to part the comment. I wonder if the following is
> more clear:
>
> * Accept pre-enabled consoles only when match() and setup()
> * was called.
Yeah the sentence is a bit convoluted, I agree. As for the fix, see
below
> And I would do the same check as in the for cycle:
>
> if (newcon->flags & CON_ENABLED && c->user_specified == user_specified)
> return 0;
Fair enough, this is simpler.
> With the above change:
>
> Reviewed-by: Petr Mladek <pmladek@suse.com>
>
> I could do the change when pushing if you agree and v4 is not needed
> for other reasons.
Of course. I'm travelling this week (which is why I somewhat rushed
sending you the patches last week, hence the glitches you noted), so I
won't have a chance to repost until sometime next week.
>
> PS: JFYI, I am going to look at the 3rd patch tomorrow. I have to go now.
No worries. It's not super important, it's a minor thing I noticed
while testing (when I artifically make my consoles not match to test
the "default" fallback). It's not directly related to the fix in patch
2, but is completely standlaone.
Cheers,
Ben.
next prev parent reply other threads:[~2020-02-11 15:34 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-02-06 4:02 Benjamin Herrenschmidt
2020-02-11 14:41 ` Petr Mladek
2020-02-11 15:33 ` Benjamin Herrenschmidt [this message]
2020-02-13 5:52 ` Sergey Senozhatsky
2020-02-13 8:39 ` Petr Mladek
2020-02-13 9:09 ` Sergey Senozhatsky
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=52b18db7c4c74fc759bf455e7e4acfb1a404951b.camel@kernel.crashing.org \
--to=benh@kernel.crashing.org \
--cc=linux-kernel@vger.kernel.org \
--cc=pmladek@suse.com \
--cc=sergey.senozhatsky.work@gmail.com \
/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
Powered by JetHome