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: Mon, 11 Nov 2019 19:47:25 +0000 Message-ID: <13e72b62-c842-8ed5-5b41-bc1692b28f53@arista.com> 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> 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=burf8SuQf/K0cviUiNaPgjO96BrO+miuKlA0Hz+3ZNQ=; b=vD5ibmp53LTidT 8gj5d2AJh/qNBzepm2k7C+H29eKIIch3ctWN6QprV0TKnZ9x+Fm/l9P6tb6NRAUrXPp+90LODQ4Ak rBTGqYA6tj7AjcBfGliVnHo4FP5Avn1Kxh8T58ynazUVK/AQWwoiL+a1ldsUHwpc/Lqpfk1hDI0J/ AJfRVhvi6AhM5IGjOfuvn1wWj1Ob0vM7wNUtDWuw3p4C4uJ9RCnhxvCozVFDLXN/y6p/JDUIFBdI3 VGuhk8A1aeBkp3nCfZFOCQBkbDdQQlqfg84CD9i5G75DVvG6Vx2Nf1MpEuIGE6dh8Sm0LSPn0McKp KHxzbo+1DuHXWdS6ofTg==; 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== In-Reply-To: <20191111012336.GA85185@google.com> 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: Sergey Senozhatsky , Petr Mladek 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, 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