Messages in this thread | | | Subject | Re: [PATCH 4.19 regression fix] printk: For early boot messages check loglevel when flushing the buffer | From | Hans de Goede <> | Date | Wed, 5 Sep 2018 06:53:15 +0200 |
| |
Hi,
On 05-09-18 04:35, Sergey Senozhatsky wrote: > Hi, > > On (09/04/18 20:01), Hans de Goede wrote: >> Commit 375899cddcbb ("printk: make sure to print log on console."), moved >> the checking of the loglevel of messages from flush time to the actual >> log time. >> >> This introduces one problem, some early boot messages are printed before >> parse_early_param() gets called and thus before kernel commandline options >> such as quiet, loglevel and ignore_loglevel are parsed. > > Do you use earlycon?
No, I'm seeing this with the regular/normal console stuff.
>> This causes e.g. the following messages to get printed on x86 systems, >> despite the presence of the "quiet" option: >> >> [ 0.000000] BIOS-provided physical RAM map: >> [ 0.000000] BIOS-e820: [mem 0x0000000000000000-0x0000000000057fff] usable >> ... >> [ 0.000000] BIOS-e820: [mem 0x0000000100000000-0x0000000874ffffff] usable >> >> 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?
Regards,
Hans
| |