Re: ublk: partition scan during START_DEV can block userspace

[Ming Lei <ming.lei@redhat.com>]

On Thu, Dec 18, 2025 at 10:11:18AM +0000, Yoav Cohen wrote:
> Hi,
> 
> Background:
> We expose a network-managed block device using ublk.
> 
> When issuing START_DEV, the kernel automatically attempts to scan the disk
> partitions. This results in synchronous reads from the device, as shown in the
> stack trace below:
> 
> [<0>] folio_wait_bit_common+0x138/0x310
> [<0>] filemap_read_folio+0x94/0xe0
> [<0>] do_read_cache_folio+0x80/0x1c0
> [<0>] read_cache_folio+0x12/0x30
> [<0>] read_part_sector+0x39/0xe0
> [<0>] read_lba+0x91/0x110
> [<0>] find_valid_gpt.constprop.0+0xe5/0x5d0
> [<0>] efi_partition+0x5b/0x360
> [<0>] check_partition+0x166/0x3c0
> [<0>] blk_add_partitions+0x3e/0x280
> [<0>] bdev_disk_changed+0x149/0x1c0
> [<0>] blkdev_get_whole+0x8c/0xb0
> [<0>] bdev_open+0x2ea/0x3c0
> [<0>] bdev_file_open_by_dev+0xde/0x140
> [<0>] disk_scan_partitions+0x68/0x130
> [<0>] add_disk_fwnode+0x46c/0x490
> [<0>] device_add_disk+0x10/0x20
> [<0>] ublk_ctrl_start_dev.isra.0+0x29d/0x3a0 [ublk_drv]
> [<0>] ublk_ctrl_uring_cmd+0x407/0x600 [ublk_drv]
> [<0>] io_uring_cmd+0xa4/0x150
> 
> Problems observed
> 
> Userspace crash can leave the process stuck
> 
> If the ublk userspace server crashes while this partition-scan I/O is in
> progress, the process may fail to terminate cleanly. For example:
> 
> yoav@nvme195:~$ sudo cat /proc/3083/stack
> [<0>] do_exit+0xd7/0xa50
> [<0>] do_group_exit+0x34/0x90
> [<0>] get_signal+0x928/0x950
> [<0>] arch_do_signal_or_restart+0x41/0x260
> [<0>] irqentry_exit_to_user_mode+0x13b/0x1d0
> [<0>] irqentry_exit+0x43/0x50
> [<0>] sysvec_reschedule_ipi+0x65/0x110
> [<0>] asm_sysvec_reschedule_ipi+0x1b/0x20
> 
> At this point, the server is no longer able to serve I/O, yet the kernel is
> still waiting for completion of the partition-scan reads, preventing proper
> shutdown and recovery.
> 
> Restart requires serving partition scan I/O
> 
> Even without a crash, restarting the userspace application requires handling
> these implicit partition-scan requests. This is undesirable for our use case,
> as the device contents are managed remotely and partition probing is not always
> meaningful or wanted.
> 
> No way to suppress partition scanning in ublk
> 
> We considered introducing an option to set GD_SUPPRESS_PART_SCAN at device
> startup, and possibly triggering partition scanning later from userspace when
> appropriate. However, it is not clear whether this is the correct approach, nor
> from which context such a rescan should safely be initiated.
> 
> Questions / discussion points
> 
> Is there an existing, recommended way for ublk devices to suppress automatic
> partition scanning at START_DEV time?

No, there isn't.

> 
> Would it make sense to add a ublk-specific option to control
> GD_SUPPRESS_PART_SCAN, similar to how some other drivers handle this?

Yes, I think it is reasonable to add this feature flag via `ublksrv_ctrl_dev_info`,
and it should be very useful & flexible for user to scan partitions by
themselves.

> 
> Are there alternative approaches to avoid blocking behavior during device
> startup without requiring kernel changes?

It should be triggered in case of UBLK_F_USER_RECOVERY only.

add_disk() is run with ub->mutex grabbed, so the following UBLK_U_CMD_DEL_DEV or
STOP_DEV command hangs forever on the ub->mutex.

I will think about how to fix this issue. Probably the lock needs to be
released when calling add_disk().


Thanks,
Ming