This message generated a parse failure. Raw output follows here. Please use 'back' to navigate. From devnull@lkml.org Wed Apr 24 17:55:16 2024 >From mailfetcher Sat Nov 10 09:52:23 2018 Envelope-to: lkml@grols.ch Delivery-date: Sat, 10 Nov 2018 09:52:23 +0100 Received: from stout.grols.ch [195.201.141.146] by 72459556e3a9 with IMAP (fetchmail-6.3.26) for (single-drop); Sat, 10 Nov 2018 09:52:23 +0100 (CET) Received: from vger.kernel.org ([209.132.180.67]) by stout.grols.ch with esmtp (Exim 4.89) (envelope-from ) id 1gLP0A-0000No-Ib for lkml@grols.ch; Sat, 10 Nov 2018 09:52:23 +0100 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728876AbeKJSge (ORCPT ); Sat, 10 Nov 2018 13:36:34 -0500 Received: from www262.sakura.ne.jp ([202.181.97.72]:56369 "EHLO www262.sakura.ne.jp" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728791AbeKJSge (ORCPT ); Sat, 10 Nov 2018 13:36:34 -05 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 wAA8qJEb034966; Sat, 10 Nov 2018 17:52:19 +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); Sat, 10 Nov 2018 17:52:19 +0900 (JST) X-Virus-Status: clean(F-Secure/fsigk_smtp/530/fsav102.sakura.ne.jp) Received: from [192.168.1.8] (softbank060157065137.bbtec.net [60.157.65.137]) (authenticated bits=0) by www262.sakura.ne.jp (8.15.2/8.15.2) with ESMTPSA id wAA8qJtq034918 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=NO); Sat, 10 N Subject: Re: [PATCH 3/3] lockdep: Use line-buffered printk() for lockdep messages. To: Petr Mladek Cc: Sergey Senozhatsky , Linus Torvalds , Sergey Senozhatsky , Dmitriy Vyukov , Steven Rostedt <1541165517-3557-3-git-send-email-penguin-kernel@I-love.SAKURA.ne.jp> <20181107151900.gxmdvx42qeanpoah@pathway.suse.cz> <20181108044510.GC2343@jagdpanzerIV> <9648a384-853c-942e-6a8d-80 From: Tetsuo Handa Message-Id: <2d0d1f60-d8b6-41e0-6845-0eb62f211e40@i-love.sakura.ne.jp> Date: Sat, 10 Nov 2018 17:52:17 +0900 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.3.0 Mime-Version: 1.0 In-Reply-To: <20181109154326.apqkbsojmbg26o3b@pathway.suse.cz> 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 Received-SPF: none client-ip=209.132.180.67; envelope-from=linux-kernel-owner@vger.kernel.org; helo=vger.kernel.org X-Spam-Score: -2.3 X-Spam-Score-Bar: -- X-Spam-Action: no action X-Spam-Report: Action: no action Symbol: ARC_NA(0.00) Symbol: RCVD_VIA_SMTP_AUTH(0.00) Symbol: RCVD_COUNT_FIVE(0.00) Symbol: FROM_HAS_DN(0.00) Symbol: TO_DN_SOME(0.00) Symbol: PRECEDENCE_BULK(0.00) Symbol: TAGGED_RCPT(0.00) Symbol: MIME_GOOD(-0.10) Symbol: DMARC_NA(0.0 On 2018/11/10 0:43, Petr Mladek wrote: > On Fri 2018-11-09 18:55:26, Tetsuo Handa wrote: >> How early_printk requirement affects line buffered printk() API? >> >> I don't think it is impossible to convert from >> >> printk("Testing feature XYZ.."); >> this_may_blow_up_because_of_hw_bugs(); >> printk(KERN_CONT " ... ok\n"); >> >> to >> >> printk("Testing feature XYZ:\n"); >> this_may_blow_up_because_of_hw_bugs(); >> printk("Testing feature XYZ.. ... ok\n"); >> >> in https://lore.kernel.org/lkml/CA+55aFwmwdY_mMqdEyFPpRhCKRyeqj=+aCqe5nN108v8ELFvPw@mail.gmail.com/ . > > I just wonder how this pattern is common. I have tried but I failed > to find any instance. > > This problem looks like a big argument against explicit buffers. > But I wonder if it is real. An example of boot up messages where buffering makes difference. Vanilla: [ 0.260459] smp: Bringing up secondary CPUs ... [ 0.269595] x86: Booting SMP configuration: [ 0.270461] .... node #0, CPUs: #1 [ 0.066578] Disabled fast string operations [ 0.066578] mce: CPU supports 0 MCE banks [ 0.066578] smpboot: CPU 1 Converting physical 2 to logical package 1 [ 0.342569] #2 [ 0.066578] Disabled fast string operations [ 0.066578] mce: CPU supports 0 MCE banks [ 0.066578] smpboot: CPU 2 Converting physical 4 to logical package 2 [ 0.413442] #3 [ 0.066578] Disabled fast string operations [ 0.066578] mce: CPU supports 0 MCE banks [ 0.066578] smpboot: CPU 3 Converting physical 6 to logical package 3 [ 0.476562] smp: Brought up 1 node, 4 CPUs [ 0.477477] smpboot: Max logical packages: 8 [ 0.477514] smpboot: Total of 4 processors activated (22691.70 BogoMIPS) With try_buffered_printk() patch: [ 0.279768] smp: Bringing up secondary CPUs ... [ 0.288825] x86: Booting SMP configuration: [ 0.066748] Disabled fast string operations [ 0.066748] mce: CPU supports 0 MCE banks [ 0.066748] smpboot: CPU 1 Converting physical 2 to logical package 1 [ 0.066748] Disabled fast string operations [ 0.066748] mce: CPU supports 0 MCE banks [ 0.066748] smpboot: CPU 2 Converting physical 4 to logical package 2 [ 0.066748] Disabled fast string operations [ 0.066748] mce: CPU supports 0 MCE banks [ 0.066748] smpboot: CPU 3 Converting physical 6 to logical package 3 [ 0.495862] .... node #0, CPUs: #1 #2 #36smp: Brought up 1 node, 4 CPUs [ 0.496833] smpboot: Max logical packages: 8 [ 0.497609] smpboot: Total of 4 processors activated (22665.22 BogoMIPS) Hmm, arch/x86/kernel/smpboot.c is not emitting '\n' after #num if (system_state < SYSTEM_RUNNING) { if (node != current_node) { if (current_node > (-1)) pr_cont("\n"); current_node = node; printk(KERN_INFO ".... node %*s#%d, CPUs: ", node_width - num_digits(node), " ", node); } /* Add padding for the BSP */ if (cpu == 1) pr_cont("%*s", width + 1, " "); pr_cont("%*s#%d", width - num_digits(cpu), " ", cpu); } else pr_info("Booting Node %d Processor %d APIC 0x%x\n", node, cpu, apicid); and causing pr_info("Brought up %d node%s, %d CPU%s\n", num_nodes, (num_nodes > 1 ? "s" : ""), num_cpus, (num_cpus > 1 ? "s" : "")); line to be concatenated to previous line. Maybe disable try_buffered_printk() if system_state != SYSTEM_RUNNING ?