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 S1751879AbdH3A4k (ORCPT <rfc822;w@1wt.eu>);
        Tue, 29 Aug 2017 20:56:40 -0400
Received: from mail-pf0-f196.google.com ([209.85.192.196]:33011 "EHLO
        mail-pf0-f196.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org
        with ESMTP id S1751829AbdH3A4g (ORCPT
        <rfc822;linux-kernel@vger.kernel.org>);
        Tue, 29 Aug 2017 20:56:36 -0400
Date: Wed, 30 Aug 2017 09:58:59 +0900
From: Sergey Senozhatsky <sergey.senozhatsky.work@gmail.com>
To: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Sergey Senozhatsky <sergey.senozhatsky@gmail.com>,
        Sergey Senozhatsky <sergey.senozhatsky.work@gmail.com>,
        Pavel Machek <pavel@ucw.cz>, 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>,
        Tetsuo Handa <penguin-kernel@i-love.sakura.ne.jp>,
        Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: printk: what is going on with additional newlines?
Message-ID: <20170830005859.GA654@jagdpanzerIV.localdomain>
References: <20170815025625.1977-1-sergey.senozhatsky@gmail.com>
 <20170828090521.GA25025@amd>
 <20170828102830.GA403@jagdpanzerIV.localdomain>
 <20170828122109.GA532@jagdpanzerIV.localdomain>
 <20170828124634.GD492@amd>
 <20170829134048.GA437@jagdpanzerIV.localdomain>
 <CA+55aFwmwdY_mMqdEyFPpRhCKRyeqj=+aCqe5nN108v8ELFvPw@mail.gmail.com>
 <20170829173314.GA623@tigerII.localdomain>
 <CA+55aFwzS=YakV+8uJHAXak5BEuQtpKSnabYWxicK+io9-1Bzg@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <CA+55aFwzS=YakV+8uJHAXak5BEuQtpKSnabYWxicK+io9-1Bzg@mail.gmail.com>
User-Agent: Mutt/1.8.3 (2017-05-23)
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

Hello,

On (08/29/17 10:52), Linus Torvalds wrote:
> On Tue, Aug 29, 2017 at 10:33 AM, Sergey Senozhatsky
> <sergey.senozhatsky@gmail.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:
> 
[..]
> 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.

ok, I was short on details (sorry, it was almost 3am).

what I was talking/thinking about is not just a single complete continuation
line, but a whole bunch of printk calls (including continuation lines). like
OOM report with backtraces, and so on. the problem people are having (well,
according to emails I have got in my inbox) is the fact that
	printk("a"); printk("b");
	
can appear in the logbuf (and serial console) pretty far; no one knows what
can happen between those calls. so the buffered-printk buffer is supposed to
be big enough for N lines and, more importantly, it stores those lines in
logbuf in consequent entries.

so the difference here is

	while (buffer->whatever)
		printk("%s\n", buffer->msg[i]);

vs

	spin_lock(&logbuf_lock);
	while (buffer->whatever)
		log_store(buffer->msg[i]);
	spin_unlock(&logbuf_lock);


a dynamic buffer with resizing probably may not work good enough in some
OOM cases.

	-ss