Re: "loop: Avoid updating block size under exclusive owner" breaks on 6.6.103

Re: "loop: Avoid updating block size under exclusive owner" breaks on 6.6.103

[Jan Kara]

On Wed 17-09-25 11:18:50, Eric Hagberg wrote:
> I stumbled across a problem where the 6.6.103 kernel will fail when
> running the ioctl_loop06 test from the LTP test suite... and worse
> than failing the test, it leaves the system in a state where you can't
> run "losetup -a" again because the /dev/loopN device that the test
> created and failed the test on... hangs in a LOOP_GET_STATUS64 ioctl.
> 
> It also leaves the system in a state where you can't re-kexec into a
> copy of the kernel as it gets completely hung at the point where it
> says "starting Reboot via kexec"...

Thanks for the report! Please report issues with stable kernels to
stable@vger.kernel.org (CCed now) because they can act on them.

> If I revert just that patch from 6.6.103 (or newer) kernels, then the
> test succeeds and doesn't leave the host in a bad state. The patch
> applied to 6.12 doesn't cause this problem, but I also see that there
> are quite a few other changes to the loop subsystem in 6.12 that never
> made it to 6.6.
> 
> For now, I'll probably just revert your patch in my 6.6 kernel builds,
> but I wouldn't be surprised if others stumble across this issue as
> well, so maybe it should be reverted or fixed some other way.

Yes, I think revert from 6.6 stable kernel is warranted (unless somebody
has time to figure out what else is missing to make the patch work with
that stable branch).

							Honza
-- 
Jan Kara <jack@suse.com>
SUSE Labs, CR

Re: "loop: Avoid updating block size under exclusive owner" breaks on 6.6.103

[Greg KH]

On Wed, Sep 17, 2025 at 05:47:16PM +0200, Jan Kara wrote:
> On Wed 17-09-25 11:18:50, Eric Hagberg wrote:
> > I stumbled across a problem where the 6.6.103 kernel will fail when
> > running the ioctl_loop06 test from the LTP test suite... and worse
> > than failing the test, it leaves the system in a state where you can't
> > run "losetup -a" again because the /dev/loopN device that the test
> > created and failed the test on... hangs in a LOOP_GET_STATUS64 ioctl.
> > 
> > It also leaves the system in a state where you can't re-kexec into a
> > copy of the kernel as it gets completely hung at the point where it
> > says "starting Reboot via kexec"...
> 
> Thanks for the report! Please report issues with stable kernels to
> stable@vger.kernel.org (CCed now) because they can act on them.
> 
> > If I revert just that patch from 6.6.103 (or newer) kernels, then the
> > test succeeds and doesn't leave the host in a bad state. The patch
> > applied to 6.12 doesn't cause this problem, but I also see that there
> > are quite a few other changes to the loop subsystem in 6.12 that never
> > made it to 6.6.
> > 
> > For now, I'll probably just revert your patch in my 6.6 kernel builds,
> > but I wouldn't be surprised if others stumble across this issue as
> > well, so maybe it should be reverted or fixed some other way.
> 
> Yes, I think revert from 6.6 stable kernel is warranted (unless somebody
> has time to figure out what else is missing to make the patch work with
> that stable branch).

Great, can someone send me the revert?

thanks,

greg k-h

Re: "loop: Avoid updating block size under exclusive owner" breaks on 6.6.103

[Eric Hagberg]

This is what I applied:

--- b/drivers/block/loop.c
+++ a/drivers/block/loop.c
@@ -1472,36 +1472,19 @@
        return error;
 }

