From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-1.0 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_PASS autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 599F7C43441 for ; Thu, 29 Nov 2018 10:09:36 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 034052081B for ; Thu, 29 Nov 2018 10:09:36 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 034052081B Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=i-love.sakura.ne.jp Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727615AbeK2VOX (ORCPT ); Thu, 29 Nov 2018 16:14:23 -0500 Received: from www262.sakura.ne.jp ([202.181.97.72]:10681 "EHLO www262.sakura.ne.jp" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726621AbeK2VOX (ORCPT ); Thu, 29 Nov 2018 16:14:23 -0500 Received: from fsav405.sakura.ne.jp (fsav405.sakura.ne.jp [133.242.250.104]) by www262.sakura.ne.jp (8.15.2/8.15.2) with ESMTP id wATA9Vnb082874; Thu, 29 Nov 2018 19:09:31 +0900 (JST) (envelope-from penguin-kernel@i-love.sakura.ne.jp) Received: from www262.sakura.ne.jp (202.181.97.72) by fsav405.sakura.ne.jp (F-Secure/fsigk_smtp/530/fsav405.sakura.ne.jp); Thu, 29 Nov 2018 19:09:31 +0900 (JST) X-Virus-Status: clean(F-Secure/fsigk_smtp/530/fsav405.sakura.ne.jp) Received: from [192.168.1.8] (softbank126126163036.bbtec.net [126.126.163.36]) (authenticated bits=0) by www262.sakura.ne.jp (8.15.2/8.15.2) with ESMTPSA id wATA9Ph8082712 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=NO); Thu, 29 Nov 2018 19:09:30 +0900 (JST) (envelope-from penguin-kernel@i-love.sakura.ne.jp) Subject: Re: [PATCH 3/3] lockdep: Use line-buffered printk() for lockdep messages. To: David Laight , "'Steven Rostedt'" , Petr Mladek , Sergey Senozhatsky Cc: Linus Torvalds , Sergey Senozhatsky , Dmitriy Vyukov , Alexander Potapenko , Fengguang Wu , Josh Poimboeuf , LKML , Andrew Morton , "linux-mm@kvack.org" , Ingo Molnar , Peter Zijlstra , Will Deacon References: <1541165517-3557-1-git-send-email-penguin-kernel@I-love.SAKURA.ne.jp> <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-80432d943aae@i-love.sakura.ne.jp> <20181109061204.GC599@jagdpanzerIV> <07dcbcb8-c5a7-8188-b641-c110ade1c5da@i-love.sakura.ne.jp> <20181109154326.apqkbsojmbg26o3b@pathway.suse.cz> <20181123124647.jmewvgrqdpra7wbm@pathway.suse.cz> <20181123105634.4956c255@vmware.local.home> From: Tetsuo Handa Message-ID: <1d29f61a-8f36-ab1c-bb92-402ee9ad161d@i-love.sakura.ne.jp> Date: Thu, 29 Nov 2018 19:09:26 +0900 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.3.1 MIME-Version: 1.0 In-Reply-To: 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 On 2018/11/28 22:29, David Laight wrote: > I also spent a week trying to work out why a customer kernel was > locking up - only to finally find out that the distro they were > using set 'panic on opps' - making it almost impossible to find > out what was happening. How can line buffering negatively affect this case? The current thread which triggered an oops will keep calling printk() until that current thread reaches panic(), won't it? The only case where line buffering negatively affects will be that the initial 10 bytes of a critical line failed to reach log_store() because some other thread (not the current thread doing a series of printk()) halted CPUs / reset the whole machine _before_ the initial 10 bytes of a critical line reaches log_store(). On 2018/11/26 13:34, Sergey Senozhatsky wrote: > Or... Instead. > We can just leave pr_cont() alone for now. And make it possible to > reconstruct messages - IOW, inject some info to printk messages. We > do this at Samsung (inject CPU number at the beginning of every > message. `cat serial.0 | grep "\[1\]"` to grep for all messages from > CPU1). Probably this would be the simplest thing. Yes, I sent a patch which helps reconstructing messages at http://lkml.kernel.org/r/1543045075-3008-1-git-send-email-penguin-kernel@I-love.SAKURA.ne.jp .