[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20251118072449.PFe_yjOF@linutronix.de>
Date: Tue, 18 Nov 2025 08:24:49 +0100
From: Sebastian Andrzej Siewior <bigeasy@...utronix.de>
To: pengdonglin <dolinux.peng@...il.com>
Cc: tj@...nel.org, tony.luck@...el.com, jani.nikula@...ux.intel.com,
ap420073@...il.com, jv@...sburgh.net, freude@...ux.ibm.com,
bcrl@...ck.org, trondmy@...nel.org, longman@...hat.com,
kees@...nel.org, hdanton@...a.com, paulmck@...nel.org,
linux-kernel@...r.kernel.org, linux-rt-devel@...ts.linux.dev,
linux-nfs@...r.kernel.org, linux-aio@...ck.org,
linux-fsdevel@...r.kernel.org,
linux-security-module@...r.kernel.org, netdev@...r.kernel.org,
intel-gfx@...ts.freedesktop.org, linux-wireless@...r.kernel.org,
linux-acpi@...r.kernel.org, linux-s390@...r.kernel.org,
cgroups@...r.kernel.org
Subject: Re: [PATCH v3 00/14] Remove redundant rcu_read_lock/unlock() in
spin_lock
On 2025-09-16 12:47:21 [+0800], pengdonglin wrote:
Hi,
> There is no need no explicitly start a RCU read section if one has already
> been started implicitly by spin_lock().
>
> Simplify the code and remove the inner rcu_read_lock() invocation.
I'm not going argue if this is a good or not but: If you intend to get
this merged I suggest you rebase your series (or what is left since I
think a few patches got merged) on top of current tree and resend them
individually targeting the relevant tree/ list. Otherwise everyone might
think someone else is in charge of this big series.
Sebastian
Powered by blists - more mailing lists