Re: ublk invert part scan bit logic

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

On Thu, Feb 12, 2026 at 03:04:53PM +0100, Hannes Reinecke wrote:
> On 2/12/26 14:02, Ming Lei wrote:
> > On Thu, Feb 12, 2026 at 05:48:40AM -0700, Jens Axboe wrote:
> > > On 2/12/26 5:42 AM, Ming Lei wrote:
> > > > On Thu, Feb 12, 2026 at 04:05:27AM -0700, Jens Axboe wrote:
> > > > > Hi,
> > > > > 
> > > > > For ublk, there's this logic in in ublk_ctrl_start_dev():
> > > > > 
> > > > > /* Skip partition scan if disabled by user */
> > > > > if (ub->dev_info.flags & UBLK_F_NO_AUTO_PART_SCAN) {
> > > > > 	clear_bit(GD_SUPPRESS_PART_SCAN, &disk->state);
> > > > > } else {
> > > > > 	/* Schedule async partition scan for trusted daemons */
> > > > > 	if (!ub->unprivileged_daemons)
> > > > > 		schedule_work(&ub->partition_scan_work);
> > > > > }
> > > > > 
> > > > > where the
> > > > > 
> > > > > clear_bit(GD_SUPPRESS_PART_SCAN, &disk->state);
> > > > > 
> > > > > seems reversed? Why is GD_SUPPRESS_PART_SCAN being cleared if
> > > > > UBLK_F_NO_AUTO_PART_SCAN is set? Added in:
> > > > > 
> > > > > 8443e2087e70 ("ublk: add UBLK_F_NO_AUTO_PART_SCAN feature flag")
> > > > 
> > > > Yeah, the interface is designed in this way: partition scan is not
> > > > done during add disk, and allowed since then on. The selftest code
> > > > is written in same way too.
> > > > 
> > > > If GD_SUPPRESS_PART_SCAN isn't cleared, userspace can't probe partitions
> > > > any more.
> > > > 
> > > > However, if you think the interface isn't good, we still can change it
> > > > before 7.0 release.
> > > 
> > > What I mean is, if UBLK_F_NO_AUTO_PART_SCAN is set, should we not
> > > either leave the disk->state alone, or _set_ GD_SUPPRESS_PART_SCAN?
> > 
> > UBLK_F_NO_AUTO_PART_SCAN means partition scanning isn't done automatically
> > from add_disk(), but it still allow userspace to send ioctl(BLKRRPART) for
> > probing partition since disk is added.
> > 
> > If GD_SUPPRESS_PART_SCAN is set, ioctl(BLKRRPART) can't succeed any more.
> > 
> > > I might be confused here, but the current implementation doesn't
> > > make much sense to me! If it is correct, then a comment to that
> > > effect would be good imho.
> > 
> > I admit it is a little confusing, will send a patch to document this
> > behavior if no one objects the UAPI.
> > 
> Is there a specific reason to continue to allow BLKRRPART if the
> UBLK_F_NO_AUTO_PART_SCAN is set? Wouldn't is be better to have a

No, I just want to allow future ioctl(BLKRRPART).

> simple 'UBLK_F_NO_PART_SCAN', which directly maps to GD_SUPPRESS_PART_SCAN?
> Would we lose something substantial in that case?

If there is, we may add new feature flag for it.

> 
> I actually would _like_ to be able to suppress partition scan
> completely for ublk devices...

Fine, we can change UBLK_F_NO_AUTO_PART_SCAN to align with GD_SUPPRESS_PART_SCAN.



Thanks,
Ming