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  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]
Date:   Wed, 6 Mar 2019 23:27:41 +0900
From:   Sergey Senozhatsky <sergey.senozhatsky@...il.com>
To:     Petr Mladek <pmladek@...e.com>
Cc:     Tetsuo Handa <penguin-kernel@...ove.sakura.ne.jp>,
        Sergey Senozhatsky <sergey.senozhatsky.work@...il.com>,
        Sergey Senozhatsky <sergey.senozhatsky@...il.com>,
        Steven Rostedt <rostedt@...dmis.org>,
        John Ogness <john.ogness@...utronix.de>,
        Andrew Morton <akpm@...ux-foundation.org>,
        Linus Torvalds <torvalds@...ux-foundation.org>,
        linux-kernel@...r.kernel.org
Subject: Re: [RFC PATCH] printk: Introduce "store now but print later" prefix.

On (03/06/19 11:04), Petr Mladek wrote:
> > I'm suggesting to use a non-async printk() for $trailer_text_line line. I think
> > that changing all printk() called from out_of_memory() to async is doable, if
> > the caller of out_of_memory() wakes up a dedicated kthread described below.
> 
> This is error prone. The trailing printk is not guaranteed:
> 
>     + It might get lost by code refactoring.
> 
>     + People would miss that it is needed when async printk is used
>       in a shared function, e.g. dump_stack().
> 
>     + People will not know that it is needed because they
>       are not familiar with the API. The would just use it
>       as part of a cargo cult programming or so.
> 
> For this reason, this API is a "no no no" from my side.

Conceptually, this buffering is just pr_cont() with extension
from "1 line" to "N lines". pr_cont() also waits for a special
marker to flush the buffered data - that marker is pr_cont('\n'),
which forces printk to log_store() cont buffer. In Tetsuo's
proposal the marker is different. That's the only difference I
see. Should any other CPU printk() anything - it will print out
buffered data, same thing as pr_cont(), again.

	-ss

Powered by blists - more mailing lists