From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932541AbcHXIdt (ORCPT ); Wed, 24 Aug 2016 04:33:49 -0400 Received: from mx2.suse.de ([195.135.220.15]:55624 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932500AbcHXIdq (ORCPT ); Wed, 24 Aug 2016 04:33:46 -0400 Date: Wed, 24 Aug 2016 10:19:20 +0200 From: Petr Mladek To: Sergey Senozhatsky Cc: Jan Kara , Kay Sievers , Tejun Heo , Calvin Owens , Andrew Morton , linux-kernel@vger.kernel.org, Sergey Senozhatsky Subject: Re: [PATCH][RFC] printk: make pr_cont buffer per-cpu Message-ID: <20160824081919.GE2504@pathway.suse.cz> References: <20160822154030.2715-1-sergey.senozhatsky@gmail.com> <20160823051831.GA423@swordfish> <20160823114702.GC4866@pathway.suse.cz> <20160824011420.GA452@swordfish> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20160824011420.GA452@swordfish> 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 2016-08-24 10:14:20, Sergey Senozhatsky wrote: > Hello, > > On (08/23/16 13:47), Petr Mladek wrote: > [..] > > > if (!(lflags & LOG_NEWLINE)) { > > > + if (!this_cpu_read(cont_printing)) { > > > + if (system_state == SYSTEM_RUNNING) { > > > + this_cpu_write(cont_printing, true); > > > + preempt_disable(); > > > + } > > > + } > > > > I am afraid that this is not acceptable. It means that printk() will have > > an unexpected side effect. The missing "\n" at the end of a printed > > string would disable preemption. See below for more. > > missing '\n' must WARN about "sched while atomic" eventually, so it > shouldn't go unnoticed or stay hidden. Well, it will still force people to rebuilt a test kernel because they forget to use '\n" and the test kernel is unusable. IMHO, the connection between '\n' and preemption is not intuitive and hard to spot. We should do our best to avoid it. > > I think that cont lines should be a corner case. There should be only > > a limited use of them. We should not make too complicated things to > > support them. Also printk() must not get harder to use because of them. > > I still see a messed output rather as a cosmetic problem in compare with > > possible possible deadlocks or hung tasks. > > oh, I would love it if pr_cont() was never used in SMP. but this is not > the case, unfortunately. and, ironically, where pr_cont really matters > is debugging -- for instance, look at arch/x86/kernel/dumpstack_{32,64}.c > show_regs() or show_stack_log_lvl() Sure but how big is the problem in the daily life? I have never heard colleagues complaining about messed cont lines. It is rare and it is always possible to restore it. Checking BUG/WARN messages is a rather hard detective work anyway. The most painful situation would be if backtraces from different CPUs are mixed. But there will be problem even with mixed lines. Fortunately, this usually happens when printing backtraces from all CPUs in NMI and the output is serialized. > well, I do understand what you mean and agree with it, but I'm > afraid pr_cont() kinda matters after all and people *probably* > expect it to be SMP safe (I'm not entirely sure whether all of > those pr_cont() calls were put there with the idea that the > output can be messed up and quite hard to read). This was even worse before the cont lines buffer. Sigh, I do not feel experienced enough to decide about this. I wonder if this is rather theoretical problem or if there are many real complains about it. I feel that we might be trapped by a perfectionism. Perfect output would be great. But it must not make printk() hard to use in the daily life. Best Regards, Petr