Received: by 2002:a05:6520:4d:b0:139:a872:a4c9 with SMTP id i13csp3475087lkm; Tue, 21 Sep 2021 17:03:35 -0700 (PDT) X-Google-Smtp-Source: ABdhPJySI1m6NJkDTvINn7dLNKlCM76vncA4JlmkBxWkJbxPU4bfL0SvQC2ghf/+2MM0C1ChUZZB X-Received: by 2002:a17:906:4f19:: with SMTP id t25mr31291203eju.440.1632269015196; Tue, 21 Sep 2021 17:03:35 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1632269015; cv=none; d=google.com; s=arc-20160816; b=vTGRq+EVWaxqdEOIpGP9MNev1uBxCrwVV4GFycLn9Hc1cvrgbD2wdY4Wm0KNG4UIEh WOWEedVBnDiSzvS48GRJrlwgN6lDW+lyrEbfCGEsl46dewF8nXu+moXvOuvY/TxOs3SD oZm46w8aEf2Al33UAbZKVBjwc0EYS/j6x8/HBT4BDdKqWrjnVe9OL8O2TUcdPGpeuk1d t5ta9UNHI6LyEdnNEBtBswNaKEAjRNAChMxy4UlUbzpxR7t9m3PAlNj72LVTwezrrM/K d3qGiTUn4kVYnC57YyKLjvAYClO6CpPxCXKKTHlT3yo1v145LKUUVoBHRm9zvilMis4Z LdSA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:mime-version:message-id:date:references :in-reply-to:subject:cc:to:dkim-signature:dkim-signature:from; bh=B/d9ecYh2L4gIWFi5kh23O8/tmeJ+Zy/cOZw1iVbWJ0=; b=nUlf/CGy7EA6pS6NqSq1FTng+Do3kvrXpomvb4yEniFW4jJmwnT+hOmIYK4wuysS1X lhRh/sBc1oSby+0o5D2i2dv3Fg6IiZFEewhBvsVvsk5Vho4cqkE3K0VREAMMxrSK62K0 vXgGSm4iKFw9PLcnjJcQXpHpyxauqV4U5/CMrBup4iGUkksvbknUvfvaR6Dyepj5gXxz srrvUBvE1wrfn0N+QvUt4hA55O6cthwuPeritWdtk2QjVBGYiXRTGbrJfiYrlWTR2kCw eUZlXzBCug7PM/5QoR+8g9EzJ6S9moeO4rft3O4bWjA4iEk+1T+hUPnqVJd+OjTDLxLv qfdg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linutronix.de header.s=2020 header.b=aoWeT3TA; dkim=neutral (no key) header.i=@linutronix.de; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=linutronix.de Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id n6si664085eda.103.2021.09.21.17.03.09; Tue, 21 Sep 2021 17:03:35 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@linutronix.de header.s=2020 header.b=aoWeT3TA; dkim=neutral (no key) header.i=@linutronix.de; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=linutronix.de Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S234852AbhIUVOW (ORCPT + 99 others); Tue, 21 Sep 2021 17:14:22 -0400 Received: from Galois.linutronix.de ([193.142.43.55]:51190 "EHLO galois.linutronix.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232386AbhIUVOV (ORCPT ); Tue, 21 Sep 2021 17:14:21 -0400 From: Thomas Gleixner DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linutronix.de; s=2020; t=1632258771; h=from:from:reply-to:subject:subject: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=B/d9ecYh2L4gIWFi5kh23O8/tmeJ+Zy/cOZw1iVbWJ0=; b=aoWeT3TAKrBIFSeky1ZLElvf7XtWUfLAzGXcrkiNVE+lzLHwt49Ll0ytAV2q8aPLgCLmhI qdBtJ3KoCjGNkY//0RlUBSXaGUBGohFQU3Iha3XJtzuCQ4d0qKRVuMiDMhpq7xN697cRFG mdX6yPlwppfpjOdcB2HHKO5XtS5tLrJZiQ5pcQA3xQ24QgpIhqQFtdsjTMKiTHUpmEiWRe SXbvvsm4QuK7Bxr5XCA2hSrEDCQK+STSKIASSH1XXzfVLyMPBWA94am2gt4URR0GApSkBP CLvAgPpxGyNm2bZP1+d2XFkUc+iVy+4JRW0jAj+f89oBvDkQOXuSDwOeV4Q8Vw== DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=linutronix.de; s=2020e; t=1632258771; h=from:from:reply-to:subject:subject: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=B/d9ecYh2L4gIWFi5kh23O8/tmeJ+Zy/cOZw1iVbWJ0=; b=3jjc+7PBcS4ow3JDn4taHqXHsmytqlFtKQZlG67nicGebcHU638avfYfsznAktpZ4wte6s t6czxYYgRKS6L4Dw== To: Valentin Schneider , linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org, rcu@vger.kernel.org, linux-rt-users@vger.kernel.org Cc: Catalin Marinas , Will Deacon , Ingo Molnar , Peter Zijlstra , Steven Rostedt , Daniel Bristot de Oliveira , Sebastian Andrzej Siewior , "Paul E. McKenney" , Frederic Weisbecker , Josh Triplett , Mathieu Desnoyers , Davidlohr Bueso , Lai Jiangshan , Joel Fernandes , Anshuman Khandual , Vincenzo Frascino , Steven Price , Ard Biesheuvel , Boqun Feng , Mike Galbraith Subject: rcu/tree: Protect rcu_rdp_is_offloaded() invocations on RT In-Reply-To: <874kae6n3g.ffs@tglx> References: <20210811201354.1976839-1-valentin.schneider@arm.com> <20210811201354.1976839-4-valentin.schneider@arm.com> <874kae6n3g.ffs@tglx> Date: Tue, 21 Sep 2021 23:12:50 +0200 Message-ID: <87pmt163al.ffs@tglx> MIME-Version: 1.0 Content-Type: text/plain Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Valentin reported warnings about suspicious RCU usage on RT kernels. Those happen when offloading of RCU callbacks is enabled: WARNING: suspicious RCU usage 5.13.0-rt1 #20 Not tainted ----------------------------- kernel/rcu/tree_plugin.h:69 Unsafe read of RCU_NOCB offloaded state! rcu_rdp_is_offloaded (kernel/rcu/tree_plugin.h:69 kernel/rcu/tree_plugin.h:58) rcu_core (kernel/rcu/tree.c:2332 kernel/rcu/tree.c:2398 kernel/rcu/tree.c:2777) rcu_cpu_kthread (./include/linux/bottom_half.h:32 kernel/rcu/tree.c:2876) The reason is that rcu_rdp_is_offloaded() is invoked without one of the required protections on RT enabled kernels because local_bh_disable() does not disable preemption on RT. Valentin proposed to add a local lock to the code in question, but that's suboptimal in several aspects: 1) local locks add extra code to !RT kernels for no value. 2) All possible callsites have to audited and amended when affected possible at an outer function level due to lock nesting issues. 3) As the local lock has to be taken at the outer functions it's required to release and reacquire them in the inner code sections which might voluntary schedule, e.g. rcu_do_batch(). Both callsites of rcu_rdp_is_offloaded() which trigger this check invoke rcu_rdp_is_offloaded() in the variable declaration section right at the top of the functions. But the actual usage of the result is either within a section which provides the required protections or after such a section. So the obvious solution is to move the invocation into the code sections which provide the proper protections, which solves the problem for RT and does not have any impact on !RT kernels. Reported-by: Valentin Schneider Signed-off-by: Thomas Gleixner --- kernel/rcu/tree.c | 7 ++++--- 1 file changed, 4 insertions(+), 3 deletions(-) --- a/kernel/rcu/tree.c +++ b/kernel/rcu/tree.c @@ -2278,13 +2278,13 @@ rcu_report_qs_rdp(struct rcu_data *rdp) { unsigned long flags; unsigned long mask; - bool needwake = false; - const bool offloaded = rcu_rdp_is_offloaded(rdp); + bool offloaded, needwake = false; struct rcu_node *rnp; WARN_ON_ONCE(rdp->cpu != smp_processor_id()); rnp = rdp->mynode; raw_spin_lock_irqsave_rcu_node(rnp, flags); + offloaded = rcu_rdp_is_offloaded(rdp); if (rdp->cpu_no_qs.b.norm || rdp->gp_seq != rnp->gp_seq || rdp->gpwrap) { @@ -2446,7 +2446,7 @@ static void rcu_do_batch(struct rcu_data int div; bool __maybe_unused empty; unsigned long flags; - const bool offloaded = rcu_rdp_is_offloaded(rdp); + bool offloaded; struct rcu_head *rhp; struct rcu_cblist rcl = RCU_CBLIST_INITIALIZER(rcl); long bl, count = 0; @@ -2472,6 +2472,7 @@ static void rcu_do_batch(struct rcu_data rcu_nocb_lock(rdp); WARN_ON_ONCE(cpu_is_offline(smp_processor_id())); pending = rcu_segcblist_n_cbs(&rdp->cblist); + offloaded = rcu_rdp_is_offloaded(rdp); div = READ_ONCE(rcu_divisor); div = div < 0 ? 7 : div > sizeof(long) * 8 - 2 ? sizeof(long) * 8 - 2 : div; bl = max(rdp->blimit, pending >> div);