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.1 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 9460EC43331 for ; Mon, 11 Nov 2019 21:13:24 +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 3AFB520818 for ; Mon, 11 Nov 2019 21:13:24 +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="cZIehrzG" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 3AFB520818 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 47BkB95FYxzF0X4 for ; Tue, 12 Nov 2019 08:13:21 +1100 (AEDT) Authentication-Results: lists.ozlabs.org; spf=pass (sender SPF authorized) smtp.mailfrom=arista.com (client-ip=2a00:1450:4864:20::342; helo=mail-wm1-x342.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="cZIehrzG"; dkim-atps=neutral Received: from mail-wm1-x342.google.com (mail-wm1-x342.google.com [IPv6:2a00:1450:4864:20::342]) (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 47BhHK41NdzF3MS for ; Tue, 12 Nov 2019 06:47:40 +1100 (AEDT) Received: by mail-wm1-x342.google.com with SMTP id u18so586069wmc.3 for ; Mon, 11 Nov 2019 11:47:40 -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=QOJc4N4PavQU2sAVS1vG4t8ohqXXXnqqV8/w5qQonB8=; b=cZIehrzGpUFezD2aa4zmv8OufN5OtO0USzsaArEEUTu0egX1JDp7fXq/MKdHB+YxUr j/kC7hgtECdh5x1noQBDdzd4zMsGonK7DNa4R/e8/R7qxcehDcLnLo5qSFE4wjuyW42o PQpFktb3ed0G2yVCt/fgkRLVHHWNH3ragHLlsd4kHSnraDACO77RcGzlulVu3SB7tcFm Ka75d1q24hYXLZJbDgNbGl6ynhrMJhmWegwmwjFp7I5D0Fg2d54s1iF9aPGxd1hnX+B8 gISwE6rYfN65iX3ZaYqQ/BYKUKfAwSvjgwPgiFEkk/eO1PVC0atmmvIxVoVwNPzimOsY R2mw== 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=QOJc4N4PavQU2sAVS1vG4t8ohqXXXnqqV8/w5qQonB8=; b=M/d12HKMuhfQAybp0jnVkMARUW86gNBao0uBWhxkLVCukcqFeAXXFKTCUCnHttNMfN Pp/GG9XqWa7MC+wIwyXjq8LILBl+W/aHhsMk4O7w1LCM3AOGgYR2T8BEuVL2JLMaljpW jErdrZGi2dyqQojDEYMZSEKFqlCzDnOeh9vx5GgSx371Yfk+4yj+RMt3FkyQ3KSf3H08 Pq4rw9v2LLrEDV9Q/8m1QJUrr3dp6ZTWWgH8kXM2o2D15Jw4wGjSoQPd3ZkoQc/J4Ey9 S7W9UIqvqbqJ7hkXdkZNBIUBdTWUQsPiw3flDdoo9/3NHvmGepvZTdMwktakOBmE+0ep EyMA== X-Gm-Message-State: APjAAAXcUzgfW0ctnhg2QbPskZUAtQ4I6NUJ37hBCLnyilxVIrsxywi5 Hb12F1v0je24w5Qso6xFGe2Xyg== X-Google-Smtp-Source: APXvYqwUswzQhu0DkD+M5khz/mFK8gHdabdOoahgxknZZUvPWQw4U7A4JmJR+GV6KsoYg/TOZHa6cQ== X-Received: by 2002:a1c:2342:: with SMTP id j63mr585268wmj.56.1573501654084; Mon, 11 Nov 2019 11:47:34 -0800 (PST) Received: from [10.83.36.153] ([217.173.96.166]) by smtp.gmail.com with ESMTPSA id f67sm723039wme.16.2019.11.11.11.47.30 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 11 Nov 2019 11:47:33 -0800 (PST) Subject: Re: [PATCH 00/50] Add log level to show_stack() To: Sergey Senozhatsky , Petr Mladek References: <20191106030542.868541-1-dima@arista.com> <20191106083538.z5nlpuf64cigxigh@pathway.suse.cz> <20191108103719.GB175344@google.com> <20191108130447.h3wfgo4efjkto56f@pathway.suse.cz> <20191111012336.GA85185@google.com> From: Dmitry Safonov Message-ID: <13e72b62-c842-8ed5-5b41-bc1692b28f53@arista.com> Date: Mon, 11 Nov 2019 19:47:25 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.2.0 MIME-Version: 1.0 In-Reply-To: <20191111012336.GA85185@google.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Tue, 12 Nov 2019 08:11:23 +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 , 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, Petr, On 11/11/19 1:23 AM, Sergey Senozhatsky wrote: > On (19/11/08 14:04), Petr Mladek wrote: > [..] >> I agree that it is complicated to pass the loglevel as >> a parameter. It would be better define the default >> log level for a given code section. It might be stored >> in task_struct for the normal context and in per-CPU >> variables for interrupt contexts. > > I do recall that we talked about per-CPU printk state bit which would > start/end "just print it" section. We probably can extend it to "just > log_store" type of functionality. Doesn't look like a very bad idea. > "This task/context is in trouble, whatever it printk()-s is important". I don't see how bits on task_struct or in per-cpu are easier than supplying a log level parameter down the stack. How would it work if sysrq_handle_crash() called by key-press? How would that interact with deferred printing? How would it make visible prints from current context, but not from something that preempted it? Furthermore, what problems are you trying to solve with this design? Only sysrq driver? Kdb? In my perspective it sounds too complicated and over-engineered for something that has two-three users. Also I've tried to point that I need to print backtrace sometimes with KERN_DEBUG loglevel to use it in production for early notices those needs to go only to log files and currently each architecture decides which log level it prefers. And what's so complicated about this patches set? I see only side of the testing, but the build-testing is covered with 0day bot and cost nothing and any visible regression may be found during -next period. While introducing those printk-sections may subtly break things. I mean, I definitely know less about printk() and its internals than you - so my points may be a no-sense. What I'm going to do - is to fix all build and reported issues, I'll send v2 this week and feel free to NAK it, I will forget about those patches and won't be offended. I don't see many people those are "hey, we'll benefit from this". And doing this patches set was neither quite fun (dirty business), nor something I can be later proud of (hey, I've introduced the log level parameter to printing functions!). Thanks, Dima