linux-kernel - Re: printk: what is going on with additional newlines?

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, 29 Aug 2017 10:52:32 -0700
From:   Linus Torvalds <torvalds@...ux-foundation.org>
To:     Sergey Senozhatsky <sergey.senozhatsky@...il.com>
Cc:     Sergey Senozhatsky <sergey.senozhatsky.work@...il.com>,
        Pavel Machek <pavel@....cz>, Petr Mladek <pmladek@...e.com>,
        Steven Rostedt <rostedt@...dmis.org>, Jan Kara <jack@...e.cz>,
        Andrew Morton <akpm@...ux-foundation.org>,
        Jiri Slaby <jslaby@...e.com>, Andreas Mohr <andi@...as.de>,
        Tetsuo Handa <penguin-kernel@...ove.sakura.ne.jp>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: printk: what is going on with additional newlines?

On Tue, Aug 29, 2017 at 10:33 AM, Sergey Senozhatsky
<sergey.senozhatsky@...il.com> wrote:
>
> ok. that's something several people asked for -- some sort of buffered
> printk mode; but people don't want to use a buffer allocated on the stack
> (or kmalloc-ed, etc.) to do sprintf() on it and then feed it to printk("%s"),
> because this adds some extra cost:

I don't like the notion of per-cpu buffers either, because then you
suddenly get atomicity issues, and you really don't want that.

My preference as a user is actually to just have a dynamically
re-sizable buffer (that's pretty much what I've done in *every* single
user space project I've had in the last decade), but because some
users might have atomicity issues I do suspect that we should just use
a stack buffer.

And then perhaps say that the buffer size has to be capped at 80 characters.

Because if you're printing more than 80 characters and expecting it
all to fit on a line, you're doing something else wrong anyway.

And hide it not as a explicit "char buffer[80]]" allocation, but as a
"struct line_buffer" or similar, so that

 (a) people don't get the line size wrong

 (b) the buffering code can add a few fields for length etc in there too

Introduce a few helper functions for it:

 init_line_buffer(&buf);
 print_line(&buf, fmt, args);
 vprint_line(&buf, fmt, vararg);
 finish_line(&buf);

or whatever, and it sounds like it should be pretty easy to use.

                Linus