linux-kernel - Re: [PATCH v2] debugobjects: Move printk out of db lock critical sections

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, 18 Dec 2018 14:51:53 +0100
From:   Ingo Molnar <mingo@...nel.org>
To:     Linus Torvalds <torvalds@...ux-foundation.org>
Cc:     Waiman Long <longman@...hat.com>,
        Thomas Gleixner <tglx@...utronix.de>,
        Andrew Morton <akpm@...ux-foundation.org>,
        Linux List Kernel Mailing <linux-kernel@...r.kernel.org>,
        Peter Zijlstra <peterz@...radead.org>,
        yang.shi@...ux.alibaba.com, Arnd Bergmann <arnd@...db.de>,
        sergey.senozhatsky.work@...il.com, dima@...sta.com, bp@...en8.de
Subject: Re: [PATCH v2] debugobjects: Move printk out of db lock critical
 sections

* Linus Torvalds <torvalds@...ux-foundation.org> wrote:

> On Mon, Dec 17, 2018 at 10:17 AM Ingo Molnar <mingo@...nel.org> wrote:
> >
> > We should rename printk() to syslog() or so, and rename early_printk() to
> > printk(), and be done with this.
> 
> No.
> 
> As already pointed out, the syslog part isn't the issue. The printing
> part is the issue.

Indeed - I fired a shot fired in the wrong direction ...

> So thinking that early_printk is any better is just puting your head in 
> the sand.

... at my own feet. ;-) Apologies to the syslog folks!

early_printk should still in principle be more robust: it tries to use as 
little (no) locking as possible, and definitely tries to do no 
allocations. It doesn't use syslog, nor any console locking, nor any 
regular console drivers.

Which results in usability trade-offs: trashed screen output, mangled 
lines. It's a superior debug facility when debugging particularly hairy 
low level code - which most of the kernel isn't where it turns into an 
inferior debugging method.

I thing a good solution would be PeterZ's force_early_printk boot knob, 
for those low level folks who absolutely want to rely on printk always 
working in some fashion.

( I think it might even be possible to add a non-locked feature to 
  early-printk that actually adds the messages to the syslog ring-buffer 
  - without any notification/wakeup/serialization features. 'dmesg' is 
  handy and its lack is the primary usability disadvantage of 
  earlyprintk. )

Thanks,

	Ingo