Received-SPF: softfail (google.com: domain of transitioning linux-kernel-owner@vger.kernel.org does not designate 23.128.96.19 as permitted sender) client-ip=23.128.96.19;
Date:   Fri, 27 May 2022 10:10:01 -0700
From:   "Paul E. McKenney" <paulmck@kernel.org>
To:     Zqiang <qiang1.zhang@intel.com>
Cc:     frederic@kernel.org, rcu@vger.kernel.org,
        linux-kernel@vger.kernel.org
Subject: Re: [PATCH] rcu: Cleanup RCU urgency state for offline CPU
Message-ID: <20220527171001.GT1790663@paulmck-ThinkPad-P17-Gen-1>
Reply-To: paulmck@kernel.org
References: <20220526015512.2218046-1-qiang1.zhang@intel.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20220526015512.2218046-1-qiang1.zhang@intel.com>
Precedence: bulk

On Thu, May 26, 2022 at 09:55:12AM +0800, Zqiang wrote:
> When an RCU grace period starts and at this time the CPU is in
> the process of going offline, if the RCU gp-fqs occurs during the
> time period when the CPU has passed the stop-machine but has not
> yet entered the idle loop, and this CPU have not report quiescent
> state yet, its urgent flags maybe is set, for example due to cbovld
> is true, but this CPUs rcu urgent flags is not cleanup in rcu_report_dead()
> when report qs. however for CPU that have been report qs, its rcu
> urgent flags should cleanup, so add rcu_disable_urgency_upon_qs()
> in rcu_report_dead() when CPU report qs.
> 
> Signed-off-by: Zqiang <qiang1.zhang@intel.com>

Good catch, thank you!

I have queued this on -rcu, and it will become visible on kernel.org
on my next rebase.  Assuming good test results and no objections from
reviews, I will submit this not to the current merge window, but to
the next merge window (v5.20).

							Thanx, Paul