On 2020-04-16 14:00:57 [-0700], Paul E. McKenney wrote: > > We might need different calling-context restrictions for the two variants > of kfree_rcu(). And we might need to come up with some sort of lockdep > check for "safe to use normal spinlock in -rt". Oh. We do have this already, it is called CONFIG_PROVE_RAW_LOCK_NESTING. This one will scream if you do raw_spin_lock(); spin_lock(); Sadly, as of today, there is code triggering this which needs to be addressed first (but it is one list of things to do). Given the thread so far, is it okay if I repost the series with migrate_disable() instead of accepting a possible migration before grabbing the lock? I would prefer to avoid the extra RT case (avoiding memory allocations in a possible atomic context) until we get there. > Thanx, Paul Sebastian
