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=-2.2 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS,URIBL_BLOCKED,USER_AGENT_SANE_1 autolearn=no 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 D6C9EC47E49 for ; Wed, 6 Nov 2019 16:28:01 +0000 (UTC) Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id A87952178F for ; Wed, 6 Nov 2019 16:28:01 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="Y1YmAeRC"; dkim=fail reason="signature verification failed" (2048-bit key) header.d=arista.com header.i=@arista.com header.b="CdDAyQ43" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org A87952178F Authentication-Results: mail.kernel.org; dmarc=fail (p=quarantine dis=none) header.from=arista.com Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-riscv-bounces+infradead-linux-riscv=archiver.kernel.org@lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20170209; h=Sender: Content-Transfer-Encoding:Content-Type:Cc:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:Date: Message-ID:From:References:To:Subject:Reply-To:Content-ID:Content-Description :Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=wRyhJyhLhMPRMvUiLt45FPZCFfvLIy5Vd3vsPsOtZkY=; b=Y1YmAeRCR7lpob yxk6DufEaEEUDGrCZoTXswnXMOhqwtKAguRyv2VVJtYUC9iBTEPfl88vUmSfOXdYEkmm5D2Df5SGn j68vXpeRifp1RGzb9MJLvdQ/E8fcmZH6NTsTd6hDhN3AGynL71yrngLt7qjvHWqg481iSPkDpXitk iEDno8kPmDpbjg4Pj7pPBKN/7+aAHsSKCqr7avgbzK4Xznk+7fi7QsQXIDbxNaPT+mUVddLPAjhuk n5F+rPVvkyH7kASx4mZtrwmRmXhb8CK5slBsaZePEXlQzYox965z4XMIITXsAit92OywB9Fzqa07W SCk8phtAVWFU1xlaqGtg==; Received: from localhost ([127.0.0.1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1iSOA4-00049m-KW; Wed, 06 Nov 2019 16:28:00 +0000 Received: from mail-pg1-x542.google.com ([2607:f8b0:4864:20::542]) by bombadil.infradead.org with esmtps (Exim 4.92.3 #3 (Red Hat Linux)) id 1iSOA1-00048M-6G for linux-riscv@lists.infradead.org; Wed, 06 Nov 2019 16:27:58 +0000 Received: by mail-pg1-x542.google.com with SMTP id k13so6161432pgh.3 for ; Wed, 06 Nov 2019 08:27:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=arista.com; s=googlenew; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=ILRv70ifsS4R/1VQKE/+LZSUA7puynZg3ILLVfy9hZk=; b=CdDAyQ43Jv36qsn9EkuUTZw8nt/+mOBKFoXfvdiENDFswTz54lmUElxhgNjniKxvLI izkIqTz62/+BsaxfKUgZ8S2RMG637jnDm+u0E1aGEUIzsEbWwsDV18EKNobslN2UlmYW WhC8g2REeIsonwoMKiOWl5u0CwVw1KGMvWwvlr5qjl4PZWOYWYsDg5p9F3UN6uGx7U/X y0XyKjPvcy9QpHnBDaHHpgbyRB/umgRbu9qBjoNr1nlR2d6FHD+lGiNEfvnrob7yl41T Rb+d5GPnNkrUNEfbqJzu6sSRExc4iKzcT+7U+xgq+doooMPjYjmc+eE6U7r6YPGlvf7O nVDg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=ILRv70ifsS4R/1VQKE/+LZSUA7puynZg3ILLVfy9hZk=; b=azAJt405JkfuSmNjrIRgWKm/9ujad7+Wdc7wnSb54pNiOEf+b0aCCkEPRGw5D2R3HL y4S41wOGcYtN5Ldkp38h1uhMqBpON4hUNACA87fyDyApya+Hwq898tmTT+Rh08FrlKo9 H9YZe9V8TeLElwJyX6eypQuE1b6kvIYgKf++kjXDkLr2n2oRdtrvVYlTYufxt/oqnO8k ifPCOOUJTtZRK/M3QqliYmru5Ov/hWOpVnFOzpjbQNJjqfhi+j4O7/MP/O8OHcZuAMnp WjLEC4/THTyizfbaibh03AoZiZjwt3GqI31lf0RumvCD5cf5v1Yt/fTh2agSOlMNKqDx n2zg== X-Gm-Message-State: APjAAAUHaQRiy362GY6cx5c8JWAKLJIov6NEdnAM/qjTaGfoLzoIydc8 LqlQwFDwo8BuBtE0UzV9PGkgZg== X-Google-Smtp-Source: APXvYqwbfJs+Rexz1GsgVLAw54LaKdVOAeh16aFzChJ5nDbwhrH1h0946xekzcVYBN4WN+Q23T6sbg== X-Received: by 2002:a63:66c1:: with SMTP id a184mr3898212pgc.164.1573057676186; Wed, 06 Nov 2019 08:27:56 -0800 (PST) Received: from [10.83.36.153] ([217.173.96.166]) by smtp.gmail.com with ESMTPSA id m15sm21253387pgv.58.2019.11.06.08.27.41 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 06 Nov 2019 08:27:55 -0800 (PST) Subject: Re: [PATCH 00/50] Add log level to show_stack() To: Peter Zijlstra References: <20191106030542.868541-1-dima@arista.com> <20191106092039.GT4131@hirez.programming.kicks-ass.net> From: Dmitry Safonov Message-ID: <10db6fa1-5b17-ebe6-09e0-6335e09e4db8@arista.com> Date: Wed, 6 Nov 2019 16:27:33 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.1.1 MIME-Version: 1.0 In-Reply-To: <20191106092039.GT4131@hirez.programming.kicks-ass.net> Content-Language: en-US X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20191106_082757_260428_BF9969A7 X-CRM114-Status: GOOD ( 18.87 ) X-BeenThere: linux-riscv@lists.infradead.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Juri Lelli , linux-sh@vger.kernel.org, Catalin Marinas , Ben Segall , Guo Ren , Pavel Machek , Vincent Guittot , Paul Burton , Michael Ellerman , Geert Uytterhoeven , Mel Gorman , Jiri Slaby , Matt Turner , uclinux-h8-devel@lists.sourceforge.jp, Len Brown , linux-pm@vger.kernel.org, Heiko Carstens , linux-um@lists.infradead.org, Thomas Gleixner , Dietmar Eggemann , Richard Henderson , Greg Kroah-Hartman , "Rafael J. Wysocki" , linux-kernel@vger.kernel.org, Ralf Baechle , Paul Mackerras , Andrew Morton , linux-ia64@vger.kernel.org, Tetsuo Handa , James Hogan , "James E.J. Bottomley" , Max Filippov , Vincent Chen , Ingo Molnar , linux-s390@vger.kernel.org, linux-c6x-dev@linux-c6x.org, Yoshinori Sato , linux-hexagon@vger.kernel.org, Helge Deller , linux-xtensa@linux-xtensa.org, Vasily Gorbik , Aurelien Jacquiot , linux-m68k@lists.linux-m68k.org, Stafford Horne , linux-arm-kernel@lists.infradead.org, Chris Zankel , Tony Luck , Douglas Anderson , Benjamin Herrenschmidt , Dmitry Safonov <0x7f454c46@gmail.com>, Will Deacon , Daniel Thompson , Brian Cain , Christian Borntraeger , kgdb-bugreport@lists.sourceforge.net, linux-snps-arc@lists.infradead.org, Fenghua Yu , Borislav Petkov , Jeff Dike , Steven Rostedt , Ivan Kokshaysky , Greentime Hu , Guan Xuetao , linux-parisc@vger.kernel.org, linux-alpha@vger.kernel.org, Ley Foon Tan , "David S. Miller" , Rich Felker , Petr Mladek , "H. Peter Anvin" , sparclinux@vger.kernel.org, linux-riscv@lists.infradead.org, Anton Ivanov , Jonas Bonn , Richard Weinberger , x86@kernel.org, Russell King , clang-built-linux@googlegroups.com, Ingo Molnar , Mark Salter , Albert Ou , Stefan Kristiansson , openrisc@lists.librecores.org, Paul Walmsley , Michal Simek , Vineet Gupta , linux-mips@vger.kernel.org, Sergey Senozhatsky , Palmer Dabbelt , Jason Wessel , nios2-dev@lists.rocketboards.org, linuxppc-dev@lists.ozlabs.org Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-riscv" Errors-To: linux-riscv-bounces+infradead-linux-riscv=archiver.kernel.org@lists.infradead.org Hi Peter, On 11/6/19 9:20 AM, Peter Zijlstra wrote: > On Wed, Nov 06, 2019 at 03:04:51AM +0000, Dmitry Safonov wrote: >> Add log level argument to show_stack(). >> Done in three stages: >> 1. Introducing show_stack_loglvl() for every architecture >> 2. Migrating old users with an explicit log level >> 3. Renaming show_stack_loglvl() into show_stack() >> >> Justification: >> o It's a design mistake to move a business-logic decision >> into platform realization detail. >> o I have currently two patches sets that would benefit from this work: >> Removing console_loglevel jumps in sysrq driver [1] >> Hung task warning before panic [2] - suggested by Tetsuo (but he >> probably didn't realise what it would involve). >> o While doing (1), (2) the backtraces were adjusted to headers >> and other messages for each situation - so there won't be a situation >> when the backtrace is printed, but the headers are missing because >> they have lesser log level (or the reverse). >> o As the result in (2) plays with console_loglevel for kdb are removed. > > I really don't understand that word salad. Why are you doing this? > Sorry, I should have tried to describe better. I'm trying to remove external users of console_loglevel by following reasons: - changing console_loglevel on SMP means that unwanted messages from other CPUs will appear (that have lower log level) - on UMP unwanted messages may appear if the code is preempted while it hasn't set the console_loglevel back to old - rising console_loglevel to print wanted message(s) may not work at all if printk() has being delayed and the console_loglevel is already set back to old value Sysrq driver changes console_loglevel because it needs to print message with a specific log level (the code said userspace relies on this). Kdb changes console_loglevel to print backtrace as the log level depends on architecture realisation. I also have patches in wip those needs to print backtrace with specific loglevel (higher when it's critical, lower when it's notice and shouldn't go to serial console). Besides on local tests I see hits those have headers (messages like "Backtrace: ") without an actual backtrace and the reverse - a backtrace without a reason for it. It's quite annoying and worth addressing by syncing headers log levels to backtraces. Thanks, Dmitry _______________________________________________ linux-riscv mailing list linux-riscv@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-riscv 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=-2.0 required=3.0 tests=DKIM_INVALID,DKIM_SIGNED, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS, USER_AGENT_SANE_1 autolearn=no 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 21E4AC5DF63 for ; Wed, 6 Nov 2019 20:03:42 +0000 (UTC) Received: from lists.ozlabs.org (lists.ozlabs.org [203.11.71.2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id B64BE2173E for ; Wed, 6 Nov 2019 20:03:41 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=fail reason="signature verification failed" (2048-bit key) header.d=arista.com header.i=@arista.com header.b="CdDAyQ43" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org B64BE2173E Authentication-Results: mail.kernel.org; dmarc=fail (p=quarantine dis=none) header.from=arista.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=linuxppc-dev-bounces+linuxppc-dev=archiver.kernel.org@lists.ozlabs.org Received: from bilbo.ozlabs.org (lists.ozlabs.org [IPv6:2401:3900:2:1::3]) by lists.ozlabs.org (Postfix) with ESMTP id 477ct32rp9zF3ny for ; Thu, 7 Nov 2019 07:03:39 +1100 (AEDT) Authentication-Results: lists.ozlabs.org; spf=pass (sender SPF authorized) smtp.mailfrom=arista.com (client-ip=2607:f8b0:4864:20::544; helo=mail-pg1-x544.google.com; envelope-from=dima@arista.com; receiver=) Authentication-Results: lists.ozlabs.org; dmarc=pass (p=quarantine dis=none) header.from=arista.com Authentication-Results: lists.ozlabs.org; dkim=pass (2048-bit key; unprotected) header.d=arista.com header.i=@arista.com header.b="CdDAyQ43"; dkim-atps=neutral Received: from mail-pg1-x544.google.com (mail-pg1-x544.google.com [IPv6:2607:f8b0:4864:20::544]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by lists.ozlabs.org (Postfix) with ESMTPS id 477X5F6n8FzF0Tr for ; Thu, 7 Nov 2019 03:27:59 +1100 (AEDT) Received: by mail-pg1-x544.google.com with SMTP id e4so17498188pgs.1 for ; Wed, 06 Nov 2019 08:27:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=arista.com; s=googlenew; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=ILRv70ifsS4R/1VQKE/+LZSUA7puynZg3ILLVfy9hZk=; b=CdDAyQ43Jv36qsn9EkuUTZw8nt/+mOBKFoXfvdiENDFswTz54lmUElxhgNjniKxvLI izkIqTz62/+BsaxfKUgZ8S2RMG637jnDm+u0E1aGEUIzsEbWwsDV18EKNobslN2UlmYW WhC8g2REeIsonwoMKiOWl5u0CwVw1KGMvWwvlr5qjl4PZWOYWYsDg5p9F3UN6uGx7U/X y0XyKjPvcy9QpHnBDaHHpgbyRB/umgRbu9qBjoNr1nlR2d6FHD+lGiNEfvnrob7yl41T Rb+d5GPnNkrUNEfbqJzu6sSRExc4iKzcT+7U+xgq+doooMPjYjmc+eE6U7r6YPGlvf7O nVDg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=ILRv70ifsS4R/1VQKE/+LZSUA7puynZg3ILLVfy9hZk=; b=VvceebfdjciPOLIAQMZf/RLuxL/x8wboSU3PPj+nxkwZhBZR04y8lkn3uM8hHFKcqC uDwZeIOTGqInaqLJhmTe1g1wwdjUEEO7Ek02YDpocLhCcgC/3Qsz0KYNDt0o551F+4X/ qnt74VJ6KRyaieq0NK0aOLVPPfAMdkTdkfoBkzLQO0YpZs5ZDD+Zwk0uoCkMkpjjbZ6h WL+TrV8hICMMdefQAvIdspmwNd0oXM3UCjZ3Sc21InqPG8pU0Y5vKVuKABCD5WhBzOjP oG3kLcWgP5DX1V3ZlJ8uxjmr1CyGeu+dodvYT6ZZ60ofU0nKQPZdG6Yb/AZi+PrvzYXm Brfw== X-Gm-Message-State: APjAAAXc7YZijuznlcFU3tMWKWip4/qtNxPZqu/NpPNE4MJ77vENCJqn C39AmUDmqDSwAYlOBusCcCc1xQ== X-Google-Smtp-Source: APXvYqwbfJs+Rexz1GsgVLAw54LaKdVOAeh16aFzChJ5nDbwhrH1h0946xekzcVYBN4WN+Q23T6sbg== X-Received: by 2002:a63:66c1:: with SMTP id a184mr3898212pgc.164.1573057676186; Wed, 06 Nov 2019 08:27:56 -0800 (PST) Received: from [10.83.36.153] ([217.173.96.166]) by smtp.gmail.com with ESMTPSA id m15sm21253387pgv.58.2019.11.06.08.27.41 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 06 Nov 2019 08:27:55 -0800 (PST) Subject: Re: [PATCH 00/50] Add log level to show_stack() To: Peter Zijlstra References: <20191106030542.868541-1-dima@arista.com> <20191106092039.GT4131@hirez.programming.kicks-ass.net> From: Dmitry Safonov Message-ID: <10db6fa1-5b17-ebe6-09e0-6335e09e4db8@arista.com> Date: Wed, 6 Nov 2019 16:27:33 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.1.1 MIME-Version: 1.0 In-Reply-To: <20191106092039.GT4131@hirez.programming.kicks-ass.net> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Thu, 07 Nov 2019 06:55:51 +1100 X-BeenThere: linuxppc-dev@lists.ozlabs.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Linux on PowerPC Developers Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Juri Lelli , linux-sh@vger.kernel.org, Catalin Marinas , Ben Segall , Guo Ren , Pavel Machek , Vincent Guittot , Paul Burton , Geert Uytterhoeven , Mel Gorman , Jiri Slaby , Matt Turner , uclinux-h8-devel@lists.sourceforge.jp, Len Brown , linux-pm@vger.kernel.org, Heiko Carstens , linux-um@lists.infradead.org, Thomas Gleixner , Dietmar Eggemann , Richard Henderson , Greg Kroah-Hartman , "Rafael J. Wysocki" , linux-kernel@vger.kernel.org, Ralf Baechle , Paul Mackerras , Andrew Morton , linux-ia64@vger.kernel.org, Tetsuo Handa , James Hogan , "James E.J. Bottomley" , Max Filippov , Vincent Chen , Ingo Molnar , linux-s390@vger.kernel.org, linux-c6x-dev@linux-c6x.org, Yoshinori Sato , linux-hexagon@vger.kernel.org, Helge Deller , linux-xtensa@linux-xtensa.org, Vasily Gorbik , Aurelien Jacquiot , linux-m68k@lists.linux-m68k.org, Stafford Horne , linux-arm-kernel@lists.infradead.org, Chris Zankel , Tony Luck , Douglas Anderson , Dmitry Safonov <0x7f454c46@gmail.com>, Will Deacon , Daniel Thompson , Brian Cain , Christian Borntraeger , kgdb-bugreport@lists.sourceforge.net, linux-snps-arc@lists.infradead.org, Fenghua Yu , Borislav Petkov , Jeff Dike , Steven Rostedt , Ivan Kokshaysky , Greentime Hu , Guan Xuetao , linux-parisc@vger.kernel.org, linux-alpha@vger.kernel.org, Ley Foon Tan , "David S. Miller" , Rich Felker , Petr Mladek , "H. Peter Anvin" , sparclinux@vger.kernel.org, linux-riscv@lists.infradead.org, Anton Ivanov , Jonas Bonn , Richard Weinberger , x86@kernel.org, Russell King , clang-built-linux@googlegroups.com, Ingo Molnar , Mark Salter , Albert Ou , Stefan Kristiansson , openrisc@lists.librecores.org, Paul Walmsley , Michal Simek , Vineet Gupta , linux-mips@vger.kernel.org, Sergey Senozhatsky , Palmer Dabbelt , Jason Wessel , nios2-dev@lists.rocketboards.org, linuxppc-dev@lists.ozlabs.org Errors-To: linuxppc-dev-bounces+linuxppc-dev=archiver.kernel.org@lists.ozlabs.org Sender: "Linuxppc-dev" Hi Peter, On 11/6/19 9:20 AM, Peter Zijlstra wrote: > On Wed, Nov 06, 2019 at 03:04:51AM +0000, Dmitry Safonov wrote: >> Add log level argument to show_stack(). >> Done in three stages: >> 1. Introducing show_stack_loglvl() for every architecture >> 2. Migrating old users with an explicit log level >> 3. Renaming show_stack_loglvl() into show_stack() >> >> Justification: >> o It's a design mistake to move a business-logic decision >> into platform realization detail. >> o I have currently two patches sets that would benefit from this work: >> Removing console_loglevel jumps in sysrq driver [1] >> Hung task warning before panic [2] - suggested by Tetsuo (but he >> probably didn't realise what it would involve). >> o While doing (1), (2) the backtraces were adjusted to headers >> and other messages for each situation - so there won't be a situation >> when the backtrace is printed, but the headers are missing because >> they have lesser log level (or the reverse). >> o As the result in (2) plays with console_loglevel for kdb are removed. > > I really don't understand that word salad. Why are you doing this? > Sorry, I should have tried to describe better. I'm trying to remove external users of console_loglevel by following reasons: - changing console_loglevel on SMP means that unwanted messages from other CPUs will appear (that have lower log level) - on UMP unwanted messages may appear if the code is preempted while it hasn't set the console_loglevel back to old - rising console_loglevel to print wanted message(s) may not work at all if printk() has being delayed and the console_loglevel is already set back to old value Sysrq driver changes console_loglevel because it needs to print message with a specific log level (the code said userspace relies on this). Kdb changes console_loglevel to print backtrace as the log level depends on architecture realisation. I also have patches in wip those needs to print backtrace with specific loglevel (higher when it's critical, lower when it's notice and shouldn't go to serial console). Besides on local tests I see hits those have headers (messages like "Backtrace: ") without an actual backtrace and the reverse - a backtrace without a reason for it. It's quite annoying and worth addressing by syncing headers log levels to backtraces. Thanks, Dmitry 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=-2.2 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS,URIBL_BLOCKED,USER_AGENT_SANE_1 autolearn=no 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 D1C61C5DF63 for ; Wed, 6 Nov 2019 16:28:01 +0000 (UTC) Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id A08122067B for ; Wed, 6 Nov 2019 16:28:01 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="BxOuSGSb"; dkim=fail reason="signature verification failed" (2048-bit key) header.d=arista.com header.i=@arista.com header.b="CdDAyQ43" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org A08122067B Authentication-Results: mail.kernel.org; dmarc=fail (p=quarantine dis=none) header.from=arista.com Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-snps-arc-bounces+linux-snps-arc=archiver.kernel.org@lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20170209; h=Sender: Content-Transfer-Encoding:Content-Type:Cc:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:Date: Message-ID:From:References:To:Subject:Reply-To:Content-ID:Content-Description :Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=iPCCugWfxxCbBgX4qpIVRQwjYe5fP2yTnirMLShmNuI=; b=BxOuSGSbbUM972 Xd+c3/US9kRVCuJpkffeBZxi/382T/LHUzNGMKoAhbJ3UCSsTjtF7aXwIRw55PcY6yOmkRj1tL0KL CpCmTaLS/YwkyYuGulVRyTt10s3DHvYzVI/Ze6CI2uvBYeC5QBpvyn0doomPZ+CI8nspIU/x2+6ME UVf7JC1X7qYIFFuEo/z9WEgmCxpgR8s+bjdwtHc2NOrbbj35h2krj7qgh4XtraMK1c8DsYhSHhUef suFYLiYbph88AqnCurOXKS+N1MR7yQnElwu/FlkZR63bq3La/YJEK9wu9txhMFXdMw0bReiDrykum OpVuLdws+l4bnNTd7Pog==; Received: from localhost ([127.0.0.1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1iSOA4-00049U-Ai; Wed, 06 Nov 2019 16:28:00 +0000 Received: from mail-pg1-x542.google.com ([2607:f8b0:4864:20::542]) by bombadil.infradead.org with esmtps (Exim 4.92.3 #3 (Red Hat Linux)) id 1iSOA1-00048J-69 for linux-snps-arc@lists.infradead.org; Wed, 06 Nov 2019 16:27:58 +0000 Received: by mail-pg1-x542.google.com with SMTP id l24so17474426pgh.10 for ; Wed, 06 Nov 2019 08:27:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=arista.com; s=googlenew; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=ILRv70ifsS4R/1VQKE/+LZSUA7puynZg3ILLVfy9hZk=; b=CdDAyQ43Jv36qsn9EkuUTZw8nt/+mOBKFoXfvdiENDFswTz54lmUElxhgNjniKxvLI izkIqTz62/+BsaxfKUgZ8S2RMG637jnDm+u0E1aGEUIzsEbWwsDV18EKNobslN2UlmYW WhC8g2REeIsonwoMKiOWl5u0CwVw1KGMvWwvlr5qjl4PZWOYWYsDg5p9F3UN6uGx7U/X y0XyKjPvcy9QpHnBDaHHpgbyRB/umgRbu9qBjoNr1nlR2d6FHD+lGiNEfvnrob7yl41T Rb+d5GPnNkrUNEfbqJzu6sSRExc4iKzcT+7U+xgq+doooMPjYjmc+eE6U7r6YPGlvf7O nVDg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=ILRv70ifsS4R/1VQKE/+LZSUA7puynZg3ILLVfy9hZk=; b=qJuFj8FxnFeP1z661N0AqeA/JRAUTVRbAXuau/py9Eg+iEXmOYl/RMAu+kY9d73vQ8 b2D7D1eiAHR+Bvsa6uaJg8RUD8rqtIFRRSgMDr++6fe7hBKh6LPYIHP2gl6TZM9WtDbj TYss/qaBODOHrhc8cMboHVeqytBMiaXYeJkljwv45gawjqGo5o7XEVcS+O9R7nwCsXX2 nr0ISGI7My0PmtcI5Dx9wk5ZKBBJ78b68C/JPpUar/AxThsF0JTjZHfC24XMlYtQce/2 Ttu9pK0gbg420ZBntf21iqRnmFkgjq8rhTcehHoOBmrXQkX6bpQbnXJEnINmJVWfDWB1 BlOw== X-Gm-Message-State: APjAAAXlUyzaKOtdoWVM3eRyu8xUiru5kji+ohFMInuaBjQp7AK+7j9v xag1IkWn6pWMC9+eMWfv171KXQ== X-Google-Smtp-Source: APXvYqwbfJs+Rexz1GsgVLAw54LaKdVOAeh16aFzChJ5nDbwhrH1h0946xekzcVYBN4WN+Q23T6sbg== X-Received: by 2002:a63:66c1:: with SMTP id a184mr3898212pgc.164.1573057676186; Wed, 06 Nov 2019 08:27:56 -0800 (PST) Received: from [10.83.36.153] ([217.173.96.166]) by smtp.gmail.com with ESMTPSA id m15sm21253387pgv.58.2019.11.06.08.27.41 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 06 Nov 2019 08:27:55 -0800 (PST) Subject: Re: [PATCH 00/50] Add log level to show_stack() To: Peter Zijlstra References: <20191106030542.868541-1-dima@arista.com> <20191106092039.GT4131@hirez.programming.kicks-ass.net> From: Dmitry Safonov Message-ID: <10db6fa1-5b17-ebe6-09e0-6335e09e4db8@arista.com> Date: Wed, 6 Nov 2019 16:27:33 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.1.1 MIME-Version: 1.0 In-Reply-To: <20191106092039.GT4131@hirez.programming.kicks-ass.net> Content-Language: en-US X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20191106_082757_264434_21CD295B X-CRM114-Status: GOOD ( 18.87 ) X-BeenThere: linux-snps-arc@lists.infradead.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Linux on Synopsys ARC Processors List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Juri Lelli , linux-sh@vger.kernel.org, Catalin Marinas , Ben Segall , Guo Ren , Pavel Machek , Vincent Guittot , Paul Burton , Michael Ellerman , Geert Uytterhoeven , Mel Gorman , Jiri Slaby , Matt Turner , uclinux-h8-devel@lists.sourceforge.jp, Len Brown , linux-pm@vger.kernel.org, Heiko Carstens , linux-um@lists.infradead.org, Thomas Gleixner , Dietmar Eggemann , Richard Henderson , Greg Kroah-Hartman , "Rafael J. Wysocki" , linux-kernel@vger.kernel.org, Ralf Baechle , Paul Mackerras , Andrew Morton , linux-ia64@vger.kernel.org, Tetsuo Handa , James Hogan , "James E.J. Bottomley" , Max Filippov , Vincent Chen , Ingo Molnar , linux-s390@vger.kernel.org, linux-c6x-dev@linux-c6x.org, Yoshinori Sato , linux-hexagon@vger.kernel.org, Helge Deller , linux-xtensa@linux-xtensa.org, Vasily Gorbik , Aurelien Jacquiot , linux-m68k@lists.linux-m68k.org, Stafford Horne , linux-arm-kernel@lists.infradead.org, Chris Zankel , Tony Luck , Douglas Anderson , Benjamin Herrenschmidt , Dmitry Safonov <0x7f454c46@gmail.com>, Will Deacon , Daniel Thompson , Brian Cain , Christian Borntraeger , kgdb-bugreport@lists.sourceforge.net, linux-snps-arc@lists.infradead.org, Fenghua Yu , Borislav Petkov , Jeff Dike , Steven Rostedt , Ivan Kokshaysky , Greentime Hu , Guan Xuetao , linux-parisc@vger.kernel.org, linux-alpha@vger.kernel.org, Ley Foon Tan , "David S. Miller" , Rich Felker , Petr Mladek , "H. Peter Anvin" , sparclinux@vger.kernel.org, linux-riscv@lists.infradead.org, Anton Ivanov , Jonas Bonn , Richard Weinberger , x86@kernel.org, Russell King , clang-built-linux@googlegroups.com, Ingo Molnar , Mark Salter , Albert Ou , Stefan Kristiansson , openrisc@lists.librecores.org, Paul Walmsley , Michal Simek , Vineet Gupta , linux-mips@vger.kernel.org, Sergey Senozhatsky , Palmer Dabbelt , Jason Wessel , nios2-dev@lists.rocketboards.org, linuxppc-dev@lists.ozlabs.org Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-snps-arc" Errors-To: linux-snps-arc-bounces+linux-snps-arc=archiver.kernel.org@lists.infradead.org Hi Peter, On 11/6/19 9:20 AM, Peter Zijlstra wrote: > On Wed, Nov 06, 2019 at 03:04:51AM +0000, Dmitry Safonov wrote: >> Add log level argument to show_stack(). >> Done in three stages: >> 1. Introducing show_stack_loglvl() for every architecture >> 2. Migrating old users with an explicit log level >> 3. Renaming show_stack_loglvl() into show_stack() >> >> Justification: >> o It's a design mistake to move a business-logic decision >> into platform realization detail. >> o I have currently two patches sets that would benefit from this work: >> Removing console_loglevel jumps in sysrq driver [1] >> Hung task warning before panic [2] - suggested by Tetsuo (but he >> probably didn't realise what it would involve). >> o While doing (1), (2) the backtraces were adjusted to headers >> and other messages for each situation - so there won't be a situation >> when the backtrace is printed, but the headers are missing because >> they have lesser log level (or the reverse). >> o As the result in (2) plays with console_loglevel for kdb are removed. > > I really don't understand that word salad. Why are you doing this? > Sorry, I should have tried to describe better. I'm trying to remove external users of console_loglevel by following reasons: - changing console_loglevel on SMP means that unwanted messages from other CPUs will appear (that have lower log level) - on UMP unwanted messages may appear if the code is preempted while it hasn't set the console_loglevel back to old - rising console_loglevel to print wanted message(s) may not work at all if printk() has being delayed and the console_loglevel is already set back to old value Sysrq driver changes console_loglevel because it needs to print message with a specific log level (the code said userspace relies on this). Kdb changes console_loglevel to print backtrace as the log level depends on architecture realisation. I also have patches in wip those needs to print backtrace with specific loglevel (higher when it's critical, lower when it's notice and shouldn't go to serial console). Besides on local tests I see hits those have headers (messages like "Backtrace: ") without an actual backtrace and the reverse - a backtrace without a reason for it. It's quite annoying and worth addressing by syncing headers log levels to backtraces. Thanks, Dmitry _______________________________________________ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc From mboxrd@z Thu Jan 1 00:00:00 1970 From: Dmitry Safonov Date: Wed, 6 Nov 2019 16:27:33 +0000 Subject: [OpenRISC] [PATCH 00/50] Add log level to show_stack() In-Reply-To: <20191106092039.GT4131@hirez.programming.kicks-ass.net> References: <20191106030542.868541-1-dima@arista.com> <20191106092039.GT4131@hirez.programming.kicks-ass.net> Message-ID: <10db6fa1-5b17-ebe6-09e0-6335e09e4db8@arista.com> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: openrisc@lists.librecores.org Hi Peter, On 11/6/19 9:20 AM, Peter Zijlstra wrote: > On Wed, Nov 06, 2019 at 03:04:51AM +0000, Dmitry Safonov wrote: >> Add log level argument to show_stack(). >> Done in three stages: >> 1. Introducing show_stack_loglvl() for every architecture >> 2. Migrating old users with an explicit log level >> 3. Renaming show_stack_loglvl() into show_stack() >> >> Justification: >> o It's a design mistake to move a business-logic decision >> into platform realization detail. >> o I have currently two patches sets that would benefit from this work: >> Removing console_loglevel jumps in sysrq driver [1] >> Hung task warning before panic [2] - suggested by Tetsuo (but he >> probably didn't realise what it would involve). >> o While doing (1), (2) the backtraces were adjusted to headers >> and other messages for each situation - so there won't be a situation >> when the backtrace is printed, but the headers are missing because >> they have lesser log level (or the reverse). >> o As the result in (2) plays with console_loglevel for kdb are removed. > > I really don't understand that word salad. Why are you doing this? > Sorry, I should have tried to describe better. I'm trying to remove external users of console_loglevel by following reasons: - changing console_loglevel on SMP means that unwanted messages from other CPUs will appear (that have lower log level) - on UMP unwanted messages may appear if the code is preempted while it hasn't set the console_loglevel back to old - rising console_loglevel to print wanted message(s) may not work at all if printk() has being delayed and the console_loglevel is already set back to old value Sysrq driver changes console_loglevel because it needs to print message with a specific log level (the code said userspace relies on this). Kdb changes console_loglevel to print backtrace as the log level depends on architecture realisation. I also have patches in wip those needs to print backtrace with specific loglevel (higher when it's critical, lower when it's notice and shouldn't go to serial console). Besides on local tests I see hits those have headers (messages like "Backtrace: ") without an actual backtrace and the reverse - a backtrace without a reason for it. It's quite annoying and worth addressing by syncing headers log levels to backtraces. Thanks, Dmitry From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Subject: Re: [PATCH 00/50] Add log level to show_stack() References: <20191106030542.868541-1-dima@arista.com> <20191106092039.GT4131@hirez.programming.kicks-ass.net> From: Dmitry Safonov Message-ID: <10db6fa1-5b17-ebe6-09e0-6335e09e4db8@arista.com> Date: Wed, 6 Nov 2019 16:27:33 +0000 MIME-Version: 1.0 In-Reply-To: <20191106092039.GT4131@hirez.programming.kicks-ass.net> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit To: Peter Zijlstra Cc: linux-kernel@vger.kernel.org, Dmitry Safonov <0x7f454c46@gmail.com>, Andrew Morton , Greg Kroah-Hartman , Ingo Molnar , Jiri Slaby , Petr Mladek , Sergey Senozhatsky , Steven Rostedt , Tetsuo Handa , Albert Ou , Ben Segall , Dietmar Eggemann , Greentime Hu , Ingo Molnar , James Hogan , Juri Lelli , Mel Gorman , Michal Simek , Palmer Dabbelt , Paul Burton , Paul Walmsley , Ralf Baechle , Thomas Gleixner , Vincent Chen , Vincent Guittot , Will Deacon , linux-mips@vger.kernel.org, linux-riscv@lists.infradead.org, Ivan Kokshaysky , Matt Turner , Richard Henderson , linux-alpha@vger.kernel.org, Vineet Gupta , linux-snps-arc@lists.infradead.org, Russell King , linux-arm-kernel@lists.infradead.org, clang-built-linux@googlegroups.com, Catalin Marinas , Aurelien Jacquiot , Mark Salter , linux-c6x-dev@linux-c6x.org, Guo Ren , Yoshinori Sato , uclinux-h8-devel@lists.sourceforge.jp, Brian Cain , linux-hexagon@vger.kernel.org, Fenghua Yu , Tony Luck , linux-ia64@vger.kernel.org, Geert Uytterhoeven , linux-m68k@lists.linux-m68k.org, Ley Foon Tan , nios2-dev@lists.rocketboards.org, Jonas Bonn , Stafford Horne , Stefan Kristiansson , openrisc@lists.librecores.org, Helge Deller , "James E.J. Bottomley" , linux-parisc@vger.kernel.org, Benjamin Herrenschmidt , Michael Ellerman , Paul Mackerras , linuxppc-dev@lists.ozlabs.org, Christian Borntraeger , Heiko Carstens , Vasily Gorbik , linux-s390@vger.kernel.org, Rich Felker , linux-sh@vger.kernel.org, "David S. Miller" , sparclinux@vger.kernel.org, Anton Ivanov , Jeff Dike , Richard Weinberger , linux-um@lists.infradead.org, Guan Xuetao , Borislav Petkov , "H. Peter Anvin" , x86@kernel.org, Chris Zankel , Max Filippov , linux-xtensa@linux-xtensa.org, Len Brown , Pavel Machek , "Rafael J. Wysocki" , linux-pm@vger.kernel.org, Daniel Thompson , Douglas Anderson , Jason Wessel , kgdb-bugreport@lists.sourceforge.net List-ID: Hi Peter, On 11/6/19 9:20 AM, Peter Zijlstra wrote: > On Wed, Nov 06, 2019 at 03:04:51AM +0000, Dmitry Safonov wrote: >> Add log level argument to show_stack(). >> Done in three stages: >> 1. Introducing show_stack_loglvl() for every architecture >> 2. Migrating old users with an explicit log level >> 3. Renaming show_stack_loglvl() into show_stack() >> >> Justification: >> o It's a design mistake to move a business-logic decision >> into platform realization detail. >> o I have currently two patches sets that would benefit from this work: >> Removing console_loglevel jumps in sysrq driver [1] >> Hung task warning before panic [2] - suggested by Tetsuo (but he >> probably didn't realise what it would involve). >> o While doing (1), (2) the backtraces were adjusted to headers >> and other messages for each situation - so there won't be a situation >> when the backtrace is printed, but the headers are missing because >> they have lesser log level (or the reverse). >> o As the result in (2) plays with console_loglevel for kdb are removed. > > I really don't understand that word salad. Why are you doing this? > Sorry, I should have tried to describe better. I'm trying to remove external users of console_loglevel by following reasons: - changing console_loglevel on SMP means that unwanted messages from other CPUs will appear (that have lower log level) - on UMP unwanted messages may appear if the code is preempted while it hasn't set the console_loglevel back to old - rising console_loglevel to print wanted message(s) may not work at all if printk() has being delayed and the console_loglevel is already set back to old value Sysrq driver changes console_loglevel because it needs to print message with a specific log level (the code said userspace relies on this). Kdb changes console_loglevel to print backtrace as the log level depends on architecture realisation. I also have patches in wip those needs to print backtrace with specific loglevel (higher when it's critical, lower when it's notice and shouldn't go to serial console). Besides on local tests I see hits those have headers (messages like "Backtrace: ") without an actual backtrace and the reverse - a backtrace without a reason for it. It's quite annoying and worth addressing by syncing headers log levels to backtraces. Thanks, Dmitry From mboxrd@z Thu Jan 1 00:00:00 1970 From: Dmitry Safonov Subject: Re: [PATCH 00/50] Add log level to show_stack() Date: Wed, 6 Nov 2019 16:27:33 +0000 Message-ID: <10db6fa1-5b17-ebe6-09e0-6335e09e4db8@arista.com> References: <20191106030542.868541-1-dima@arista.com> <20191106092039.GT4131@hirez.programming.kicks-ass.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20170209; h=Sender: Content-Transfer-Encoding:Content-Type:Cc:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:Date: Message-ID:From:References:To:Subject:Reply-To:Content-ID:Content-Description :Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=iPCCugWfxxCbBgX4qpIVRQwjYe5fP2yTnirMLShmNuI=; b=BxOuSGSbbUM972 Xd+c3/US9kRVCuJpkffeBZxi/382T/LHUzNGMKoAhbJ3UCSsTjtF7aXwIRw55PcY6yOmkRj1tL0KL CpCmTaLS/YwkyYuGulVRyTt10s3DHvYzVI/Ze6CI2uvBYeC5QBpvyn0doomPZ+CI8nspIU/x2+6ME UVf7JC1X7qYIFFuEo/z9WEgmCxpgR8s+bjdwtHc2NOrbbj35h2krj7qgh4XtraMK1c8DsYhSHhUef suFYLiYbph88AqnCurOXKS+N1MR7yQnElwu/FlkZR63bq3La/YJEK9wu9txhMFXdMw0bReiDrykum OpVuLdws+l4bnNTd7Pog==; DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=arista.com; s=googlenew; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=ILRv70ifsS4R/1VQKE/+LZSUA7puynZg3ILLVfy9hZk=; b=CdDAyQ43Jv36qsn9EkuUTZw8nt/+mOBKFoXfvdiENDFswTz54lmUElxhgNjniKxvLI izkIqTz62/+BsaxfKUgZ8S2RMG637jnDm+u0E1aGEUIzsEbWwsDV18EKNobslN2UlmYW WhC8g2REeIsonwoMKiOWl5u0CwVw1KGMvWwvlr5qjl4PZWOYWYsDg5p9F3UN6uGx7U/X y0XyKjPvcy9QpHnBDaHHpgbyRB/umgRbu9qBjoNr1nlR2d6FHD+lGiNEfvnrob7yl41T Rb+d5GPnNkrUNEfbqJzu6sSRExc4iKzcT+7U+xgq+doooMPjYjmc+eE6U7r6YPGlvf7O nVDg== In-Reply-To: <20191106092039.GT4131@hirez.programming.kicks-ass.net> Content-Language: en-US List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: "linux-snps-arc" Errors-To: linux-snps-arc-bounces+gla-linux-snps-arc=m.gmane.org@lists.infradead.org To: Peter Zijlstra Cc: Juri Lelli , linux-sh@vger.kernel.org, Catalin Marinas , Ben Segall , Guo Ren , Pavel Machek , Vincent Guittot , Paul Burton , Michael Ellerman , Geert Uytterhoeven , Mel Gorman , Jiri Slaby , Matt Turner , uclinux-h8-devel@lists.sourceforge.jp, Len Brown , linux-pm@vger.kernel.org, Heiko Carstens , linux-um@lists.infradead.org, Thomas Gleixner , Dietmar Eggemann , Richard Henderson , Greg Kroah-Hartman , "Rafael J. Wysocki" , linux-kernel@vger.kernel.org, Ralf Baechle Hi Peter, On 11/6/19 9:20 AM, Peter Zijlstra wrote: > On Wed, Nov 06, 2019 at 03:04:51AM +0000, Dmitry Safonov wrote: >> Add log level argument to show_stack(). >> Done in three stages: >> 1. Introducing show_stack_loglvl() for every architecture >> 2. Migrating old users with an explicit log level >> 3. Renaming show_stack_loglvl() into show_stack() >> >> Justification: >> o It's a design mistake to move a business-logic decision >> into platform realization detail. >> o I have currently two patches sets that would benefit from this work: >> Removing console_loglevel jumps in sysrq driver [1] >> Hung task warning before panic [2] - suggested by Tetsuo (but he >> probably didn't realise what it would involve). >> o While doing (1), (2) the backtraces were adjusted to headers >> and other messages for each situation - so there won't be a situation >> when the backtrace is printed, but the headers are missing because >> they have lesser log level (or the reverse). >> o As the result in (2) plays with console_loglevel for kdb are removed. > > I really don't understand that word salad. Why are you doing this? > Sorry, I should have tried to describe better. I'm trying to remove external users of console_loglevel by following reasons: - changing console_loglevel on SMP means that unwanted messages from other CPUs will appear (that have lower log level) - on UMP unwanted messages may appear if the code is preempted while it hasn't set the console_loglevel back to old - rising console_loglevel to print wanted message(s) may not work at all if printk() has being delayed and the console_loglevel is already set back to old value Sysrq driver changes console_loglevel because it needs to print message with a specific log level (the code said userspace relies on this). Kdb changes console_loglevel to print backtrace as the log level depends on architecture realisation. I also have patches in wip those needs to print backtrace with specific loglevel (higher when it's critical, lower when it's notice and shouldn't go to serial console). Besides on local tests I see hits those have headers (messages like "Backtrace: ") without an actual backtrace and the reverse - a backtrace without a reason for it. It's quite annoying and worth addressing by syncing headers log levels to backtraces. Thanks, Dmitry