public inbox for linux-block@vger.kernel.org
 help / color / mirror / Atom feed
* ublk invert part scan bit logic
@ 2026-02-12 11:05 Jens Axboe
  2026-02-12 12:42 ` Ming Lei
  2026-02-12 13:08 ` Alexander Atanasov
  0 siblings, 2 replies; 11+ messages in thread
From: Jens Axboe @ 2026-02-12 11:05 UTC (permalink / raw)
  To: Ming Lei, linux-block@vger.kernel.org

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")

-- 
Jens Axboe


^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: ublk invert part scan bit logic
  2026-02-12 11:05 ublk invert part scan bit logic Jens Axboe
@ 2026-02-12 12:42 ` Ming Lei
  2026-02-12 12:48   ` Jens Axboe
  2026-02-12 13:08 ` Alexander Atanasov
  1 sibling, 1 reply; 11+ messages in thread
From: Ming Lei @ 2026-02-12 12:42 UTC (permalink / raw)
  To: Jens Axboe; +Cc: linux-block@vger.kernel.org

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.


Thanks
Ming


^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: ublk invert part scan bit logic
  2026-02-12 12:42 ` Ming Lei
@ 2026-02-12 12:48   ` Jens Axboe
  2026-02-12 13:02     ` Ming Lei
  0 siblings, 1 reply; 11+ messages in thread
From: Jens Axboe @ 2026-02-12 12:48 UTC (permalink / raw)
  To: Ming Lei; +Cc: linux-block@vger.kernel.org

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?
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.

-- 
Jens Axboe


^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: ublk invert part scan bit logic
  2026-02-12 12:48   ` Jens Axboe
@ 2026-02-12 13:02     ` Ming Lei
  2026-02-12 14:04       ` Hannes Reinecke
  0 siblings, 1 reply; 11+ messages in thread
From: Ming Lei @ 2026-02-12 13:02 UTC (permalink / raw)
  To: Jens Axboe; +Cc: linux-block@vger.kernel.org

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.


Thanks,
Ming


^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: ublk invert part scan bit logic
  2026-02-12 11:05 ublk invert part scan bit logic Jens Axboe
  2026-02-12 12:42 ` Ming Lei
@ 2026-02-12 13:08 ` Alexander Atanasov
  2026-02-12 13:17   ` Ming Lei
  1 sibling, 1 reply; 11+ messages in thread
From: Alexander Atanasov @ 2026-02-12 13:08 UTC (permalink / raw)
  To: Jens Axboe, Ming Lei, linux-block@vger.kernel.org

Hi,

On 12.02.26 13:05, 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")
> 

There is more to this :
a comment few lines above states that:
	 * For unprivileged daemons, keep GD_SUPPRESS_PART_SCAN set
	 * permanently.
	 */
	set_bit(GD_SUPPRESS_PART_SCAN, &disk->state);

