From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753888AbcJYEXD (ORCPT ); Tue, 25 Oct 2016 00:23:03 -0400 Received: from mail-oi0-f45.google.com ([209.85.218.45]:33082 "EHLO mail-oi0-f45.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751121AbcJYEXA (ORCPT ); Tue, 25 Oct 2016 00:23:00 -0400 MIME-Version: 1.0 In-Reply-To: <20161025040617.GA565@swordfish> References: <1477249607.3561.2.camel@perches.com> <20161024140845.GA626@swordfish> <20161025015554.GA495@swordfish> <20161025040617.GA565@swordfish> From: Linus Torvalds Date: Mon, 24 Oct 2016 21:15:41 -0700 X-Google-Sender-Auth: 1gHtFf_lDwFdYh-u-qbZmnNN8QQ Message-ID: Subject: Re: linux.git: printk() problem To: Sergey Senozhatsky Cc: Sergey Senozhatsky , Joe Perches , Geert Uytterhoeven , Tetsuo Handa , Linux Kernel Mailing List , Petr Mladek , Tejun Heo , Calvin Owens , Steven Rostedt , Andrew Morton 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 Mon, Oct 24, 2016 at 9:06 PM, Sergey Senozhatsky wrote: > > 1) the way we dumpstack on x86 (at least on x86) is a spaghetti of > printk() and pr_cont() calls. for instance, arch/x86/kernel/dumpstack_64.c > show_regs() does pr_cont() to print out the registers, while the stack and > backtrace are printed with printk(). so, I assume, the backtrace now will > look a bit upside-down, because cont lines are printed with the delay. > correct? No. Most cont lines never hit the delay, because when the line is completed, it is flushed (and then printed synchronously, assuming it can get the console lock). So the timeout only ever comes into effect if the line isn't completed in time at all. Which is actually very rare, and never happens for the "let's print things out in multiple chinks because we're using a loop". Similarly, if a new printk() happens due to interleaving, the previous buffered line is always flushed first, so buffering never causes out-of-order behavior. Basically, the only time the timer actually does anything is if something just does a printk() without a newline, and no other printouts happen for the next 0.1s. > 2) flush on oops. Again, really not an issue for the exact reason above: nothing is ever buffered when something new is printed. And all you need to guarantee that last line of the oops itself is printed is that it has a newline. So again, the timer only matters for the exceptional case, not for the normal situation. It's literally there to guarantee basic timeliness. Linus