From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S933896AbcJLPrM (ORCPT ); Wed, 12 Oct 2016 11:47:12 -0400 Received: from mail-oi0-f41.google.com ([209.85.218.41]:33628 "EHLO mail-oi0-f41.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S933628AbcJLPrG (ORCPT ); Wed, 12 Oct 2016 11:47:06 -0400 MIME-Version: 1.0 In-Reply-To: <201610122230.DID43237.FSOHFFQOJOtVML@I-love.SAKURA.ne.jp> References: <201610122230.DID43237.FSOHFFQOJOtVML@I-love.SAKURA.ne.jp> From: Linus Torvalds Date: Wed, 12 Oct 2016 08:47:04 -0700 X-Google-Sender-Auth: wKKCTwDUDm4ueuvWfosH6tsCwQY Message-ID: Subject: Re: linux.git: printk() problem To: Tetsuo Handa Cc: 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 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. Now, honestly, that is something that we may end up reverting, but I'd _like_ to try not to. Because without that flushing, there might be one last partial line that the logger never sees. So it was me trying to be aggressive about those partial lines, and the *hope* is that we can just keep it, and that we can look at areas that have problems with it. We'll see. But the other issues are easily fixed by just adding KERN_CONT where appropriate. It was actually very much what you were supposed to do before too, if only as a marker to others that "yes, I'm actually doing this, and no, I'm not supposed to have a log level" (but with the new world order you actually *can* combine KERN_CONT with a loglevel, so that if the beginning od the line got flushed, the continuation can still be printed with the right log level). Linus