diff options
author | Frederic Weisbecker <frederic@kernel.org> | 2024-05-30 15:45:44 +0200 |
---|---|---|
committer | Neeraj Upadhyay <neeraj.upadhyay@kernel.org> | 2024-07-29 07:34:31 +0530 |
commit | 7be88a857eb84d2e0677690b81ee423dee51c93d (patch) | |
tree | a0c4b7d0d37c44e06e8ef8b883087e104cbcc319 /lib/crypto/mpi/mpi-pow.c | |
parent | ff81428ede8a290fc5fd85135e39be1065ae6176 (diff) |
rcu/nocb: Assert no callbacks while nocb kthread allocation fails
When a NOCB CPU fails to create a nocb kthread on bringup, the CPU is
then deoffloaded. The barrier mutex is locked at this stage. It is
typically used to protect against concurrent (de-)offloading and/or
concurrent rcu_barrier() that would otherwise risk a nocb locking
imbalance. However:
* rcu_barrier() can't run concurrently if it's the boot CPU on early
boot-up.
* rcu_barrier() can run concurrently if it's a secondary CPU but it is
expected to see 0 callbacks on this target because it's the first
time it boots.
* (de-)offloading can't happen concurrently with smp_init(), as
rcutorture is initialized later, at least not before device_initcall(),
and userspace isn't available yet.
* (de-)offloading can't happen concurrently with cpu_up(), courtesy of
cpu_hotplug_lock.
But:
* The lazy shrinker might run concurrently with cpu_up(). It shouldn't
try to grab the nocb_lock and risk an imbalance due to lazy_len
supposed to be 0 but be extra cautious.
* Also be cautious against resume from hibernation potential subtleties.
So keep the locking and add some assertions and comments.
Signed-off-by: Frederic Weisbecker <frederic@kernel.org>
Signed-off-by: Paul E. McKenney <paulmck@kernel.org>
Reviewed-by: Paul E. McKenney <paulmck@kernel.org>
Signed-off-by: Neeraj Upadhyay <neeraj.upadhyay@kernel.org>
Diffstat (limited to 'lib/crypto/mpi/mpi-pow.c')
0 files changed, 0 insertions, 0 deletions