Re: Deadlock due to "cpuset: Make cpuset hotplug synchronous"

[Peter Zijlstra <peterz-wEGCiKHe2LqWVfeAwA7xHQ@public.gmane.org>]

On Wed, Mar 25, 2020 at 03:16:56PM -0400, Qian Cai wrote:
> [17602.773334][   T15] ======================================================
> [17602.780207][   T15] WARNING: possible circular locking dependency detected
> [17602.787081][   T15] 5.6.0-rc7-next-20200325+ #13 Tainted: G             L   
> [17602.794125][   T15] ------------------------------------------------------
> [17602.800997][   T15] cpuhp/1/15 is trying to acquire lock:
> [17602.806392][   T15] ffff900012cb7bf0 (cgroup_mutex){+.+.}-{3:3}, at: cgroup_transfer_tasks+0x130/0x2d8
> [17602.815718][   T15] 
> [17602.815718][   T15] but task is already holding lock:
> [17602.822934][   T15] ffff900012aeb2b0 (cpuhp_state-down){+.+.}-{0:0}, at: cpuhp_lock_acquire+0x8/0x48
> [17602.832078][   T15] 
> [17602.832078][   T15] which lock already depends on the new lock.
> [17602.832078][   T15] 
> [17602.842334][   T15] 
> [17602.842334][   T15] the existing dependency chain (in reverse order) is:

> [17602.946473][   T15] -> #1 (cpu_hotplug_lock){++++}-{0:0}:
> [17602.954050][   T15]        lock_acquire+0xe4/0x25c
> [17602.958841][   T15]        cpus_read_lock+0x50/0x154
> [17602.963807][   T15]        static_key_slow_inc+0x18/0x30
> [17602.969117][   T15]        mem_cgroup_css_alloc+0x824/0x8b0
> [17602.974689][   T15]        cgroup_apply_control_enable+0x1d8/0x56c
> [17602.980867][   T15]        cgroup_apply_control+0x40/0x344
> [17602.986352][   T15]        cgroup_subtree_control_write+0x664/0x69c
> [17602.992618][   T15]        cgroup_file_write+0x130/0x2e8
> [17602.997928][   T15]        kernfs_fop_write+0x228/0x32c
> [17603.003152][   T15]        __vfs_write+0x84/0x1d8
> [17603.007854][   T15]        vfs_write+0x13c/0x1b4
> [17603.012470][   T15]        ksys_write+0xb0/0x120
> [17603.017087][   T15]        __arm64_sys_write+0x54/0x88
> [17603.022223][   T15]        do_el0_svc+0x128/0x1dc
> [17603.026926][   T15]        el0_sync_handler+0x150/0x250
> [17603.032149][   T15]        el0_sync+0x164/0x180
> [17603.036674][   T15] 
> [17603.036674][   T15] -> #0 (cgroup_mutex){+.+.}-{3:3}:

> [17603.123392][   T15] other info that might help us debug this:
> [17603.123392][   T15] 
> [17603.133473][   T15] Chain exists of:
> [17603.133473][   T15]   cgroup_mutex --> cpu_hotplug_lock --> cpuhp_state-down
> [17603.133473][   T15] 

> [17603.194111][   T15] 2 locks held by cpuhp/1/15:
> [17603.198636][   T15]  #0: ffff900012ae9408 (cpu_hotplug_lock){++++}-{0:0}, at: lockdep_acquire_cpus_lock+0xc/0x3c

> [17603.218397][   T15] stack backtrace:
> [17603.224146][   T15] CPU: 1 PID: 15 Comm: cpuhp/1 Tainted: G             L    5.6.0-rc7-next-20200325+ #13
> [17603.233708][   T15] Hardware name: HPE Apollo 70             /C01_APACHE_MB         , BIOS L50_5.13_1.11 06/18/2019
> [17603.244138][   T15] Call trace:

> [17603.287957][   T15]  mutex_lock_nested+0x40/0x50
> [17603.292573][   T15]  cgroup_transfer_tasks+0x130/0x2d8
> [17603.297711][   T15]  cpuset_hotplug_update_tasks+0x6d4/0x794
> remove_tasks_in_empty_cpuset at kernel/cgroup/cpuset.c:2932
> (inlined by) hotplug_update_tasks_legacy at kernel/cgroup/cpuset.c:2973
> (inlined by) cpuset_hotplug_update_tasks at kernel/cgroup/cpuset.c:3097
> [17603.303368][   T15]  cpuset_hotplug+0x42c/0x5bc
> [17603.307897][   T15]  cpuset_update_active_cpus+0x14/0x1c
> cpuset_update_active_cpus at kernel/cgroup/cpuset.c:3230
> [17603.313208][   T15]  sched_cpu_deactivate+0x144/0x208
> [17603.318258][   T15]  cpuhp_invoke_callback+0x1dc/0x534
> [17603.323394][   T15]  cpuhp_thread_fun+0x27c/0x36c

Hurmph,.. that one is vexing indeed. The only possible solution is
changing mem_cgroup_css_alloc(), but that also doesn't look too pretty.
I so hate hotplug...