Re: [PATCH 4.19 regression fix] printk: For early boot messages check loglevel when flushing the buffer

[Hans de Goede <hdegoede@redhat.com>]

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