From: Sergey Senozhatsky <sergey.senozhatsky.work@gmail.com>
To: Hans de Goede <hdegoede@redhat.com>
Cc: Sergey Senozhatsky <sergey.senozhatsky.work@gmail.com>,
Thomas Gleixner <tglx@linutronix.de>,
Ingo Molnar <mingo@redhat.com>, "H . Peter Anvin" <hpa@zytor.com>,
Sergey Senozhatsky <sergey.senozhatsky@gmail.com>,
x86@kernel.org, linux-kernel@vger.kernel.org,
Steven Rostedt <rostedt@goodmis.org>,
Petr Mladek <pmladek@suse.com>,
Maninder Singh <maninder1.s@samsung.com>
Subject: Re: [PATCH 4.19 regression fix] printk: For early boot messages check loglevel when flushing the buffer
Date: Wed, 5 Sep 2018 14:36:09 +0900 [thread overview]
Message-ID: <20180905053609.GA19936@jagdpanzerIV> (raw)
In-Reply-To: <93901f2b-91ad-a910-7031-0040b827a3af@redhat.com>
On (09/05/18 06:53), Hans de Goede wrote:
> >
> > Do you use earlycon?
>
> No, I'm seeing this with the regular/normal console stuff.
OK, thanks for the report!
So I think that your case is CON_PRINTBUFFER related as well. We have
a number of logbuf messages before we parse quiet and console_loglevel.
Those messages pass the suppress_message() test. Then when we finally
register a CON_PRINTBUFFER console we update console_loglevel and flush
all logbuf messages, but console_loglevel does not matter anymore.
> > > This commit fixes this by setting a new LOG_CHK_LEVEL on early boot
> > > messages and doing the loglevel check for these while flushing as before.
> > >
> >
> > Hmm, OK, chances are we need to re-think 375899cddcbb. It might be
> > the case that we sort of broke CON_PRINTBUFFER handling.
> >
> > console_loglevel = CONSOLE_LOGLEVEL_MOTORMOUTH
> > register CON_PRINTBUFFER console
> > -> no debug output
> >
> > So I think that when console_unlock() re-flushes already seen logbuf
> > messages to a newly registered exclusive [CON_PRINTBUFFER] console we
> > probably need to look at the current console_loglevel in console_unlock()
> > loop.
>
> So if it breaks quiet and the above use-case maybe we should revert
> 375899cddcbb for now?
Maybe all we need to do is to re-introduce suppress_message() check to
console_unlock() when we have exclusive console set (IOW, when we re-flush
logbuf messages to a CON_PRINTBUFFER console).
Just a demonstration of the idea. It does not look very good, tho.
I'd rather have just one suppress_message_printing() in printk code.
// This is not a proposed patch, hence the 80-cols violation.
---
diff --git a/kernel/printk/printk.c b/kernel/printk/printk.c
index c036f128cdc3..231ac18423e1 100644
--- a/kernel/printk/printk.c
+++ b/kernel/printk/printk.c
@@ -2416,7 +2416,7 @@ void console_unlock(void)
break;
msg = log_from_idx(console_idx);
- if (msg->flags & LOG_NOCONS) {
+ if (msg->flags & LOG_NOCONS || (exclusive_console && suppress_message_printing(msg->level))) {
/*
* Skip record if !ignore_loglevel, and
* record has level above the console loglevel.
---
We are still early in 4.19 -rcs, let's wait a bit and hear from Steven
and Petr, they have bright ideas oftentimes.
-ss
next prev parent reply other threads:[~2018-09-05 5:36 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-09-04 18:01 [PATCH 4.19 regression fix] printk: For early boot messages check loglevel when flushing the buffer Hans de Goede
2018-09-05 2:35 ` Sergey Senozhatsky
2018-09-05 4:53 ` Hans de Goede
2018-09-05 5:36 ` Sergey Senozhatsky [this message]
2018-09-05 5:51 ` Sergey Senozhatsky
2018-09-05 8:33 ` Sergey Senozhatsky
2018-09-05 11:02 ` Petr Mladek
2018-09-05 15:20 ` Hans de Goede
2018-09-06 14:31 ` Petr Mladek
2018-09-06 7:29 ` Sergey Senozhatsky
2018-09-06 14:28 ` Petr Mladek
2018-09-07 4:21 ` Sergey Senozhatsky
2018-09-10 14:57 ` Petr Mladek
2018-09-10 15:02 ` Hans de Goede
2018-09-11 2:30 ` Sergey Senozhatsky
2018-09-11 8:47 ` Petr Mladek
2018-09-12 7:49 ` Sergey Senozhatsky
2018-09-12 13:33 ` Petr Mladek
2018-09-13 2:25 ` Sergey Senozhatsky
2018-09-06 14:34 ` kbuild test robot
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=20180905053609.GA19936@jagdpanzerIV \
--to=sergey.senozhatsky.work@gmail.com \
--cc=hdegoede@redhat.com \
--cc=hpa@zytor.com \
--cc=linux-kernel@vger.kernel.org \
--cc=maninder1.s@samsung.com \
--cc=mingo@redhat.com \
--cc=pmladek@suse.com \
--cc=rostedt@goodmis.org \
--cc=sergey.senozhatsky@gmail.com \
--cc=tglx@linutronix.de \
--cc=x86@kernel.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.