On Tue 24-09-19 11:03:21, Qian Cai wrote:
[...]
> While at it, it might be a good time to rethink the whole locking over there,
> as
> it right now read files under /sys/kernel/slab/ could trigger a possible
> deadlock anyway.
>
[...]
> [ 442.452090][ T5224] -> #0 (mem_hotplug_lock.rw_sem){++++}:
> [ 442.459748][ T5224] validate_chain+0xd10/0x2bcc
> [ 442.464883][ T5224] __lock_acquire+0x7f4/0xb8c
> [ 442.469930][ T5224] lock_acquire+0x31c/0x360
> [ 442.474803][ T5224] get_online_mems+0x54/0x150
> [ 442.479850][ T5224] show_slab_objects+0x94/0x3a8
> [ 442.485072][ T5224] total_objects_show+0x28/0x34
> [ 442.490292][ T5224] slab_attr_show+0x38/0x54
> [ 442.495166][ T5224] sysfs_kf_seq_show+0x198/0x2d4
> [ 442.500473][ T5224] kernfs_seq_show+0xa4/0xcc
> [ 442.505433][ T5224] seq_read+0x30c/0x8a8
> [ 442.509958][ T5224] kernfs_fop_read+0xa8/0x314
> [ 442.515007][ T5224] __vfs_read+0x88/0x20c
> [ 442.519620][ T5224] vfs_read+0xd8/0x10c
> [ 442.524060][ T5224] ksys_read+0xb0/0x120
> [ 442.528586][ T5224] __arm64_sys_read+0x54/0x88
> [ 442.533634][ T5224] el0_svc_handler+0x170/0x240
> [ 442.538768][ T5224] el0_svc+0x8/0xc
I believe the lock is not really needed here. We do not deallocated
pgdat of a hotremoved node nor destroy the slab state because an
existing slabs would prevent hotremove to continue in the first place.
There are likely details to be checked of course but the lock just seems
bogus.
--
Michal Hocko
SUSE Labs
