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 36F68C432C3 for ; Wed, 13 Nov 2019 16:57:33 +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 CEE36206D6 for ; Wed, 13 Nov 2019 16:57:31 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="ToUn4uSl"; dkim=fail reason="signature verification failed" (2048-bit key) header.d=arista.com header.i=@arista.com header.b="kRXw4Avo" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org CEE36206D6 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=7n6gmXMBXY4YuCEWdXZZLAhZnJhQ9DnDLrubJcdQ3DQ=; b=ToUn4uSlIHtsUK Z10LwB+iVF3H5DpXpmYj8rsN1+1PnOOHuFsJ23TmCJYzeKM5rIwVLVubxAdT6SLVj26AxFZCR8TtH INtkea1eR2V6Om15j7ozLu4603Ub+bzaB/RkYeNWIXkaO5DU9FP6DNLQ8Xdqq7SVJ4KxZkJsN7nj0 vBLI9WAYCIWGz46jmsh4ENgAVQfB2U5H6fgRzIAwvi1kAcGepGWHsaUliZ0xv/Od7dogBylEz68fn vdXkwBW7+uxG63yVdHuAMn9hXWjMFMjhJh8taj3MjuEjjVcqUB6+RnxsZH2R6OSqWkyAuDDkyZpqD BwGRJibrSMmf1k9JDwcg==; 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 1iUvhx-0001tq-W6; Wed, 13 Nov 2019 16:41:30 +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 1iUvhu-0001sd-Du for linux-riscv@lists.infradead.org; Wed, 13 Nov 2019 16:41:28 +0000 Received: by mail-pg1-x542.google.com with SMTP id z188so1726673pgb.1 for ; Wed, 13 Nov 2019 08:41:26 -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=bpYMERXodNN3/IUKFqoV3bu09Kfnjp4MDDbBxGqTaak=; b=kRXw4AvoWBw7ukkZ2SwH4DcHmhkOyvtHzm9A9tembEe4SHnL/Wkxs4OG+Y78DFYLKj WUQkQ3xkRC7KpV6HsQsVQ8Y83U6DSV4bjqqA4yz8eiAzM5MouyPOfpTV04Q+Swaq6dzO iwJ3irSL+AWM6APV8kLc/aiqJnine4lrlZLBQET4Kth1bx1KYWl6QngPsxySaS0LA2u8 4l3EYQWDxhDPyJMBUmdjQ4AlBq5rQRf2tmZq6s9bjkx4QpbhYyBqV94RH9xa8/CrCe8j rdAqy2276oEWDDekf+JPcbvdolRg+K/VuqSY8KHpC1K4x4t7plUDL/CedXLaIDpvWCOd tkDg== 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=bpYMERXodNN3/IUKFqoV3bu09Kfnjp4MDDbBxGqTaak=; b=o2BGhhf2Y2WVJwjLEowpXT+y0wkBacM5uaSgHAOe94u1yduAcri/TKzLXWjMjp6nhH /l4nWBqV+pVdIrRP+QODRQ+cUEng8y665HK+dV9iTJ9Wn8xONaETQLEueQnP1YDWp4yh AZBbfvC+bVNurhzTCe+vP+f2gj1r0NgSVqoolGxNG0kqwmit7l+sR3ZyKaZcpPBQEZ9j 6Ump2+GvYWTCbmKPiYmg0hncE1qs7Bzq4t9EesfAAmnourg8csvwz7TJQ9zc/djplmuI KIDYv5M7VHkDyPjmaDoqpkfvCRY+aZX4FFro7c7mDq6XhI007PRl56ipRExUIRniAYal wvLQ== X-Gm-Message-State: APjAAAWwR4uxmwqqrdPCLQc+OWg8EHNczdAthcL7PfRjta/niicFozRm OtFPC6U5kE+xY83lzNZEJa5Sfw== X-Google-Smtp-Source: APXvYqxGmsqG/IrGmwAGiFxwnMwQ7BOsmJMkITh9aVjyUYUrJF/k6QpL2RmzoyB1mQQoM3FoiW7TOw== X-Received: by 2002:a63:c55:: with SMTP id 21mr4829337pgm.282.1573663285447; Wed, 13 Nov 2019 08:41:25 -0800 (PST) Received: from [10.83.36.153] ([217.173.96.166]) by smtp.gmail.com with ESMTPSA id h4sm2954304pjs.24.2019.11.13.08.41.04 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 13 Nov 2019 08:41:24 -0800 (PST) Subject: Re: [PATCH 00/50] Add log level to show_stack() To: Sergey Senozhatsky References: <20191108103719.GB175344@google.com> <20191108130447.h3wfgo4efjkto56f@pathway.suse.cz> <20191111012336.GA85185@google.com> <20191111091207.u3lrd6cmumnx4czr@pathway.suse.cz> <20191112044447.GA121272@google.com> <20191112045704.GA138013@google.com> <20191112083509.gmgjpkjffsfaw5lm@pathway.suse.cz> <20191112101229.GA201294@google.com> <20191113012337.GA70781@google.com> <25ff45f0-6420-f660-55a8-637f11ab5ab4@arista.com> <20191113063334.GA147997@google.com> From: Dmitry Safonov Message-ID: <578d041a-3ce5-28bb-9fcc-cf90fe82b036@arista.com> Date: Wed, 13 Nov 2019 16:40:57 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.2.2 MIME-Version: 1.0 In-Reply-To: <20191113063334.GA147997@google.com> Content-Language: en-US X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20191113_084126_478292_A7EDE53C X-CRM114-Status: GOOD ( 13.24 ) 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 , Peter Zijlstra , "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 Sergey, On 11/13/19 6:33 AM, Sergey Senozhatsky wrote: [..] > Well, here we go. There is a number of generally useful functions that > print nice data and where people might want to have better loglevel control > (for debugging purposes). show_stack() is just one of them. Patching all > those functions, which you have mentioned above, is hardly a fun task to do. > Hence the printk() per-CPU per-context loglevel proposition. The code there > is not clever or complicated and is meant for debugging purposes only, but > with just 3 lines of code one can do some stuff: > > /* @BTW you can't do this with "%s" KERN_FOO ;P */ > + printk_emergency_enter(LOGLEVEL_SCHED); > + debug_show_all_locks(); > + printk_emergency_exit(); Not that I want to critic your proposal more, but just to clarify what I've meant by "cleaver and complicated": I don't think semantically there is any difference between: printk_emergency_enter(LOGLEVEL_SCHED); printk(); printk_emergency_exit(); vs printk("%s ...", KERN_SHED, ...); I was speaking about complexity not about usage, but about realization inside printk_emergency_enter(): there will be some business logic that will do "it's NMI? Use loglevel given. it's KERN_ALERT? Don't downgrade the loglevel..." and other smart details those are really logic which one have to think about and later maintain. There will be also minor issues like people inserting print with one log level and seeing it in dmesg with another, but I presume those printk_enter() and printk_exit() will cover little amount of code without much nesting [as long as it's not getting overused]. And also it can be documented and people will learn about another feature of printk(). And this year I've seen the presentation "Why printk() is so complicated?" and I presumed that the approach is to keep things as simple as possible. In conclusion: I see that your proposal also solves the problem [except preemption and some pr_debug() that shouldn't be printed]. And I think your approach is better in the sense of short-term (we won't have any missed %s KERN_ in linux-next), but in a long-term it adds some amount of business logic to printk and another feature. Just in case: again, I don't mind, it's up to you, maintainers of printk. It's also not very fun for me to create those patches. But they fix console_loglevel issues (I hope we could un-export it in the end) and also I need it for my other patches those will produce warnings with debug loglevel when configured through sysctl. 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 5BF97C432C3 for ; Wed, 13 Nov 2019 20:10:46 +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 BA41E206EE for ; Wed, 13 Nov 2019 20:10:46 +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="kRXw4Avo" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org BA41E206EE 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 lists.ozlabs.org (lists.ozlabs.org [IPv6:2401:3900:2:1::3]) by lists.ozlabs.org (Postfix) with ESMTP id 47Cwhz190qzF62p for ; Thu, 14 Nov 2019 07:10:43 +1100 (AEDT) Authentication-Results: lists.ozlabs.org; spf=pass (sender SPF authorized) smtp.mailfrom=arista.com (client-ip=2607:f8b0:4864:20::442; helo=mail-pf1-x442.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="kRXw4Avo"; dkim-atps=neutral Received: from mail-pf1-x442.google.com (mail-pf1-x442.google.com [IPv6:2607:f8b0:4864:20::442]) (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 47Cr3Y6mhfzF6DN for ; Thu, 14 Nov 2019 03:41:29 +1100 (AEDT) Received: by mail-pf1-x442.google.com with SMTP id r4so2019064pfl.7 for ; Wed, 13 Nov 2019 08:41:29 -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=bpYMERXodNN3/IUKFqoV3bu09Kfnjp4MDDbBxGqTaak=; b=kRXw4AvoWBw7ukkZ2SwH4DcHmhkOyvtHzm9A9tembEe4SHnL/Wkxs4OG+Y78DFYLKj WUQkQ3xkRC7KpV6HsQsVQ8Y83U6DSV4bjqqA4yz8eiAzM5MouyPOfpTV04Q+Swaq6dzO iwJ3irSL+AWM6APV8kLc/aiqJnine4lrlZLBQET4Kth1bx1KYWl6QngPsxySaS0LA2u8 4l3EYQWDxhDPyJMBUmdjQ4AlBq5rQRf2tmZq6s9bjkx4QpbhYyBqV94RH9xa8/CrCe8j rdAqy2276oEWDDekf+JPcbvdolRg+K/VuqSY8KHpC1K4x4t7plUDL/CedXLaIDpvWCOd tkDg== 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=bpYMERXodNN3/IUKFqoV3bu09Kfnjp4MDDbBxGqTaak=; b=e3VFjJW9PR4iE5JHnE871xorLCP+ggxBvKgikRVal1P9bUrSm8IjtGKjL0s00Sh+HV GfKqqpjCt7c0NnqFaZRogvjFmENhN9yVI/H22Vi6uqI8FmMESTHqveNdhq/Yp+040UCw jiZe/ve88zMVfTuixT4saJHCQ9yY0OC4PAz802hdacw7vtJ4F+WG2HPjBCivDV0uq5o6 n5lmEVYD4ROwtb3CzFRo1qbitjS0XGdBWJhbdRPnGiDsqzSeEWiRM9qyHZaECim02mjo FbYCAk4Y6ZxPtoVKi+bEzgLHFj2AXa9fZ7rykDvPACtHLmllphjXjmlFAC/QgHrYK2El uGPQ== X-Gm-Message-State: APjAAAU7xyBqDWnPyZLEx7ViWMml91NkEnYWsZ70NN2Dw6KA6ZN0VmHZ VGeLWNodIOyk7MVrDPBsU3oQoQ== X-Google-Smtp-Source: APXvYqxGmsqG/IrGmwAGiFxwnMwQ7BOsmJMkITh9aVjyUYUrJF/k6QpL2RmzoyB1mQQoM3FoiW7TOw== X-Received: by 2002:a63:c55:: with SMTP id 21mr4829337pgm.282.1573663285447; Wed, 13 Nov 2019 08:41:25 -0800 (PST) Received: from [10.83.36.153] ([217.173.96.166]) by smtp.gmail.com with ESMTPSA id h4sm2954304pjs.24.2019.11.13.08.41.04 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 13 Nov 2019 08:41:24 -0800 (PST) Subject: Re: [PATCH 00/50] Add log level to show_stack() To: Sergey Senozhatsky References: <20191108103719.GB175344@google.com> <20191108130447.h3wfgo4efjkto56f@pathway.suse.cz> <20191111012336.GA85185@google.com> <20191111091207.u3lrd6cmumnx4czr@pathway.suse.cz> <20191112044447.GA121272@google.com> <20191112045704.GA138013@google.com> <20191112083509.gmgjpkjffsfaw5lm@pathway.suse.cz> <20191112101229.GA201294@google.com> <20191113012337.GA70781@google.com> <25ff45f0-6420-f660-55a8-637f11ab5ab4@arista.com> <20191113063334.GA147997@google.com> From: Dmitry Safonov Message-ID: <578d041a-3ce5-28bb-9fcc-cf90fe82b036@arista.com> Date: Wed, 13 Nov 2019 16:40:57 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.2.2 MIME-Version: 1.0 In-Reply-To: <20191113063334.GA147997@google.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Thu, 14 Nov 2019 06:57:20 +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 , Peter Zijlstra , "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 Sergey, On 11/13/19 6:33 AM, Sergey Senozhatsky wrote: [..] > Well, here we go. There is a number of generally useful functions that > print nice data and where people might want to have better loglevel control > (for debugging purposes). show_stack() is just one of them. Patching all > those functions, which you have mentioned above, is hardly a fun task to do. > Hence the printk() per-CPU per-context loglevel proposition. The code there > is not clever or complicated and is meant for debugging purposes only, but > with just 3 lines of code one can do some stuff: > > /* @BTW you can't do this with "%s" KERN_FOO ;P */ > + printk_emergency_enter(LOGLEVEL_SCHED); > + debug_show_all_locks(); > + printk_emergency_exit(); Not that I want to critic your proposal more, but just to clarify what I've meant by "cleaver and complicated": I don't think semantically there is any difference between: printk_emergency_enter(LOGLEVEL_SCHED); printk(); printk_emergency_exit(); vs printk("%s ...", KERN_SHED, ...); I was speaking about complexity not about usage, but about realization inside printk_emergency_enter(): there will be some business logic that will do "it's NMI? Use loglevel given. it's KERN_ALERT? Don't downgrade the loglevel..." and other smart details those are really logic which one have to think about and later maintain. There will be also minor issues like people inserting print with one log level and seeing it in dmesg with another, but I presume those printk_enter() and printk_exit() will cover little amount of code without much nesting [as long as it's not getting overused]. And also it can be documented and people will learn about another feature of printk(). And this year I've seen the presentation "Why printk() is so complicated?" and I presumed that the approach is to keep things as simple as possible. In conclusion: I see that your proposal also solves the problem [except preemption and some pr_debug() that shouldn't be printed]. And I think your approach is better in the sense of short-term (we won't have any missed %s KERN_ in linux-next), but in a long-term it adds some amount of business logic to printk and another feature. Just in case: again, I don't mind, it's up to you, maintainers of printk. It's also not very fun for me to create those patches. But they fix console_loglevel issues (I hope we could un-export it in the end) and also I need it for my other patches those will produce warnings with debug loglevel when configured through sysctl. 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 31B86C43141 for ; Wed, 13 Nov 2019 16:58:37 +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 D7633206D5 for ; Wed, 13 Nov 2019 16:58:35 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="bGGSu2Uy"; dkim=fail reason="signature verification failed" (2048-bit key) header.d=arista.com header.i=@arista.com header.b="kRXw4Avo" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org D7633206D5 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=nHT1I6opo0i/U993tzxvoHLLAcJ+P73UJpxH0BEsc/U=; b=bGGSu2Uy6RO8na St0hn6Vy4E+wCgn6SW3J/AjqTUQ2mdf6uYZsU8LYkivuydz4qYUN/ZK5vG+5ZjmjAjINb7SeExDTL Lb/kbSs90yWSQ3C9BY0bBuRw9yISTM3naNd5Q1+a/cpm4Wwr08k5NhNHGj8tsybRlE69xgl7df/si yS2HLKmnowvnAM/e45C/GrW7kClbkAhdunStCbeTxOMQSjfnIE7l6K5oynAA2XAEhGs9r5HZ5rWRC pT6Uts96pRjnXFyTfdmsdN6uY+47Ws3huUZHR/GyND9FDxHZumg31ppGyIleGb2QpxZxPu+ta33Tt 4tKU2DJndtgU+lR3MUuQ==; 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 1iUvhz-0001vf-Vy; Wed, 13 Nov 2019 16:41:31 +0000 Received: from mail-pf1-x442.google.com ([2607:f8b0:4864:20::442]) by bombadil.infradead.org with esmtps (Exim 4.92.3 #3 (Red Hat Linux)) id 1iUvhu-0001sc-Da for linux-snps-arc@lists.infradead.org; Wed, 13 Nov 2019 16:41:30 +0000 Received: by mail-pf1-x442.google.com with SMTP id c184so2035404pfb.0 for ; Wed, 13 Nov 2019 08:41:26 -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=bpYMERXodNN3/IUKFqoV3bu09Kfnjp4MDDbBxGqTaak=; b=kRXw4AvoWBw7ukkZ2SwH4DcHmhkOyvtHzm9A9tembEe4SHnL/Wkxs4OG+Y78DFYLKj WUQkQ3xkRC7KpV6HsQsVQ8Y83U6DSV4bjqqA4yz8eiAzM5MouyPOfpTV04Q+Swaq6dzO iwJ3irSL+AWM6APV8kLc/aiqJnine4lrlZLBQET4Kth1bx1KYWl6QngPsxySaS0LA2u8 4l3EYQWDxhDPyJMBUmdjQ4AlBq5rQRf2tmZq6s9bjkx4QpbhYyBqV94RH9xa8/CrCe8j rdAqy2276oEWDDekf+JPcbvdolRg+K/VuqSY8KHpC1K4x4t7plUDL/CedXLaIDpvWCOd tkDg== 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=bpYMERXodNN3/IUKFqoV3bu09Kfnjp4MDDbBxGqTaak=; b=MrJN7rLV949tCdgcSpyYotYMwklcvTIbxv3celITH0Xx6taynNRiSVFsmSau47WBOJ 4aqnu7uVAErf4h1e71K+z7DTW2yg9MOUiyca+W+qPyXtjNdIpLaBIb+0bFASilRVgcLi 07e2QlK9dYs4p0Jp4h3iT62vczZY+DOsfkGx53NW2mniaLIUV5RNcF0T0B77DgXg8IPo K81fk/6LREx5aiGGoNQko/FGdVGWFLJtf4r9VQJimFtJ1/xKFdjMtxWYpzCn1kFO9ohO 3RNEq4sGj/k9CcRLCM/xrSZQcP8KtdovYxo6cCnCzT0xWaVn7QSyxFiOkTGposz5ZDj3 FCUw== X-Gm-Message-State: APjAAAWD20EWvB2Vt2fBgto+HcWREl0vNTt5Bm4QKkqzuO5iCu06sA5J aL7uLNbRuLJuJQcuMicpEkmkXQ== X-Google-Smtp-Source: APXvYqxGmsqG/IrGmwAGiFxwnMwQ7BOsmJMkITh9aVjyUYUrJF/k6QpL2RmzoyB1mQQoM3FoiW7TOw== X-Received: by 2002:a63:c55:: with SMTP id 21mr4829337pgm.282.1573663285447; Wed, 13 Nov 2019 08:41:25 -0800 (PST) Received: from [10.83.36.153] ([217.173.96.166]) by smtp.gmail.com with ESMTPSA id h4sm2954304pjs.24.2019.11.13.08.41.04 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 13 Nov 2019 08:41:24 -0800 (PST) Subject: Re: [PATCH 00/50] Add log level to show_stack() To: Sergey Senozhatsky References: <20191108103719.GB175344@google.com> <20191108130447.h3wfgo4efjkto56f@pathway.suse.cz> <20191111012336.GA85185@google.com> <20191111091207.u3lrd6cmumnx4czr@pathway.suse.cz> <20191112044447.GA121272@google.com> <20191112045704.GA138013@google.com> <20191112083509.gmgjpkjffsfaw5lm@pathway.suse.cz> <20191112101229.GA201294@google.com> <20191113012337.GA70781@google.com> <25ff45f0-6420-f660-55a8-637f11ab5ab4@arista.com> <20191113063334.GA147997@google.com> From: Dmitry Safonov Message-ID: <578d041a-3ce5-28bb-9fcc-cf90fe82b036@arista.com> Date: Wed, 13 Nov 2019 16:40:57 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.2.2 MIME-Version: 1.0 In-Reply-To: <20191113063334.GA147997@google.com> Content-Language: en-US X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20191113_084126_476255_A7C5444A X-CRM114-Status: GOOD ( 13.24 ) 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 , Peter Zijlstra , "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 Sergey, On 11/13/19 6:33 AM, Sergey Senozhatsky wrote: [..] > Well, here we go. There is a number of generally useful functions that > print nice data and where people might want to have better loglevel control > (for debugging purposes). show_stack() is just one of them. Patching all > those functions, which you have mentioned above, is hardly a fun task to do. > Hence the printk() per-CPU per-context loglevel proposition. The code there > is not clever or complicated and is meant for debugging purposes only, but > with just 3 lines of code one can do some stuff: > > /* @BTW you can't do this with "%s" KERN_FOO ;P */ > + printk_emergency_enter(LOGLEVEL_SCHED); > + debug_show_all_locks(); > + printk_emergency_exit(); Not that I want to critic your proposal more, but just to clarify what I've meant by "cleaver and complicated": I don't think semantically there is any difference between: printk_emergency_enter(LOGLEVEL_SCHED); printk(); printk_emergency_exit(); vs printk("%s ...", KERN_SHED, ...); I was speaking about complexity not about usage, but about realization inside printk_emergency_enter(): there will be some business logic that will do "it's NMI? Use loglevel given. it's KERN_ALERT? Don't downgrade the loglevel..." and other smart details those are really logic which one have to think about and later maintain. There will be also minor issues like people inserting print with one log level and seeing it in dmesg with another, but I presume those printk_enter() and printk_exit() will cover little amount of code without much nesting [as long as it's not getting overused]. And also it can be documented and people will learn about another feature of printk(). And this year I've seen the presentation "Why printk() is so complicated?" and I presumed that the approach is to keep things as simple as possible. In conclusion: I see that your proposal also solves the problem [except preemption and some pr_debug() that shouldn't be printed]. And I think your approach is better in the sense of short-term (we won't have any missed %s KERN_ in linux-next), but in a long-term it adds some amount of business logic to printk and another feature. Just in case: again, I don't mind, it's up to you, maintainers of printk. It's also not very fun for me to create those patches. But they fix console_loglevel issues (I hope we could un-export it in the end) and also I need it for my other patches those will produce warnings with debug loglevel when configured through sysctl. 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, 13 Nov 2019 16:40:57 +0000 Subject: [OpenRISC] [PATCH 00/50] Add log level to show_stack() In-Reply-To: <20191113063334.GA147997@google.com> References: <20191108103719.GB175344@google.com> <20191108130447.h3wfgo4efjkto56f@pathway.suse.cz> <20191111012336.GA85185@google.com> <20191111091207.u3lrd6cmumnx4czr@pathway.suse.cz> <20191112044447.GA121272@google.com> <20191112045704.GA138013@google.com> <20191112083509.gmgjpkjffsfaw5lm@pathway.suse.cz> <20191112101229.GA201294@google.com> <20191113012337.GA70781@google.com> <25ff45f0-6420-f660-55a8-637f11ab5ab4@arista.com> <20191113063334.GA147997@google.com> Message-ID: <578d041a-3ce5-28bb-9fcc-cf90fe82b036@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 Sergey, On 11/13/19 6:33 AM, Sergey Senozhatsky wrote: [..] > Well, here we go. There is a number of generally useful functions that > print nice data and where people might want to have better loglevel control > (for debugging purposes). show_stack() is just one of them. Patching all > those functions, which you have mentioned above, is hardly a fun task to do. > Hence the printk() per-CPU per-context loglevel proposition. The code there > is not clever or complicated and is meant for debugging purposes only, but > with just 3 lines of code one can do some stuff: > > /* @BTW you can't do this with "%s" KERN_FOO ;P */ > + printk_emergency_enter(LOGLEVEL_SCHED); > + debug_show_all_locks(); > + printk_emergency_exit(); Not that I want to critic your proposal more, but just to clarify what I've meant by "cleaver and complicated": I don't think semantically there is any difference between: printk_emergency_enter(LOGLEVEL_SCHED); printk(); printk_emergency_exit(); vs printk("%s ...", KERN_SHED, ...); I was speaking about complexity not about usage, but about realization inside printk_emergency_enter(): there will be some business logic that will do "it's NMI? Use loglevel given. it's KERN_ALERT? Don't downgrade the loglevel..." and other smart details those are really logic which one have to think about and later maintain. There will be also minor issues like people inserting print with one log level and seeing it in dmesg with another, but I presume those printk_enter() and printk_exit() will cover little amount of code without much nesting [as long as it's not getting overused]. And also it can be documented and people will learn about another feature of printk(). And this year I've seen the presentation "Why printk() is so complicated?" and I presumed that the approach is to keep things as simple as possible. In conclusion: I see that your proposal also solves the problem [except preemption and some pr_debug() that shouldn't be printed]. And I think your approach is better in the sense of short-term (we won't have any missed %s KERN_ in linux-next), but in a long-term it adds some amount of business logic to printk and another feature. Just in case: again, I don't mind, it's up to you, maintainers of printk. It's also not very fun for me to create those patches. But they fix console_loglevel issues (I hope we could un-export it in the end) and also I need it for my other patches those will produce warnings with debug loglevel when configured through sysctl. 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: <20191108103719.GB175344@google.com> <20191108130447.h3wfgo4efjkto56f@pathway.suse.cz> <20191111012336.GA85185@google.com> <20191111091207.u3lrd6cmumnx4czr@pathway.suse.cz> <20191112044447.GA121272@google.com> <20191112045704.GA138013@google.com> <20191112083509.gmgjpkjffsfaw5lm@pathway.suse.cz> <20191112101229.GA201294@google.com> <20191113012337.GA70781@google.com> <25ff45f0-6420-f660-55a8-637f11ab5ab4@arista.com> <20191113063334.GA147997@google.com> From: Dmitry Safonov Message-ID: <578d041a-3ce5-28bb-9fcc-cf90fe82b036@arista.com> Date: Wed, 13 Nov 2019 16:40:57 +0000 MIME-Version: 1.0 In-Reply-To: <20191113063334.GA147997@google.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit To: Sergey Senozhatsky Cc: Petr Mladek , Steven Rostedt , linux-kernel@vger.kernel.org, Dmitry Safonov <0x7f454c46@gmail.com>, Andrew Morton , Greg Kroah-Hartman , Ingo Molnar , Jiri Slaby , Sergey Senozhatsky , 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 , Peter Zijlstra , 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 Sergey, On 11/13/19 6:33 AM, Sergey Senozhatsky wrote: [..] > Well, here we go. There is a number of generally useful functions that > print nice data and where people might want to have better loglevel control > (for debugging purposes). show_stack() is just one of them. Patching all > those functions, which you have mentioned above, is hardly a fun task to do. > Hence the printk() per-CPU per-context loglevel proposition. The code there > is not clever or complicated and is meant for debugging purposes only, but > with just 3 lines of code one can do some stuff: > > /* @BTW you can't do this with "%s" KERN_FOO ;P */ > + printk_emergency_enter(LOGLEVEL_SCHED); > + debug_show_all_locks(); > + printk_emergency_exit(); Not that I want to critic your proposal more, but just to clarify what I've meant by "cleaver and complicated": I don't think semantically there is any difference between: printk_emergency_enter(LOGLEVEL_SCHED); printk(); printk_emergency_exit(); vs printk("%s ...", KERN_SHED, ...); I was speaking about complexity not about usage, but about realization inside printk_emergency_enter(): there will be some business logic that will do "it's NMI? Use loglevel given. it's KERN_ALERT? Don't downgrade the loglevel..." and other smart details those are really logic which one have to think about and later maintain. There will be also minor issues like people inserting print with one log level and seeing it in dmesg with another, but I presume those printk_enter() and printk_exit() will cover little amount of code without much nesting [as long as it's not getting overused]. And also it can be documented and people will learn about another feature of printk(). And this year I've seen the presentation "Why printk() is so complicated?" and I presumed that the approach is to keep things as simple as possible. In conclusion: I see that your proposal also solves the problem [except preemption and some pr_debug() that shouldn't be printed]. And I think your approach is better in the sense of short-term (we won't have any missed %s KERN_ in linux-next), but in a long-term it adds some amount of business logic to printk and another feature. Just in case: again, I don't mind, it's up to you, maintainers of printk. It's also not very fun for me to create those patches. But they fix console_loglevel issues (I hope we could un-export it in the end) and also I need it for my other patches those will produce warnings with debug loglevel when configured through sysctl. 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, 13 Nov 2019 16:40:57 +0000 Message-ID: <578d041a-3ce5-28bb-9fcc-cf90fe82b036@arista.com> References: <20191108103719.GB175344@google.com> <20191108130447.h3wfgo4efjkto56f@pathway.suse.cz> <20191111012336.GA85185@google.com> <20191111091207.u3lrd6cmumnx4czr@pathway.suse.cz> <20191112044447.GA121272@google.com> <20191112045704.GA138013@google.com> <20191112083509.gmgjpkjffsfaw5lm@pathway.suse.cz> <20191112101229.GA201294@google.com> <20191113012337.GA70781@google.com> <25ff45f0-6420-f660-55a8-637f11ab5ab4@arista.com> <20191113063334.GA147997@google.com> 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=7n6gmXMBXY4YuCEWdXZZLAhZnJhQ9DnDLrubJcdQ3DQ=; b=ToUn4uSlIHtsUK Z10LwB+iVF3H5DpXpmYj8rsN1+1PnOOHuFsJ23TmCJYzeKM5rIwVLVubxAdT6SLVj26AxFZCR8TtH INtkea1eR2V6Om15j7ozLu4603Ub+bzaB/RkYeNWIXkaO5DU9FP6DNLQ8Xdqq7SVJ4KxZkJsN7nj0 vBLI9WAYCIWGz46jmsh4ENgAVQfB2U5H6fgRzIAwvi1kAcGepGWHsaUliZ0xv/Od7dogBylEz68fn vdXkwBW7+uxG63yVdHuAMn9hXWjMFMjhJh8taj3MjuEjjVcqUB6+RnxsZH2R6OSqWkyAuDDkyZpqD BwGRJibrSMmf1k9JDwcg==; 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=bpYMERXodNN3/IUKFqoV3bu09Kfnjp4MDDbBxGqTaak=; b=kRXw4AvoWBw7ukkZ2SwH4DcHmhkOyvtHzm9A9tembEe4SHnL/Wkxs4OG+Y78DFYLKj WUQkQ3xkRC7KpV6HsQsVQ8Y83U6DSV4bjqqA4yz8eiAzM5MouyPOfpTV04Q+Swaq6dzO iwJ3irSL+AWM6APV8kLc/aiqJnine4lrlZLBQET4Kth1bx1KYWl6QngPsxySaS0LA2u8 4l3EYQWDxhDPyJMBUmdjQ4AlBq5rQRf2tmZq6s9bjkx4QpbhYyBqV94RH9xa8/CrCe8j rdAqy2276oEWDDekf+JPcbvdolRg+K/VuqSY8KHpC1K4x4t7plUDL/CedXLaIDpvWCOd tkDg== In-Reply-To: <20191113063334.GA147997@google.com> Content-Language: en-US List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: "linux-riscv" Errors-To: linux-riscv-bounces+glpr-linux-riscv=m.gmane.org@lists.infradead.org To: Sergey Senozhatsky 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 Sergey, On 11/13/19 6:33 AM, Sergey Senozhatsky wrote: [..] > Well, here we go. There is a number of generally useful functions that > print nice data and where people might want to have better loglevel control > (for debugging purposes). show_stack() is just one of them. Patching all > those functions, which you have mentioned above, is hardly a fun task to do. > Hence the printk() per-CPU per-context loglevel proposition. The code there > is not clever or complicated and is meant for debugging purposes only, but > with just 3 lines of code one can do some stuff: > > /* @BTW you can't do this with "%s" KERN_FOO ;P */ > + printk_emergency_enter(LOGLEVEL_SCHED); > + debug_show_all_locks(); > + printk_emergency_exit(); Not that I want to critic your proposal more, but just to clarify what I've meant by "cleaver and complicated": I don't think semantically there is any difference between: printk_emergency_enter(LOGLEVEL_SCHED); printk(); printk_emergency_exit(); vs printk("%s ...", KERN_SHED, ...); I was speaking about complexity not about usage, but about realization inside printk_emergency_enter(): there will be some business logic that will do "it's NMI? Use loglevel given. it's KERN_ALERT? Don't downgrade the loglevel..." and other smart details those are really logic which one have to think about and later maintain. There will be also minor issues like people inserting print with one log level and seeing it in dmesg with another, but I presume those printk_enter() and printk_exit() will cover little amount of code without much nesting [as long as it's not getting overused]. And also it can be documented and people will learn about another feature of printk(). And this year I've seen the presentation "Why printk() is so complicated?" and I presumed that the approach is to keep things as simple as possible. In conclusion: I see that your proposal also solves the problem [except preemption and some pr_debug() that shouldn't be printed]. And I think your approach is better in the sense of short-term (we won't have any missed %s KERN_ in linux-next), but in a long-term it adds some amount of business logic to printk and another feature. Just in case: again, I don't mind, it's up to you, maintainers of printk. It's also not very fun for me to create those patches. But they fix console_loglevel issues (I hope we could un-export it in the end) and also I need it for my other patches those will produce warnings with debug loglevel when configured through sysctl. Thanks, Dmitry