From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751404AbdIEJpA (ORCPT ); Tue, 5 Sep 2017 05:45:00 -0400 Received: from mx2.suse.de ([195.135.220.15]:55506 "EHLO mx1.suse.de" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1751363AbdIEJoz (ORCPT ); Tue, 5 Sep 2017 05:44:55 -0400 Date: Tue, 5 Sep 2017 11:44:52 +0200 From: Petr Mladek To: Sergey Senozhatsky Cc: Joe Perches , Steven Rostedt , Linus Torvalds , Pavel Machek , Sergey Senozhatsky , Jan Kara , Andrew Morton , Jiri Slaby , Andreas Mohr , Tetsuo Handa , Linux Kernel Mailing List Subject: Re: printk: what is going on with additional newlines? Message-ID: <20170905094452.GE8741@pathway.suse.cz> References: <20170829134048.GA437@jagdpanzerIV.localdomain> <20170829195013.5048dc42@gandalf.local.home> <20170830010348.GB654@jagdpanzerIV.localdomain> <20170829211046.74644c8a@gandalf.local.home> <1504057959.2786.4.camel@perches.com> <20170830022528.GA17968@jagdpanzerIV.localdomain> <1504060296.2786.8.camel@perches.com> <20170830024703.GA17175@jagdpanzerIV.localdomain> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20170830024703.GA17175@jagdpanzerIV.localdomain> User-Agent: Mutt/1.5.21 (2010-09-15) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed 2017-08-30 11:47:03, Sergey Senozhatsky wrote: > On (08/29/17 19:31), Joe Perches wrote: > [..] > > > the idea is not to do printk() on that seq buffer at all, but to > > > log_store(), atomically, seq buffer messages > > > > > > spin_lock(&logbuf_lock) > > > while (offset < seq_buffer->len) { > > > ... > > > log_store(seq->buffer + offset); > > > ... > > > } > > > spin_unlock(&logbuf_unlock) > > > > Why? > > Tetsuo wants this, for instance, > for OOM reports and backtraces. SCIS/ATA people want it as well. The mixing of related lines might cause problems. But I am not sure if it can be fixed a safe way on the printk side. Especially I am afraid of an extensive buffering. My underestanding, of the discussion about printk kthread patchset, is that printk() has the following priorities: 1. do not break the system (deadlock, livelock, softlock) 2. get the message out (suddent death, panic, flood of messages) 3. keep the message readable (cont lines, related lines) Any buffering would delay showing the message. It increases the risk that nobody will see it at all. It is acceptable in printk_safe() and printk_safe_nmi() because we did not find a better way to avoid the deadlock. But I am not sure about any buffering used for a better readability. It is against the priorities mentioned above. Well, the buffering might be acceptable for single lines. I mean to solve KERN_CONT problems. A good API might allow to get rid of KERN_CONT, and the unreliable and rather complex code around struct cont in kernel/printk/printk.c. I would be afraid of adding an API that would allow to (transparently) redirect printing into a buffer from a huge amount of code. Alternative solution would be to print more information per-line, for example: message Then you might extract the related lines using a simple grep. It would be similar to the output of strace -f -t -o . Best Regards, Petr