Messages in this thread | | | Date | Fri, 22 Nov 2019 21:01:22 +0100 | From | Sebastian Andrzej Siewior <> | Subject | Re: [tip: sched/urgent] sched/core: Avoid spurious lock dependencies |
| |
On 2019-11-13 10:06:28 [-0000], tip-bot2 for Peter Zijlstra wrote: > sched/core: Avoid spurious lock dependencies > > While seemingly harmless, __sched_fork() does hrtimer_init(), which, > when DEBUG_OBJETS, can end up doing allocations. > > This then results in the following lock order: > > rq->lock > zone->lock.rlock > batched_entropy_u64.lock > > Which in turn causes deadlocks when we do wakeups while holding that > batched_entropy lock -- as the random code does.
Peter, can it _really_ cause deadlocks? My understanding was that the batched_entropy_u64.lock is a per-CPU lock and can _not_ cause a deadlock because it can be always acquired on multiple CPUs simultaneously (and it is never acquired cross-CPU). Lockdep is simply not smart enough to see that and complains about it like it would complain about a regular lock in this case.
Sebastian
| |