next in ublk_partition_scan_work it is
if (WARN_ON_ONCE(!test_and_clear_bit(GD_SUPPRESS_PART_SCAN,
it is not used anywhere else but at least for debug it is good to stay
and align with the comment.

So if i've untwisted it right:
do not clear the bit before scanning and invert logic to clear the
bit only(enable) scan only if UBLK_F_NO_AUTO_PART_SCAN is not requested
by the user for a trusted daemon.

Ming - what do you think?

-- 
have fun,
alex

diff --git a/drivers/block/ublk_drv.c b/drivers/block/ublk_drv.c
index 3c918db4905c..0d6d840b4f21 100644
--- a/drivers/block/ublk_drv.c
+++ b/drivers/block/ublk_drv.c
@@ -2361,7 +2361,7 @@ static void ublk_partition_scan_work(struct 
work_struct *work)
         if (!disk)
                 return;

-       if (WARN_ON_ONCE(!test_and_clear_bit(GD_SUPPRESS_PART_SCAN,
+       if (WARN_ON_ONCE(test_bit(GD_SUPPRESS_PART_SCAN,
                                              &disk->state)))
                 goto out;

@@ -4429,13 +4429,13 @@ static int ublk_ctrl_start_dev(struct 
ublk_device *ub,

         set_bit(UB_STATE_USED, &ub->state);

-       /* Skip partition scan if disabled by user */
-       if (ub->dev_info.flags & UBLK_F_NO_AUTO_PART_SCAN) {
+       /* Skip partition scan if disabled by user only for trusted 
daemons */
+       if (!ub->unprivileged_daemons &&
+           !(ub->dev_info.flags & UBLK_F_NO_AUTO_PART_SCAN)) {
+               /* Enable partition scanning */
                 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);
+               schedule_work(&ub->partition_scan_work);
         }

  out_put_cdev:




^ permalink raw reply related	[flat|nested] 11+ messages in thread

* Re: ublk invert part scan bit logic
  2026-02-12 13:08 ` Alexander Atanasov
@ 2026-02-12 13:17   ` Ming Lei
  2026-02-12 18:03     ` Alexander Atanasov
  0 siblings, 1 reply; 11+ messages in thread
From: Ming Lei @ 2026-02-12 13:17 UTC (permalink / raw)
  To: Alexander Atanasov; +Cc: Jens Axboe, linux-block@vger.kernel.org

On Thu, Feb 12, 2026 at 03:08:17PM +0200, Alexander Atanasov wrote:
> Hi,
> 
> On 12.02.26 13:05, 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")
> > 
> 
> There is more to this :
> a comment few lines above states that:
> 	 * For unprivileged daemons, keep GD_SUPPRESS_PART_SCAN set
> 	 * permanently.
> 	 */
> 	set_bit(GD_SUPPRESS_PART_SCAN, &disk->state);
> 
> next in ublk_partition_scan_work it is
> if (WARN_ON_ONCE(!test_and_clear_bit(GD_SUPPRESS_PART_SCAN,
> it is not used anywhere else but at least for debug it is good to stay
> and align with the comment.

Actually ioctl(BLKRRPART) does require CAP_SYS_ADMIN, so either we
modify above comment or not clear GD_SUPPRESS_PART_SCAN for
ub->unprivileged_daemons.

> 
> So if i've untwisted it right:
> do not clear the bit before scanning and invert logic to clear the
> bit only(enable) scan only if UBLK_F_NO_AUTO_PART_SCAN is not requested
> by the user for a trusted daemon.
> 
> Ming - what do you think?
> 
> -- 
> have fun,
> alex
> 
> diff --git a/drivers/block/ublk_drv.c b/drivers/block/ublk_drv.c
> index 3c918db4905c..0d6d840b4f21 100644
> --- a/drivers/block/ublk_drv.c
> +++ b/drivers/block/ublk_drv.c
> @@ -2361,7 +2361,7 @@ static void ublk_partition_scan_work(struct
> work_struct *work)
>         if (!disk)
>                 return;
> 
> -       if (WARN_ON_ONCE(!test_and_clear_bit(GD_SUPPRESS_PART_SCAN,
> +       if (WARN_ON_ONCE(test_bit(GD_SUPPRESS_PART_SCAN,
>                                              &disk->state)))

This way will fail future ioctl(BLKRRPART).

>                 goto out;
> 
> @@ -4429,13 +4429,13 @@ static int ublk_ctrl_start_dev(struct ublk_device
> *ub,
> 
>         set_bit(UB_STATE_USED, &ub->state);
> 
> -       /* Skip partition scan if disabled by user */
> -       if (ub->dev_info.flags & UBLK_F_NO_AUTO_PART_SCAN) {
> +       /* Skip partition scan if disabled by user only for trusted daemons
> */
> +       if (!ub->unprivileged_daemons &&
> +           !(ub->dev_info.flags & UBLK_F_NO_AUTO_PART_SCAN)) {

The above change looks fine.

> +               /* Enable partition scanning */
>                 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);
> +               schedule_work(&ub->partition_scan_work);

We shouldn't or can't schedule the part scan work in case of
ub->unprivileged_daemons.

Thanks,
Ming


^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: ublk invert part scan bit logic
  2026-02-12 13:02     ` Ming Lei
@ 2026-02-12 14:04       ` Hannes Reinecke
  2026-02-12 14:22         ` Ming Lei
  0 siblings, 1 reply; 11+ messages in thread
From: Hannes Reinecke @ 2026-02-12 14:04 UTC (permalink / raw)
  To: Ming Lei, Jens Axboe; +Cc: linux-block@vger.kernel.org

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
simple 'UBLK_F_NO_PART_SCAN', which directly maps to GD_SUPPRESS_PART_SCAN?
Would we lose something substantial in that case?

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

Cheers,

Hannes
-- 
Dr. Hannes Reinecke                  Kernel Storage Architect
hare@suse.de                                +49 911 74053 688
SUSE Software Solutions GmbH, Frankenstr. 146, 90461 Nürnberg
HRB 36809 (AG Nürnberg), GF: I. Totev, A. McDonald, W. Knoblich

^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: ublk invert part scan bit logic
  2026-02-12 14:04       ` Hannes Reinecke
@ 2026-02-12 14:22         ` Ming Lei
  2026-02-12 15:06           ` Hannes Reinecke
  2026-02-12 18:26           ` Alexander Atanasov
  0 siblings, 2 replies; 11+ messages in thread
From: Ming Lei @ 2026-02-12 14:22 UTC (permalink / raw)
  To: Hannes Reinecke; +Cc: Jens Axboe, linux-block@vger.kernel.org

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


^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: ublk invert part scan bit logic
  2026-02-12 14:22         ` Ming Lei
@ 2026-02-12 15:06           ` Hannes Reinecke
  2026-02-12 18:26           ` Alexander Atanasov
  1 sibling, 0 replies; 11+ messages in thread
From: Hannes Reinecke @ 2026-02-12 15:06 UTC (permalink / raw)
  To: Ming Lei; +Cc: Jens Axboe, linux-block@vger.kernel.org

On 2/12/26 15:22, Ming Lei wrote:
> 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:
[ .. ]
>>>> 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.
> 
yes, please. That would make the code easier to understand and we 
wouldn't need to have any 'special' handling (or documentation)
here.

Cheers,

Hannes
-- 
Dr. Hannes Reinecke                  Kernel Storage Architect
hare@suse.de                                +49 911 74053 688
SUSE Software Solutions GmbH, Frankenstr. 146, 90461 Nürnberg
HRB 36809 (AG Nürnberg), GF: I. Totev, A. McDonald, W. Knoblich

^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: ublk invert part scan bit logic
  2026-02-12 13:17   ` Ming Lei
@ 2026-02-12 18:03     ` Alexander Atanasov
  0 siblings, 0 replies; 11+ messages in thread
From: Alexander Atanasov @ 2026-02-12 18:03 UTC (permalink / raw)
  To: Ming Lei; +Cc: Jens Axboe, linux-block@vger.kernel.org

On 12.02.26 15:17, Ming Lei wrote:

Cooked up a patch - i think i've hit some of the points in the thread.

https://lore.kernel.org/linux-block/20260212152553.1737373-1-alex@zazolabs.com/T/#u

-- 
have fun,
alex

^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: ublk invert part scan bit logic
  2026-02-12 14:22         ` Ming Lei
  2026-02-12 15:06           ` Hannes Reinecke
@ 2026-02-12 18:26           ` Alexander Atanasov
  1 sibling, 0 replies; 11+ messages in thread
From: Alexander Atanasov @ 2026-02-12 18:26 UTC (permalink / raw)
  To: Ming Lei, Hannes Reinecke; +Cc: Jens Axboe, linux-block@vger.kernel.org

On 12.02.26 16:22, Ming Lei wrote:
> 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:

>>>
>> 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.


These are two different things, does not make sense to merge them.

Use case is you have a backing files which are not ready/accessible -
you create a device with UBLK_F_NO_AUTO_PART_SCAN.
Do some preparations using the device and when files are ready
read the partitions.

If there is a use case to disable partitions on a trusted devices then a
new flag to map to GD_SUPPRESS_PART_SCAN makes sense.
And that is in case using UBLK_F_NO_AUTO_PART_SCAN to suppress initial
auto scan is not enough.


-- 
have fun,
alex

^ permalink raw reply	[flat|nested] 11+ messages in thread

end of thread, other threads:[~2026-02-12 18:26 UTC | newest]

Thread overview: 11+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2026-02-12 11:05 ublk invert part scan bit logic Jens Axboe
2026-02-12 12:42 ` Ming Lei
2026-02-12 12:48   ` Jens Axboe
2026-02-12 13:02     ` Ming Lei
2026-02-12 14:04       ` Hannes Reinecke
2026-02-12 14:22         ` Ming Lei
2026-02-12 15:06           ` Hannes Reinecke
2026-02-12 18:26           ` Alexander Atanasov
2026-02-12 13:08 ` Alexander Atanasov
2026-02-12 13:17   ` Ming Lei
2026-02-12 18:03     ` Alexander Atanasov

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox