From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
        id S1751691AbdH2UvM (ORCPT <rfc822;w@1wt.eu>);
        Tue, 29 Aug 2017 16:51:12 -0400
Received: from mail-io0-f196.google.com ([209.85.223.196]:37281 "EHLO
        mail-io0-f196.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org
        with ESMTP id S1751263AbdH2UvL (ORCPT
        <rfc822;linux-kernel@vger.kernel.org>);
        Tue, 29 Aug 2017 16:51:11 -0400
MIME-Version: 1.0
In-Reply-To: <201708300541.IHE65621.SFMHVFOQOOtJFL@I-love.SAKURA.ne.jp>
References: <20170828122109.GA532@jagdpanzerIV.localdomain>
 <20170828124634.GD492@amd> <20170829134048.GA437@jagdpanzerIV.localdomain>
 <CA+55aFwmwdY_mMqdEyFPpRhCKRyeqj=+aCqe5nN108v8ELFvPw@mail.gmail.com>
 <CA+55aFyzR4LKhJKLFgvvd9OTsos2_g4-9fova782BX4kyA3bLA@mail.gmail.com> <201708300541.IHE65621.SFMHVFOQOOtJFL@I-love.SAKURA.ne.jp>
From: Linus Torvalds <torvalds@linux-foundation.org>
Date: Tue, 29 Aug 2017 13:51:10 -0700
X-Google-Sender-Auth: F_DgQzxT9bpJRur8NhJ50mUG4Fo
Message-ID: <CA+55aFwcZK80Sth9xny647rNn+QyRLXw7mxZw9n1MZAuZSjDUA@mail.gmail.com>
Subject: Re: printk: what is going on with additional newlines?
To: Tetsuo Handa <penguin-kernel@i-love.sakura.ne.jp>
Cc: Sergey Senozhatsky <sergey.senozhatsky.work@gmail.com>,
        Pavel Machek <pavel@ucw.cz>,
        SergeySenozhatsky <sergey.senozhatsky@gmail.com>,
        Petr Mladek <pmladek@suse.com>, Steven Rostedt <rostedt@goodmis.org>,
        Jan Kara <jack@suse.cz>, Andrew Morton <akpm@linux-foundation.org>,
        Jiri Slaby <jslaby@suse.com>, Andreas Mohr <andi@lisas.de>,
        Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Content-Type: text/plain; charset="UTF-8"
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

On Tue, Aug 29, 2017 at 1:41 PM, Tetsuo Handa
<penguin-kernel@i-love.sakura.ne.jp> wrote:
>>
>> A private buffer has none of those issues.
>
> Yes, I posted "[PATCH] printk: Add best-effort printk() buffering." at
> http://lkml.kernel.org/r/1493560477-3016-1-git-send-email-penguin-kernel@I-love.SAKURA.ne.jp .

No, this is exactly what I *don't* want, because it takes over printk() itself.

And that's problematic, because nesting happens for various reasons.

For example, you try to handle that nesting with printk_context(), and
nothing when an interrupt happens.

But that is fundamentally broken.

Just to give an example: what if an interrupt happens, it does this
buffering thing, then it gets interrupted by *another* interrupt, and
now the printk from that other interrupt gets incorrectly nested
together with the first one, because your "printk_context()" gives
them the same context?

And it really doesn't have to even be interrupts. Look at what happens
if you take a page fault in kernel space. Same exact deal. Both are
sleeping contexts.

So I really think that the only thing that knows what the "context" is
is the person who does the printing. So if you want to create a
printing buffer, it should be explicit. You allocate the buffer ahead
of time (perhaps on the stack, possibly using actual allocations), and
you use that explicit context.

Yes, it means that you don't do "printk()". You do an actual
"buf_print()" or similar.

             Linus