From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-3.8 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, INCLUDES_PATCH,MAILING_LIST_MULTI,SPF_PASS autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 5D241ECE561 for ; Mon, 24 Sep 2018 08:11:34 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id B077320C0A for ; Mon, 24 Sep 2018 08:11:33 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org B077320C0A Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=i-love.sakura.ne.jp Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727049AbeIXOMX (ORCPT ); Mon, 24 Sep 2018 10:12:23 -0400 Received: from www262.sakura.ne.jp ([202.181.97.72]:46718 "EHLO www262.sakura.ne.jp" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725935AbeIXOMX (ORCPT ); Mon, 24 Sep 2018 10:12:23 -0400 Received: from fsav104.sakura.ne.jp (fsav104.sakura.ne.jp [27.133.134.231]) by www262.sakura.ne.jp (8.15.2/8.15.2) with ESMTP id w8O8BTHd027218; Mon, 24 Sep 2018 17:11:29 +0900 (JST) (envelope-from penguin-kernel@i-love.sakura.ne.jp) Received: from www262.sakura.ne.jp (202.181.97.72) by fsav104.sakura.ne.jp (F-Secure/fsigk_smtp/530/fsav104.sakura.ne.jp); Mon, 24 Sep 2018 17:11:29 +0900 (JST) X-Virus-Status: clean(F-Secure/fsigk_smtp/530/fsav104.sakura.ne.jp) Received: from [192.168.1.8] (softbank060157066051.bbtec.net [60.157.66.51]) (authenticated bits=0) by www262.sakura.ne.jp (8.15.2/8.15.2) with ESMTPSA id w8O8BMRM027048 (version=TLSv1.2 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 24 Sep 2018 17:11:29 +0900 (JST) (envelope-from penguin-kernel@i-love.sakura.ne.jp) Subject: Re: [PATCH] printk: inject caller information into the body of message From: Tetsuo Handa To: Sergey Senozhatsky Cc: Sergey Senozhatsky , Petr Mladek , Steven Rostedt , Alexander Potapenko , Dmitriy Vyukov , kbuild test robot , syzkaller , LKML , Linus Torvalds , Andrew Morton References: <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> <20180914122217.GA518@tigerII.localdomain> 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: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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);