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
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
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
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
linux-stable-mirror@lists.linaro.org