Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
Subject: Re: [PATCH] printk: inject caller information into the body of
 message
From:   Tetsuo Handa <penguin-kernel@i-love.sakura.ne.jp>
To:     Sergey Senozhatsky <sergey.senozhatsky@gmail.com>
Cc:     Sergey Senozhatsky <sergey.senozhatsky.work@gmail.com>,
        Petr Mladek <pmladek@suse.com>,
        Steven Rostedt <rostedt@goodmis.org>,
        Alexander Potapenko <glider@google.com>,
        Dmitriy Vyukov <dvyukov@google.com>,
        kbuild test robot <fengguang.wu@intel.com>,
        syzkaller <syzkaller@googlegroups.com>,
        LKML <linux-kernel@vger.kernel.org>,
        Linus Torvalds <torvalds@linux-foundation.org>,
        Andrew Morton <akpm@linux-foundation.org>
References: <CAG_fn=XuZo5yrZzVizP26iV6eFfJtAHUs4NsDFXFyvnaJkdSQw@mail.gmail.com>
 <20180912065307.GA606@jagdpanzerIV>
 <20180912120548.4280f04a@vmware.local.home>
 <20180913071204.GA604@jagdpanzerIV>
 <20180913122625.6ieyexpcmlc5z2it@pathway.suse.cz>
 <20180913142802.GB517@tigerII.localdomain>
 <20180914065728.GA515@jagdpanzerIV>
 <49d22738-17ad-410a-be0a-d27d76ba9f37@i-love.sakura.ne.jp>
 <20180914115028.GB20572@tigerII.localdomain>
 <e855cbef-03ff-b4ac-3e06-d2f2f48cfb1f@i-love.sakura.ne.jp>
 <20180914122217.GA518@tigerII.localdomain>
 <a661ed7f-889a-1811-0ada-111cc5185d05@i-love.sakura.ne.jp>
Message-ID: <7dadfa8c-1f69-ae0f-d747-dbbc9f97c2b6@i-love.sakura.ne.jp>
Date:   Mon, 24 Sep 2018 17:11:22 +0900
User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:52.0) Gecko/20100101
 Thunderbird/52.9.1
MIME-Version: 1.0
In-Reply-To: <a661ed7f-889a-1811-0ada-111cc5185d05@i-love.sakura.ne.jp>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

On 2018/09/19 20:02, Tetsuo Handa wrote:
> On 2018/09/14 21:22, Sergey Senozhatsky wrote:
>> The "SMP-safe" comment becomes a bit tricky when pr_line is used with a
>> static buffer. Either we need to require synchronization - umm... and
>> document it - or to provide some means of synchronization in pr_line().
>> Let's think what pr_line API should do about it.
>>
>> Any thoughts?
>>
> 
> I'm inclined to propose a simple one shown below, similar to just having
> several "struct cont" for concurrent printk() users.
> What Linus has commented is that implicit context is bad, and below one
> uses explicit context.
> After almost all users are converted to use below one, we might be able
> to get rid of KERN_CONT support.

The reason of using statically preallocated global buffers is that I think
that it is inconvenient for KERN_CONT users to calculate necessary bytes
only for avoiding message truncation. The pr_line might be passed to deep
into the callchain and adjusting buffer size whenever the content's possible
max length changes is as much painful as changing printk() to accept only
one "const char *" argument. Even if we guarantee that any context can
allocate buffer from kernel stack, we cannot guarantee that many concurrent
printk() won't trigger lockup. Thus, I think that trying to allocate from
finite static buffers with a fallback to unbuffered printk() upon failure
is sufficient.


By the way, kbuild test robot told me that I forgot to drop asmlinkage keyword.

 include/linux/printk.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/include/linux/printk.h b/include/linux/printk.h
index 889491b..3347442 100644
--- a/include/linux/printk.h
+++ b/include/linux/printk.h
@@ -178,7 +178,7 @@ asmlinkage __printf(1, 2) __cold
 void flush_printk_buffer(struct printk_buffer *ptr);
 __printf(2, 3)
 int buffered_printk(struct printk_buffer *ptr, const char *fmt, ...);
-asmlinkage __printf(2, 0)
+__printf(2, 0)
 int buffered_vprintk(struct printk_buffer *ptr, const char *fmt, va_list args);
 void put_printk_buffer(struct printk_buffer *ptr);