From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756303AbcJWJWR (ORCPT ); Sun, 23 Oct 2016 05:22:17 -0400 Received: from mail-it0-f54.google.com ([209.85.214.54]:36088 "EHLO mail-it0-f54.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752097AbcJWJWP (ORCPT ); Sun, 23 Oct 2016 05:22:15 -0400 MIME-Version: 1.0 In-Reply-To: References: <201610122230.DID43237.FSOHFFQOJOtVML@I-love.SAKURA.ne.jp> From: Geert Uytterhoeven Date: Sun, 23 Oct 2016 11:22:14 +0200 X-Google-Sender-Auth: R4VBOOzwXMogJWEtqnKaofSNmDs Message-ID: Subject: Re: linux.git: printk() problem To: Linus Torvalds Cc: Tetsuo Handa , Linux Kernel Mailing List Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Linus, On Wed, Oct 12, 2016 at 5:47 PM, Linus Torvalds wrote: > On Wed, Oct 12, 2016 at 6:30 AM, Tetsuo Handa > wrote: >> >> I noticed that current linux.git generates hardly readable console output >> due to KERN_CONT changes. Are you suggesting developers that output like >> this be fixed? > > Yes. Needing to add a few KERN_CONT markers was pretty much expected, > since it's about 5 years since we enfroced it and new code won't > necessarily have it (and even back then I don't think we _always_ got > it right). > > That said, looking at the printk's in the lowmem code, I think it > could be useful if there was some effort to see if the code could > somehow avoid the multi-printk thing. This is actually one area where > > (a) the problem actually happens while the system is running, rather > than booting > > (b) I've seen line mixing in the past > > but the short term fix is to just add KERN_CONT markers to the lines > that are continuations. > > NOTE! The reason I mention that (a) thing that it has traditionally > made it much messier to do logging of continuation lines in the first > place (because more things are going on and often one problem leads to > another and then the mixing is much more likely), but I actually > intentionally made it more likely to trigger the flushing issue in > commit bfd8d3f23b51 ("printk: make reading the kernel log flush > pending lines"). > > So if there is an active system logger that is reading messages *when* > one of those "one line in multiple printk's" things happen, that log > reader will now potentially cause the logging to be broken up because > the act of reading will flush the pending lines. These changes have an interesting side-effect on sequences of printk()s that lack proper continuation: they introduced a discrepancy between dmesg output and the actual kernel output. Before: Atari hardware found: VIDEL STDMA-SCSI ST_MFP YM2149 PCM CODEC DSP56K SCC ANALOG_JOY BLITTER IDE TT_CLK FDC_SPEED Output of "dmesg" after: Atari hardware found: VIDEL STDMA-SCSI ST_MFP YM2149 PCM CODEC DSP56K SCC ANALOG_JOY BLITTER IDE TT_CLK FDC_SPEED Actual kernel output after: Atari hardware found: VIDEL STDMA-SCSI ST_MFP YM2149 PCM CODEC DSP56K SCC ANALOG_JOY BLITTER IDE TT_CLK FDC_SPEED Note that the above is really early in the boot process, right after the debug console is enabled, and before any system log consumer is running, Of course I'm converting this code to use pr_cont() anyway... Gr{oetje,eeting}s, Geert -- Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org In personal conversations with technical people, I call myself a hacker. But when I'm talking to journalists I just say "programmer" or something like that. -- Linus Torvalds