From: Sergey Senozhatsky <sergey.senozhatsky.work@gmail.com>
To: Petr Mladek <pmladek@suse.com>
Cc: Sergey Senozhatsky <sergey.senozhatsky.work@gmail.com>,
Hans de Goede <hdegoede@redhat.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>,
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: Thu, 6 Sep 2018 16:29:40 +0900 [thread overview]
Message-ID: <20180906072940.GA382@jagdpanzerIV> (raw)
In-Reply-To: <20180905110207.rxy3upplgkjbk5oi@pathway.suse.cz>
On (09/05/18 13:02), Petr Mladek wrote:
> Note that the first registered console prints all messages
> even without this flag.
Hmm, OK, interesting point.
I assumed that the first console usually has CON_PRINTBUFFER bit set.
Or even a CON_PRINTBUFFER | CON_ANYTIME combo. E.g. 8250. It sort of
makes sense to have CON_PRINTBUFFER for the first console. Any later
consoles [e.g. fbcon, netcon] don't necessarily have CON_PRINTBUFFER.
So by the time we have callable console "quite" param should be already
parsed [except the earlycon case perhaps]:
kernel_init_freeable
do_one_initcall
register_console
happens after
setup_arch
parse_early_param
quiet_kernel/debug_kernel.
And
setup_arch
parse_early_param
quiet_kernel/debug_kernel
happens before
console_init
con_init
register_console.
And the first console has CON_PRINTBUFFER bit set. Well, just because
it sounds reasonable. Those were the main assumptions behind my code
snippet. Was any of those assumptions wrong?
> I played with another solution, see the patch below. It defines
> which messages have a valid NOCONS flag according to the msg_seq
> number. IMHO, it is a bit more straightforward but it is still
> a hack. I am not super happy about it.
I just skimmed through it, and probably missed some parts. But I sort
of expected to see some console_valid_nocons_seq manipulations in
register_console(), when we register a new CON_PRINTBUFFER console
on already running system.
> Hmm, I seriously think about reverting the commit 375899cddcbb
> ("printk: make sure to print log on console.") and solving it
> another way.
I can agree, definitely. That's one of the options.
-ss
next prev parent reply other threads:[~2018-09-06 7:29 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
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 [this message]
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=20180906072940.GA382@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.