linux-kernel - RE: [PATCH v6 1/3] printk: Add line-buffered printk() API.

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:   Wed, 7 Nov 2018 11:01:05 +0000
From:   David Laight <David.Laight@...LAB.COM>
To:     'Tetsuo Handa' <penguin-kernel@...ove.sakura.ne.jp>,
        Sergey Senozhatsky <sergey.senozhatsky@...il.com>
CC:     Petr Mladek <pmladek@...e.com>,
        Sergey Senozhatsky <sergey.senozhatsky.work@...il.com>,
        Dmitriy Vyukov <dvyukov@...gle.com>,
        Steven Rostedt <rostedt@...dmis.org>,
        Alexander Potapenko <glider@...gle.com>,
        Fengguang Wu <fengguang.wu@...el.com>,
        Josh Poimboeuf <jpoimboe@...hat.com>,
        LKML <linux-kernel@...r.kernel.org>,
        Linus Torvalds <torvalds@...ux-foundation.org>,
        Andrew Morton <akpm@...ux-foundation.org>,
        "linux-mm@...ck.org" <linux-mm@...ck.org>,
        Ingo Molnar <mingo@...hat.com>,
        Peter Zijlstra <peterz@...radead.org>,
        Will Deacon <will.deacon@....com>
Subject: RE: [PATCH v6 1/3] printk: Add line-buffered printk() API.

From: Tetsuo Handa
> Sent: 07 November 2018 10:53
> 
> On 2018/11/06 23:35, Sergey Senozhatsky wrote:
> >> Since we want to remove "struct cont" eventually, we will try to remove
> >> both "implicit printk() users who are expecting KERN_CONT behavior" and
> >> "explicit pr_cont()/printk(KERN_CONT) users". Therefore, converting to
> >> this API is recommended.
> >
> > - The printk-fallback sounds like a hint that the existing 'cont' handling
> >   better stay in the kernel. I don't see how the existing 'cont' is
> >   significantly worse than
> > 		bpr_warn(NULL, ...)->printk() // no 'cont' support
> >   I don't see why would we want to do it, sorry. I don't see "it takes 16
> >   printk-buffers to make a thing go right" as a sure thing.
> 
> Existing 'cont' handling will stay for a while. After majority of
> pr_cont()/KERN_CONT users are converted, 'cont' support will be removed
> (e.g. KERN_CONT becomes "").

A though:

Why not make the printf lock slightly 'sticky'?
- If the output line is incomplete save the cpuid.
- If there is a saved cpuid that doesn't match the current cpu then spin for a bit.

Any callers of printk() have to assume they will spin on the buffer for the
longest printk formatting (and symbol lookup might take a while) so a short
additional delay won't matter.

Then two calls to printk() for the same line won't (usually) get split and
none of the callers need any changes.

	David

-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK
Registration No: 1397386 (Wales)