From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751129AbdIEMV7 (ORCPT ); Tue, 5 Sep 2017 08:21:59 -0400 Received: from mx2.suse.de ([195.135.220.15]:41918 "EHLO mx1.suse.de" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1750858AbdIEMV5 (ORCPT ); Tue, 5 Sep 2017 08:21:57 -0400 Date: Tue, 5 Sep 2017 14:21:54 +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: <20170905122154.GG8741@pathway.suse.cz> References: <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> <20170905094452.GE8741@pathway.suse.cz> <20170905095900.GC2066@jagdpanzerIV.localdomain> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20170905095900.GC2066@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 Tue 2017-09-05 18:59:00, Sergey Senozhatsky wrote: > On (09/05/17 11:44), Petr Mladek wrote: > [..] > > > 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 > > this discussion is not related to printk ktrehad. it's just the > first messages was posted as a reply to printk kthread patch set, > other than that it's unrelated. But it is related in the sense of what people expect from printk(). This has been discussed in all the patchsets that try to avoid soft-lockups. Any printk() feature or fix must be in sync with these expectations. See below for more. > > 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. > > that's why I want buffered printk to re-use the printk-safe buffer > on that particular CPU [ if buffered printk will ever land ]. > printk-safe buffer is not allocated on stack, or kmalloc-ed for > temp usafe, and, more importantly, we flush it from panic(). > > and I'm not sure that lost messages due to missing panic flush() > can really be an option even for a single cont line buffer. well, > may be it can. printk has a sort of guarantee that messages will > be at some well known location when pr_foo or printk function > returns. buffered printk kills it. and I don't want to have > several "flavors" of printk. printk-safe buffer seems to be the > way to preserve that guarantee. But the well known locations would help only when they are flushed in panic() or when a crashdump is created. They do not help in other cases, especially where there is a sudden death. There are many fears that printk offloading does not have enough guarantees to actually happen. IMHO, there must be similar fears that the messages in a temporary buffer will never get flushed. And there are more risks with this approach: + soft-lockups caused by disabled preemption; we would need this to stay on the same CPU and use the same buffer + broken preempt-count and missing message when one forgets to close the buffered section or do it twice + lost messages because a per-CPU buffer size limitations + races in printk_safe() that is not recursions safe + not to say the problems mentioned by Linus as reply to the Tetsuo's proposal, see https://lkml.kernel.org/r/CA+55aFx+5R-vFQfr7+Ok9Yrs2adQ2Ma4fz+S6nCyWHY_-2mrmw@mail.gmail.com Some of these problems would be solved by a custom buffer. But you are right. There are less guarantees that it would get flushed or that it can be found in case of troubles. Now, I am not sure that it is a good idea to use it even for a single continuous line. I wonder if all this is worth the effort, complexity, and risk. We are talking about cosmetic problems after all. Well, what do you think about the extra printed information? For example: message It looks straightforward to me. These information might be helpful on its own. So, it might be a win-win solution. Best Regards, Petr