[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <aV_Pp5BUxB9dwp1S@localhost.localdomain>
Date: Thu, 8 Jan 2026 16:39:19 +0100
From: Frederic Weisbecker <frederic@...nel.org>
To: Joel Fernandes <joel@...lfernandes.org>
Cc: Joel Fernandes <joelagnelf@...dia.com>,
Paul E McKenney <paulmck@...nel.org>,
Boqun Feng <boqun.feng@...il.com>, rcu@...r.kernel.org,
Neeraj Upadhyay <neeraj.upadhyay@...nel.org>,
Josh Triplett <josh@...htriplett.org>,
Uladzislau Rezki <urezki@...il.com>,
Steven Rostedt <rostedt@...dmis.org>,
Mathieu Desnoyers <mathieu.desnoyers@...icios.com>,
Lai Jiangshan <jiangshanlai@...il.com>,
Zqiang <qiang.zhang@...ux.dev>, Shuah Khan <shuah@...nel.org>,
linux-kernel@...r.kernel.org, linux-kselftest@...r.kernel.org,
Kai Yao <yaokai34@...wei.com>, Tengda Wu <wutengda2@...wei.com>
Subject: Re: [PATCH -next 1/8] rcu: Fix rcu_read_unlock() deadloop due to
softirq
Le Wed, Jan 07, 2026 at 10:35:44PM -0500, Joel Fernandes a écrit :
> >
> > By the way, when I last tried to do it from rcu_qs, it was not fixing the original bug with the IRQ work recursion.
> >
> > I found that it was always resetting the flag. But probably it is not even the right place to do it in the first place.
>
> I think we need to reset the flag in rcu_report_exp_rdp() as well if exp_hint
> is set and we reported exp qs.
To avoid needlessly reaching the rcu_read_unlock() slowpath whenever the exp QS has
already been reported, yes indeed.
> I am working on a series to cover all cases and will send RFC soon. However this patch we are
> reviewing can go in for this merge window and the rest I am preparing (for
> further improvement) for the next merge window, if that sounds good.
Ok.
--
Frederic Weisbecker
SUSE Labs
Powered by blists - more mailing lists