On Fri, Feb 21, 2020 at 07:00:45PM -0500, Daniel Jordan wrote:
On Fri, Feb 21, 2020 at 08:40:34AM +0100, Greg Kroah-Hartman wrote:From: Daniel Jordan <daniel.m.jordan@xxxxxxxxxx> [ Upstream commit 38228e8848cd7dd86ccb90406af32de0cad24be3 ] lockdep complains when padata's paths to update cpumasks via CPU hotplug and sysfs are both taken: # echo 0 > /sys/devices/system/cpu/cpu1/online # echo ff > /sys/kernel/pcrypt/pencrypt/parallel_cpumask ====================================================== WARNING: possible circular locking dependency detected 5.4.0-rc8-padata-cpuhp-v3+ #1 Not tainted ------------------------------------------------------ bash/205 is trying to acquire lock: ffffffff8286bcd0 (cpu_hotplug_lock.rw_sem){++++}, at: padata_set_cpumask+0x2b/0x120 but task is already holding lock: ffff8880001abfa0 (&pinst->lock){+.+.}, at: padata_set_cpumask+0x26/0x120 which lock already depends on the new lock.I think this patch should be dropped from all stable queues (4.4, 4.9, 4.14, 4.19, 5.4, and 5.5). The main benefit is to un-break lockdep for testing with future padata changes, and an actual deadlock seems unlikely. These stable versions don't fix the ordering in padata_remove_cpu() either (nothing calls it though). I tried the other stable padata patch in this cycle ("padata: validate cpumask without removed CPU during offline"), it passed my tests and should stay in.
I've dropped it, thanks. -- Thanks, Sasha
