linux-kernel - Re: printk meeting at LPC

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <87r24giac9.fsf@linutronix.de>
Date:   Mon, 16 Sep 2019 16:28:54 +0200
From:   John Ogness <john.ogness@...utronix.de>
To:     Steven Rostedt <rostedt@...dmis.org>
Cc:     Petr Mladek <pmladek@...e.com>,
        Tetsuo Handa <penguin-kernel@...ove.SAKURA.ne.jp>,
        Daniel Vetter <daniel.vetter@...ll.ch>,
        Andrea Parri <parri.andrea@...il.com>,
        Sergey Senozhatsky <sergey.senozhatsky@...il.com>,
        Sergey Senozhatsky <sergey.senozhatsky.work@...il.com>,
        Brendan Higgins <brendanhiggins@...gle.com>,
        Paul Turner <pjt@...gle.com>,
        Peter Zijlstra <peterz@...radead.org>,
        Thomas Gleixner <tglx@...utronix.de>,
        Linus Torvalds <torvalds@...ux-foundation.org>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        Theodore Ts'o <tytso@....edu>,
        Prarit Bhargava <prarit@...hat.com>,
        LKML <linux-kernel@...r.kernel.org>
Subject: Re: printk meeting at LPC

On 2019-09-16, Steven Rostedt <rostedt@...dmis.org> wrote:
>>>> 6. A new may-sleep function pr_flush() will be made available to
>>>> wait for all previously printk'd messages to be output on all
>>>> consoles before proceeding. For example:
>>>> 
>>>>     pr_cont("Running test ABC... ");
>>>>     pr_flush();
>>>> 
>>>>     do_test();
>>>> 
>>>>     pr_cont("PASSED\n");
>>>>     pr_flush();  
>>> 
>>> Don't we need to allow printk() callers to know the sequence number
>>> which the printk() has queued? Something like
>>> 
>>>   u64 seq;
>>>   pr_info(...);
>>>   pr_info(...);
>>>   pr_info(...);
>>>   seq = pr_current_seq();
>>>   pr_wait_seq(seq);
>>> 
>>> in case concurrently executed printk() flooding keeps adding a lot
>>> of pending output?
>> 
>> My expectation is that pr_flush() would wait only until the current
>> message appears on all consoles. It will not wait for messages that
>> would get added later.
>
> Right, I believe we agreed that pr_flush() would take care of all this.

Yes, this is what we agreed on.

>>>> 9. Support for printk dictionaries will be discontinued. I will
>>>> look into who is using this and why. If printk dictionaries are
>>>> important for you, speak up now!
>>> 
>>> I think that dev_printk() is using "const char *dict, size_t
>>> dictlen," part via create_syslog_header(). Some userspace programs
>>> might depend on availability of such information.
>> 
>> Yeah, but it seems to be the only dictionary writer. There were
>> doubts (during the meeting) whether anyone was actually using the
>> information.
>> 
>> Hmm, it seems that journalctl is able to filer device specific
>> information, for example, I get:
>> 
>> $> journalctl _KERNEL_DEVICE=+usb:2-1  
>> -- Logs begin at Tue 2019-08-13 09:00:03 CEST, end at Mon 2019-09-16 12:32:58 CEST. --
>> Aug 13 09:00:04 linux-qszd kernel: usb 2-1: new high-speed USB device number 2 using ehci-pci
>> 
>> One question is if anyone is using this filtering. Simple grep is
>> enough. Another question is whether it really needs to get passed
>> this way.
>> 
>
> If worse comes to worse, perhaps we let the console decide what to do
> with it. Where all consoles but the "kmsg" one ignores it?
>
> Then journalctl should work as normal.
>
> Or will this break one of our other changes?

The consoles will just iterate the ringbuffer. So if any console needs
dictionary information, that information needs to be stored in the
ringbuffer as well.

The dictionary text and message text could be stored as concatenated
strings. The descriptor would point separately to the beginning of
dictionary and message. So the data-buffer would still be a clean
collection of text. But AFAIK Linus didn't want to see that "extra" text
at all.

If we want to keep dictionary text out of the data-buffer, we could have
a 2nd data-buffer dedicated for dictionary text. I expect it would not
really complicate things. Especially if the dictionary part was "best
effort" (i.e. if the dictionary text does not fit in the free part of
its data-buffer, it is dropped).

John Ogness