lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Sun, 23 Oct 2016 11:22:14 +0200 From: Geert Uytterhoeven <geert@...ux-m68k.org> To: Linus Torvalds <torvalds@...ux-foundation.org> Cc: Tetsuo Handa <penguin-kernel@...ove.sakura.ne.jp>, Linux Kernel Mailing List <linux-kernel@...r.kernel.org> Subject: Re: linux.git: printk() problem Hi Linus, On Wed, Oct 12, 2016 at 5:47 PM, Linus Torvalds <torvalds@...ux-foundation.org> wrote: > On Wed, Oct 12, 2016 at 6:30 AM, Tetsuo Handa > <penguin-kernel@...ove.sakura.ne.jp> 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@...ux-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
Powered by blists - more mailing lists