Comment # 8 on bug 1203539 from Jan Kara

For reference the softlockup is:

watchdog: BUG: soft lockup - CPU#0 stuck for 22s! [systemd-udevd:711]
Modules linked in: idma64 thermal fjes(-) ac acpi_pad intel_hid(N)
acpi_cpufreq(-) sparse_keymap fuse configfs ip_tables x_tables ext4 crc16
mbcache jbd2 hid_generic usbhid rtsx_pci_sdmmc i915 mmc_core sd_mod
i2c_algo_bit ttm drm_kms_helper nvme crc32_pclmul crc32c_intel syscopyarea
sysfillrect sysimgblt nvme_core fb_sys_fops cec ahci rtsx_pci rc_core libahci
xhci_pci nvme_common xhci_pci_renesas ghash_clmulni_intel xhci_hcd aesni_intel
drm crypto_simd cryptd libata usbcore serio_raw mfd_core t10_pi i2c_hid_acpi
battery i2c_hid wmi video pinctrl_cannonlake button v4l2loopback(OEN) videodev
mc sg dm_multipath dm_mod scsi_dh_rdac scsi_dh_emc scsi_dh_alua scsi_mod msr
efivarfs
Supported: No, Unsupported modules are loaded
CPU: 0 PID: 711 Comm: systemd-udevd Tainted: G           OE     N
5.14.21-150400.24.21-default #1 SLE15-SP4
7550826c4c7e8c258239e300508e0c8b2a69bad2
Hardware name: Novatech PB50_70DFx,DDx                          /PB50_70DFx,DDx
                         , BIOS 1.07.07TNO 09/25/2019
RIP: 0010:smp_call_function_many_cond+0x126/0x560
RAX: 0000000000000011 RBX: 0000000000000001 RCX: 0000000000000000
RDX: 0000000000000011 RSI: 0000000000000000 RDI: ffff9416c04794c0
RBP: 0000000000000001 R08: 0000000000000000 R09: 0000000000000000
R10: 0000000000000001 R11: 0000000000000000 R12: ffff9416c0434a40
R13: ffff9416c0434a40 R14: ffffffff9f38d650 R15: 00000000000394c0
FS:  00007f340f894b00(0000) GS:ffff9416c0400000(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 0000564868903ce8 CR3: 000000010a608002 CR4: 00000000007706f0
PKRU: 55555554
Call Trace:
 <TASK>
 ? __brelse+0x30/0x30
 on_each_cpu_cond_mask+0x25/0x40
 kill_bdev.isra.31+0x16/0x30
 blkdev_flush_mapping+0x46/0xf0
 blkdev_put_whole+0x3a/0x50
 blkdev_put+0x57/0x180
 blkdev_close+0x21/0x30
 __fput+0x8f/0x250
 ? __SCT__preempt_schedule_notrace+0x8/0x8
 task_work_run+0x70/0xb0
 exit_to_user_mode_prepare+0x228/0x230
 syscall_exit_to_user_mode+0x18/0x40
 do_syscall_64+0x67/0x80
...

So we are actually stuck in the smp_call_function_many_cond() call. The work
queued on each CPU is actually pretty trivial (read per-cpu variable and
decrease one refcount). So likely this is not related to any change in the
block layer but rather due to some CPU getting stuck with interrupts disabled
so we cannot execute work on it. Maybe this is somehow related to the USB
devices that are probed by mtp-probe when the hang happens?