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 Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 86A1DC77B61 for ; Thu, 13 Apr 2023 12:10:48 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229522AbjDMMKr (ORCPT ); Thu, 13 Apr 2023 08:10:47 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:34896 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229749AbjDMMKq (ORCPT ); Thu, 13 Apr 2023 08:10:46 -0400 Received: from smtp-out1.suse.de (smtp-out1.suse.de [IPv6:2001:67c:2178:6::1c]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 478E54EFD; Thu, 13 Apr 2023 05:10:45 -0700 (PDT) Received: from relay2.suse.de (relay2.suse.de [149.44.160.134]) by smtp-out1.suse.de (Postfix) with ESMTP id E697321870; Thu, 13 Apr 2023 12:10:43 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1; t=1681387843; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=bVHo1AXvNk+0J2p7GN3q6H/IIXVoMsR7G7c5lAwQvBU=; b=HaJy1zlPz/tNt7qW8EQurlRkj6zMsHLxlojZiP//cBWXlSwvxA/9Yt9fVGAlgmgwdpyZlM f59uzjPxfPkSp45d7VkT76gPiKn6IuNhKxzknWGURkgawwA7BYZOB141pPpJ0SRI6we18N xM24LBgMca98+CFZA9PXAYQb0c2rYbE= Received: from suse.cz (pmladek.udp.ovpn2.prg.suse.de [10.100.201.202]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by relay2.suse.de (Postfix) with ESMTPS id 508042C143; Thu, 13 Apr 2023 12:10:43 +0000 (UTC) Date: Thu, 13 Apr 2023 14:10:39 +0200 From: Petr Mladek To: John Ogness Cc: Sergey Senozhatsky , Steven Rostedt , Thomas Gleixner , linux-kernel@vger.kernel.org, "Paul E. McKenney" , Frederic Weisbecker , Neeraj Upadhyay , Josh Triplett , Mathieu Desnoyers , Lai Jiangshan , Joel Fernandes , rcu@vger.kernel.org Subject: Re: [PATCH printk v1 17/18] rcu: Add atomic write enforcement for rcu stalls Message-ID: References: <20230302195618.156940-1-john.ogness@linutronix.de> <20230302195618.156940-18-john.ogness@linutronix.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20230302195618.156940-18-john.ogness@linutronix.de> Precedence: bulk List-ID: X-Mailing-List: rcu@vger.kernel.org On Thu 2023-03-02 21:02:17, John Ogness wrote: > Invoke the atomic write enforcement functions for rcu stalls to > ensure that the information gets out to the consoles. "ensure" is too strong. It is still just the best effort. It might fail when the current console user does not pass the lock. I would say that it will increase the chance to see the messages on NOBKL consoles by printing the messages directly instead of waiting for the printk thread. > It is important to note that if there are any legacy consoles > registered, they will be attempting to directly print from the > printk-caller context, which may jeopardize the reliability of the > atomic consoles. Optimally there should be no legacy consoles > registered. The above paragraph is a bit vague. It is not clear how exactly the legacy consoles affect the reliability, Does it mean that they might cause a deadlock because they are not atomic? But there is nothing specific about rcu stalls and priority of NOBKL consoles. This is a generic problem with legacy consoles. > --- a/kernel/rcu/tree_stall.h > +++ b/kernel/rcu/tree_stall.h > @@ -566,6 +568,8 @@ static void print_other_cpu_stall(unsigned long gp_seq, unsigned long gps) > if (rcu_stall_is_suppressed()) > return; > > + prev_prio = cons_atomic_enter(CONS_PRIO_EMERGENCY); Thinking loudly: This would set the EMERGENCY priority on this CPU. But the following function: + rcu_dump_cpu_stacks() + dump_cpu_task() + trigger_single_cpu_backtrace() might send IPI and the backtrace will be printed from another CPU. As a result that backtraces won't be printed with EMERGENCY priority. One solution would be to have also global EMERGENCY priority. Another possibility would be to use EMERGENCY priority also in nmi_cpu_backtrace() which is the callback called by the IPI. I would probably go for the global flag. printk() called in EMERGENCY priority has to flush also messages added by other CPUs. So that messages added by other CPUs are printed "directly" anyway. Also setting the EMERGENCY priority in nmi_cpu_backtrace() is an ad-hoc solution. The backtrace is usually called as part of another global emergency report. > + > /* > * OK, time to rat on our buddy... > * See Documentation/RCU/stallwarn.rst for info on how to debug Best Regards, Petr