+static int loop_set_block_size(struct loop_device *lo, unsigned long arg)
-static int loop_set_block_size(struct loop_device *lo, blk_mode_t mode,
-                              struct block_device *bdev, unsigned long arg)
 {
        int err = 0;

+       if (lo->lo_state != Lo_bound)
+               return -ENXIO;
-       /*
-        * If we don't hold exclusive handle for the device, upgrade to it
-        * here to avoid changing device under exclusive owner.
-        */
-       if (!(mode & BLK_OPEN_EXCL)) {
-               err = bd_prepare_to_claim(bdev, loop_set_block_size, NULL);
-               if (err)
-                       return err;
-       }
-
-       err = mutex_lock_killable(&lo->lo_mutex);
-       if (err)
-               goto abort_claim;
-
-       if (lo->lo_state != Lo_bound) {
-               err = -ENXIO;
-               goto unlock;
-       }

        err = blk_validate_block_size(arg);
        if (err)
                return err;

        if (lo->lo_queue->limits.logical_block_size == arg)
+               return 0;
-               goto unlock;

        sync_blockdev(lo->lo_device);
        invalidate_bdev(lo->lo_device);
@@ -1513,11 +1496,6 @@
        loop_update_dio(lo);
        blk_mq_unfreeze_queue(lo->lo_queue);

-unlock:
-       mutex_unlock(&lo->lo_mutex);
-abort_claim:
-       if (!(mode & BLK_OPEN_EXCL))
-               bd_abort_claiming(bdev, loop_set_block_size);
        return err;
 }

@@ -1536,6 +1514,9 @@
        case LOOP_SET_DIRECT_IO:
                err = loop_set_dio(lo, arg);
                break;
+       case LOOP_SET_BLOCK_SIZE:
+               err = loop_set_block_size(lo, arg);
+               break;
        default:
                err = -EINVAL;
        }
@@ -1590,12 +1571,9 @@
                break;
        case LOOP_GET_STATUS64:
                return loop_get_status64(lo, argp);
-       case LOOP_SET_BLOCK_SIZE:
-               if (!(mode & BLK_OPEN_WRITE) && !capable(CAP_SYS_ADMIN))
-                       return -EPERM;
-               return loop_set_block_size(lo, mode, bdev, arg);
        case LOOP_SET_CAPACITY:
        case LOOP_SET_DIRECT_IO:
+       case LOOP_SET_BLOCK_SIZE:
                if (!(mode & BLK_OPEN_WRITE) && !capable(CAP_SYS_ADMIN))
                        return -EPERM;
                fallthrough;


On Sun, Sep 21, 2025 at 1:17 PM Greg KH <gregkh@linuxfoundation.org> wrote:
>
> On Wed, Sep 17, 2025 at 05:47:16PM +0200, Jan Kara wrote:
> > On Wed 17-09-25 11:18:50, Eric Hagberg wrote:
> > > I stumbled across a problem where the 6.6.103 kernel will fail when
> > > running the ioctl_loop06 test from the LTP test suite... and worse
> > > than failing the test, it leaves the system in a state where you can't
> > > run "losetup -a" again because the /dev/loopN device that the test
> > > created and failed the test on... hangs in a LOOP_GET_STATUS64 ioctl.
> > >
> > > It also leaves the system in a state where you can't re-kexec into a
> > > copy of the kernel as it gets completely hung at the point where it
> > > says "starting Reboot via kexec"...
> >
> > Thanks for the report! Please report issues with stable kernels to
> > stable@vger.kernel.org (CCed now) because they can act on them.
> >
> > > If I revert just that patch from 6.6.103 (or newer) kernels, then the
> > > test succeeds and doesn't leave the host in a bad state. The patch
> > > applied to 6.12 doesn't cause this problem, but I also see that there
> > > are quite a few other changes to the loop subsystem in 6.12 that never
> > > made it to 6.6.
> > >
> > > For now, I'll probably just revert your patch in my 6.6 kernel builds,
> > > but I wouldn't be surprised if others stumble across this issue as
> > > well, so maybe it should be reverted or fixed some other way.
> >
> > Yes, I think revert from 6.6 stable kernel is warranted (unless somebody
> > has time to figure out what else is missing to make the patch work with
> > that stable branch).
>
> Great, can someone send me the revert?
>
> thanks,
>
> greg k-h

Re: "loop: Avoid updating block size under exclusive owner" breaks on 6.6.103

[Greg KH]

On Mon, Sep 22, 2025 at 10:07:55AM -0400, Eric Hagberg wrote:
> This is what I applied:

<snip>

Can you turn it into a patch I can apply with the reasons why it's being
reverted and your signed-off-by line?  Same format as any other normal
kernel patch.

thanks,

greg k-h