Received: by 2002:a05:6a10:d5a5:0:0:0:0 with SMTP id gn37csp1450403pxb; Fri, 1 Oct 2021 10:50:20 -0700 (PDT) X-Google-Smtp-Source: ABdhPJz+ew2BvKfSqWWcGOC9BWhA++x2tcr5Be8B7tjgxHcM0oNEkvSPVlEAnr5z1+BNSnU7BJ2j X-Received: by 2002:a17:90a:428e:: with SMTP id p14mr21568762pjg.229.1633110620763; Fri, 01 Oct 2021 10:50:20 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1633110620; cv=none; d=google.com; s=arc-20160816; b=lmW1k3K3yxc4EkEjdODJ0jNCtlw5ltVqS/HfPRoDSbGqosRy0ZfSePoz3LUdFlxps6 8TxbDpCKnI6xB3seH5FydCYin09qGLl9Ha/dpDNwJ0R6akoQT3Fc/3YGz1SHyuKxBE8c CH5E8XQ8vGsRXD/m2DOBNlo2KzVt4sCi0JJ895hjwtGRAxjT6EKt2gvphnILizn2LjGd xMoeFiXV/3RvMC7SQib4j323921JXFI6aXZLliNwereHtS43KOFexw1Rgr2X4RwyiTbK r6xzM9NzL3QV4GENcUduFq57kQMy+6Fwlnh1En/n0QrjTm+H4drrGaxmm761oKGQ8ceN oRPQ== 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:from; bh=HTdgGZXDfTDod8xnjnB11tx7DbfC+KN52xvnIk+LFqk=; b=DqZDycbBxOzbkxclDfIuM62rrmyPp2eUHmo/EVwGstjEF/6llx+bwqdqczxoFq13QT EnG+skVP85CaWR1Hvj6hC6LOUWoJv0ncWjJxd2pdPFKmbQGoYP68nehdmhc3eplh3oOn VbwUk0opi+pOFIrwRd2Z8bBhyzL09ab3W6IzHij8Zxw7SjEQscB496FyuXA/YpMgm/Ro SuW+yncOMQDI+m8pBwZkgSmO3MK6AigWUE48ojtPdi6Jvjc/qbAkrYObPHasBz0PUypw 03W1ekWvFSnthIJo/sQiZpI/gIbjkWFBv+uc+COJyuvE8AmQ4xqthCwL71AIT0jmYHqz 6YYg== ARC-Authentication-Results: i=1; mx.google.com; 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=fail (p=NONE sp=NONE dis=NONE) header.from=arm.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id k9si8755861pls.321.2021.10.01.10.50.07; Fri, 01 Oct 2021 10:50:20 -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; 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=fail (p=NONE sp=NONE dis=NONE) header.from=arm.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1355262AbhJARuT (ORCPT + 99 others); Fri, 1 Oct 2021 13:50:19 -0400 Received: from foss.arm.com ([217.140.110.172]:49368 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232413AbhJARuR (ORCPT ); Fri, 1 Oct 2021 13:50:17 -0400 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id E463B106F; Fri, 1 Oct 2021 10:48:31 -0700 (PDT) Received: from e113632-lin (usa-sjc-imap-foss1.foss.arm.com [10.121.207.14]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 4347C3F70D; Fri, 1 Oct 2021 10:48:30 -0700 (PDT) From: Valentin Schneider To: Frederic Weisbecker , "Paul E . McKenney" Cc: LKML , Frederic Weisbecker , Sebastian Andrzej Siewior , Peter Zijlstra , Uladzislau Rezki , Thomas Gleixner , Boqun Feng , Neeraj Upadhyay , Josh Triplett , Joel Fernandes , rcu@vger.kernel.org Subject: Re: [PATCH 02/11] rcu/nocb: Prepare state machine for a new step In-Reply-To: <20210929221012.228270-3-frederic@kernel.org> References: <20210929221012.228270-1-frederic@kernel.org> <20210929221012.228270-3-frederic@kernel.org> Date: Fri, 01 Oct 2021 18:48:28 +0100 Message-ID: <87ee94myab.mognet@arm.com> MIME-Version: 1.0 Content-Type: text/plain Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 30/09/21 00:10, Frederic Weisbecker wrote: > Currently SEGCBLIST_SOFTIRQ_ONLY is a bit of an exception among the > segcblist flags because it is an exclusive state that doesn't mix up > with the other flags. Remove it in favour of: > > _ A flag specifying that rcu_core() needs to perform callbacks execution > and acceleration > > and > > _ A flag specifying we want the nocb lock to be held in any needed > circumstances > > This clarifies the code and is more flexible: It allows to have a state > where rcu_core() runs with locking while offloading hasn't started yet. > This is a necessary step to prepare for triggering rcu_core() at the > very beginning of the de-offloading process so that rcu_core() won't > dismiss work while being preempted by the de-offloading process, at > least not without a pending subsequent rcu_core() that will quickly > catch up. > > Signed-off-by: Frederic Weisbecker > Cc: Valentin Schneider > Cc: Peter Zijlstra > Cc: Sebastian Andrzej Siewior > Cc: Josh Triplett > Cc: Joel Fernandes > Cc: Boqun Feng > Cc: Neeraj Upadhyay > Cc: Uladzislau Rezki > Cc: Thomas Gleixner One question and a comment nit below, other than that: Reviewed-by: Valentin Schneider > @@ -84,7 +84,7 @@ static inline bool rcu_segcblist_is_enabled(struct rcu_segcblist *rsclp) > static inline bool rcu_segcblist_is_offloaded(struct rcu_segcblist *rsclp) It doesn't show up on the diff but there's a SEGCBLIST_SOFTIRQ_ONLY straggler in the comment above (the last one according to grep). > { > if (IS_ENABLED(CONFIG_RCU_NOCB_CPU) && > - !rcu_segcblist_test_flags(rsclp, SEGCBLIST_SOFTIRQ_ONLY)) > + rcu_segcblist_test_flags(rsclp, SEGCBLIST_LOCKING)) > return true; > > return false; > @@ -1000,12 +1000,12 @@ static long rcu_nocb_rdp_deoffload(void *arg) > */ > rcu_nocb_lock_irqsave(rdp, flags); > /* > - * Theoretically we could set SEGCBLIST_SOFTIRQ_ONLY after the nocb > + * Theoretically we could clear SEGCBLIST_LOCKING after the nocb > * lock is released but how about being paranoid for once? > */ > - rcu_segcblist_set_flags(cblist, SEGCBLIST_SOFTIRQ_ONLY); > + rcu_segcblist_clear_flags(cblist, SEGCBLIST_LOCKING); Thought experiment for me; AFAICT the comment still holds: we can't offload until deoffload has finished, and we shouldn't be able to preempt rcu_core() while it holds ->nocb_lock. With that said, I'm all for paranoia. > /* > - * With SEGCBLIST_SOFTIRQ_ONLY, we can't use > + * Without SEGCBLIST_LOCKING, we can't use > * rcu_nocb_unlock_irqrestore() anymore. > */ > raw_spin_unlock_irqrestore(&rdp->nocb_lock, flags);