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]
Date:   Tue, 17 Sep 2019 23:08:21 +0900
From:   Tetsuo Handa <penguin-kernel@...ove.sakura.ne.jp>
To:     Steven Rostedt <rostedt@...dmis.org>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>
Cc:     Petr Mladek <pmladek@...e.com>,
        Daniel Vetter <daniel.vetter@...ll.ch>,
        AndreaParri <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>,
        John Ogness <john.ogness@...utronix.de>,
        Thomas Gleixner <tglx@...utronix.de>,
        LinusTorvalds <torvalds@...ux-foundation.org>,
        "Theodore Ts'o" <tytso@....edu>,
        PraritBhargava <prarit@...hat.com>,
        LKML <linux-kernel@...r.kernel.org>
Subject: Re: printk meeting at LPC

On 2019/09/17 22:37, Steven Rostedt wrote:
> On Tue, 17 Sep 2019 15:12:04 +0200
> Greg Kroah-Hartman <gregkh@...uxfoundation.org> wrote:
> 
>>> Well, it's being used. I was thinking of dropping it if it was not.
>>> Let's keep it then.  
>>
>> I think it should be dropped, only one user of the kernel is using it in
>> a legitimate way, which kind of implies it isn't needed.
> 
> I'm thinking if it isn't hard to support then we can keep it (meaning
> that we already have to calculate the length anyway). But if it starts
> to complicate the code, then we should drop it.
> 

Due to console_loglevel (some are printed and others are not printed) and
possibility of concurrent printk() callers (one line can be printed as
multiple lines), using printk()'s return value for calculating column offset
will not always work as expected. I guess that users should not count on
printk()'s return value. They might want to try printing one line at a time
using their local buffers...

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