Received: by 2002:ac0:a5a6:0:0:0:0:0 with SMTP id m35-v6csp606038imm; Fri, 14 Sep 2018 03:37:52 -0700 (PDT) X-Google-Smtp-Source: ANB0VdYV4iXy+c+tGfnK6tZuGFF22wst2IIJztpFio4N1pcAevKIAS0eSx7cO6hXoY+5VAisB8UD X-Received: by 2002:a62:e218:: with SMTP id a24-v6mr11663147pfi.75.1536921472488; Fri, 14 Sep 2018 03:37:52 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1536921472; cv=none; d=google.com; s=arc-20160816; b=PodXMHh7krHs3j6AIOYSQffbuT0T/Gby9TJNyZzCfy0gr4FEFX6Va+5MXQY3O+Dk5m gVYUYcLOjzX2lmDgPlVk4RjLNPAd47X9OSN3XVUcJAufv4J2wMgtqDd8wcemJ7OJWBOu gyLgQBEyljFa1Wmb/7pud/eJbOQXO4sstNUZoJbDRYq8mJ0/Dhm3+7xoRWaaFm1NUNtj yHjAyScAEPXznZ2a/HLVvXP7MCIDiqjKPWmilBm3HlZrmOmz416wdio8G7ZEzZrqVH2C HLkBjrAsgBafrXB1fwAY5Zr/E5SNg8yOWlLS5JjaIIwwBVTopD7qyyDe9NAb/77r77/f BU8w== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding :content-language:in-reply-to:mime-version:user-agent:date :message-id:from:references:cc:to:subject; bh=bhJAYpFovJ/hOksm7Y9kZhA5MQYhe2HsNFog/4X9abw=; b=JZoBe4SzryVAHLZ4xCPtKC9WoHHfStNkP17QzFfEUwBZYZAHJn+qi0RkrCQ0s4dbZN lzOKLrJBoJ5Je+QGfdoBGam7wKvZPB0Cxj5FF0OkMO2uHz4OXEms7mQSPDNej/iI+3/K tgyT9cs241EqNNpqPEkhS0nAOZMtIRVlHhfzanwM1O0hyFJR41zgTYjYsx+No6J/1rNz vOCyHsbyPkivTqnHSqDGtYMtfizJvX4M/95fiSFVuvEDIjgfl0YQBRJgipZgzOjqA2Iv pzMZFpiQxtHnECoWsDQjf1SiBPXeXC4NJA3WMWeXQe3CjWjiZuOnB8pODd8+gcx+HIkK 1JcQ== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id l18-v6si7009113pfk.78.2018.09.14.03.37.36; Fri, 14 Sep 2018 03:37:52 -0700 (PDT) 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; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728005AbeINPvY (ORCPT + 99 others); Fri, 14 Sep 2018 11:51:24 -0400 Received: from www262.sakura.ne.jp ([202.181.97.72]:52186 "EHLO www262.sakura.ne.jp" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726893AbeINPvY (ORCPT ); Fri, 14 Sep 2018 11:51:24 -0400 Received: from fsav102.sakura.ne.jp (fsav102.sakura.ne.jp [27.133.134.229]) by www262.sakura.ne.jp (8.15.2/8.15.2) with ESMTP id w8EAbTmB084396; Fri, 14 Sep 2018 19:37:29 +0900 (JST) (envelope-from penguin-kernel@i-love.sakura.ne.jp) Received: from www262.sakura.ne.jp (202.181.97.72) by fsav102.sakura.ne.jp (F-Secure/fsigk_smtp/530/fsav102.sakura.ne.jp); Fri, 14 Sep 2018 19:37:29 +0900 (JST) X-Virus-Status: clean(F-Secure/fsigk_smtp/530/fsav102.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 w8EAbOko084349 (version=TLSv1.2 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 14 Sep 2018 19:37:29 +0900 (JST) (envelope-from penguin-kernel@i-love.sakura.ne.jp) Subject: Re: [PATCH] printk: inject caller information into the body of message To: Sergey Senozhatsky , Petr Mladek , Steven Rostedt Cc: Alexander Potapenko , Dmitriy Vyukov , kbuild test robot , syzkaller , LKML , Linus Torvalds , Andrew Morton , Sergey Senozhatsky References: <20180620110759.GD444@jagdpanzerIV> <20180620130628.GA1000@tigerII.localdomain> <20180912065307.GA606@jagdpanzerIV> <20180912120548.4280f04a@vmware.local.home> <20180913071204.GA604@jagdpanzerIV> <20180913122625.6ieyexpcmlc5z2it@pathway.suse.cz> <20180913142802.GB517@tigerII.localdomain> <20180914065728.GA515@jagdpanzerIV> From: Tetsuo Handa Message-ID: <49d22738-17ad-410a-be0a-d27d76ba9f37@i-love.sakura.ne.jp> Date: Fri, 14 Sep 2018 19:37:21 +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: <20180914065728.GA515@jagdpanzerIV> 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/14 15:57, Sergey Senozhatsky wrote: > On (09/13/18 23:28), Sergey Senozhatsky wrote: >> Not that I see any problems with pr_line_flush(). But can drop it, sure. >> pr_line() is a replacement for pr_cont() and as such it's not for multi-line >> buffering. > > OK, attached. > Let me know if anything needs to improved (including broken English). > Will we keep in the printk tree or shall I send a formal patch to Andrew? > @@ -20,6 +20,9 @@ > * Annotation for a "continued" line of log printout (only done after a > * line that had no enclosing \n). Only to be used by core/arch code > * during early bootup (a continued line is not SMP-safe otherwise). > + * > + * Please consider pr_line()/vpr_line() functions for SMP-safe continued > + * line printing. I think the advantage is not limited to SMP-safeness. Reducing the frequency of calling printk() will reduce overhead. Also, latency for netconsole will be reduced by sending a whole line in one printk(). > +/** > + * DEFINE_PR_LINE - define a new pr_line variable > + * @lev: printk() log level > + * @name: variable name > + * > + * Defines a new pr_line varialbe, which would use an implicit s/varialbe/variable/ . > + * stack buffer of size __PR_LINE_BUF_SZ. > + */ > +#define DEFINE_PR_LINE(lev, name) \ > + char __line_##name[__PR_LINE_BUF_SZ]; \ > + struct pr_line name = { \ > + .sb = __SEQ_BUF_INITIALIZER(__line_##name, \ > + __PR_LINE_BUF_SZ), \ > + .level = lev, \ > + } Want a note that static DEFINE_PR_LINE(lev, name); won't make "name" variable "static" ? > +/** > + * DEFINE_PR_LINE_BUF - define a new pr_line variable > + * @lev: printk() log level > + * @name: variable name > + * @buf: external buffer > + * @sz: external buffer size > + * > + * Defines a new pr_line variable, which would use an external > + * buffer for printk line. > + */ > +#define DEFINE_PR_LINE_BUF(lev, name, buf, sz) \ > + struct pr_line name = { \ > + .sb = __SEQ_BUF_INITIALIZER(buf, (sz)), \ > + .level = lev, \ > + } > + I would use this one for the OOM killer. 80 bytes is too short. static char oom_print_buf[1024]; DEFINE_PR_LINE_BUF(level, oom_print_buf); > @@ -131,4 +187,8 @@ extern int > seq_buf_bprintf(struct seq_buf *s, const char *fmt, const u32 *binary); > #endif > > +extern __printf(2, 0) > +int vpr_line(struct pr_line *pl, const char *fmt, va_list args); > +extern __printf(2, 3) > +int pr_line(struct pr_line *pl, const char *fmt, ...); Do we want to mark "asmlinkage" like printk() ? > @@ -324,3 +324,60 @@ int seq_buf_to_user(struct seq_buf *s, char __user *ubuf, int cnt) > s->readpos += cnt; > return cnt; > } > + > +/** > + * vpr_line - Append data to the printk() line buffer > + * @pl: the pr_line descriptor s/descriptor/structure/ ? > + * @fmt: printf format string > + * @args: va_list of arguments from a printf() type function > + * > + * Writes a vnprintf() format into the printk() pr_line buffer. s/vnprintf/vprintf/ ?