[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <6c184b9ffc5c641736d53bb7598f814d6b4c3fe0.camel@infradead.org>
Date: Mon, 13 Dec 2021 08:18:11 +0000
From: David Woodhouse <dwmw2@...radead.org>
To: Neeraj Upadhyay <quic_neeraju@...cinc.com>, paulmck@...nel.org,
frederic@...nel.org, josh@...htriplett.org, rostedt@...dmis.org,
mathieu.desnoyers@...icios.com, jiangshanlai@...il.com,
joel@...lfernandes.org
Cc: rcu@...r.kernel.org, linux-kernel@...r.kernel.org,
urezki@...il.com, boqun.feng@...il.com
Subject: Re: [EXTERNAL] [PATCH v2] rcu/nocb: Handle concurrent nocb kthreads
creation
On Sat, 2021-12-11 at 22:31 +0530, Neeraj Upadhyay wrote:
> When multiple CPUs in the same nocb gp/cb group concurrently
> come online, they might try to concurrently create the same
> rcuog kthread. Fix this by using nocb gp CPU's spawn mutex to
> provide mutual exclusion for the rcuog kthread creation code.
>
> Signed-off-by: Neeraj Upadhyay <quic_neeraju@...cinc.com>
> ---
> Change in v2:
> Fix missing mutex_unlock in nocb gp kthread creation err path.
I think this ends up being not strictly necessary in the short term too
because we aren't currently planning to run rcutree_prepare_cpu()
concurrently anyway. But harmless and worth fixing in the longer term.
Although, if I've already added a mutex for adding the boost thread,
could we manage to use the *same* mutex instead of adding another one?
Acked-by: David Woodhouse <dwmw@...zon.co.uk>
+ mutex_unlock(&rdp_gp->nocb_gp_kthread_mutex);
> return;
> + }
> WRITE_ONCE(rdp_gp->nocb_gp_kthread, t);
> }
> + mutex_unlock(&rdp_gp->nocb_gp_kthread_mutex);
>
> /* Spawn the kthread for this CPU. */
Some whitespace damage there.
Download attachment "smime.p7s" of type "application/pkcs7-signature" (5174 bytes)
Powered by blists - more mailing lists