Re: [PATCH] loop: block loop reconfiguration of offset/sizelimit on mounted device

[Theodore Tso]

On Sun, Mar 29, 2026 at 10:54:12PM -0700, Christoph Hellwig wrote:
> On Mon, Mar 30, 2026 at 10:13:34AM +0530, Deepanshu Kartikey wrote:
> > LOOP_SET_STATUS{64} allows changing lo_offset and lo_sizelimit while
> > a filesystem is mounted on the loop device. This effectively mutates
> > the data visible to the mounted filesystem, which is equivalent to
> > writing directly to the block device.
> 
> Increasing the size certainly does not do that.
> 
> > Export bdev_writes_blocked() so it can be used from the loop driver.
> 
> I'm not sure exporting this is a good idea.  Besides the growing the
> device part above, if someone insist on changing the size, they could
> do this just fine with a remove block device, so prohibiting it locally
> just because we can seems odd.  And exporting a helper with obscure
> usage for a strange use case without documenting that is rarely a
> good idea.

The patch was missing the...

  #ifndef CONFIG_BLK_DEV_WRITE_MOUNTED)

... in loop.c which was in my original sketch of a patch which I sent
to Deepanshu.

The intent was to suppress Syzkaller noise.  Inherent in my assumption
was that changing either lo_offset or lo_sizelimit parameter was going
to mutate the loop device when it was mounted, which was the intent of
!CONFIG_BLK_DEV_WRITE_MOUNTED.  I also assumed that at least for now,
the only user of !CONFIG_BLK_DEV_WRITE_MOUNTED was syzkaller, since
there are file systems (in particular ext4) that are commonly in use
whose userspace utilities fundamentally assume that you can write to
the block device.  Even after we promulgate the tune2fs changes to use
the new EXT4_IOC_SET_TUNE_SB_PARAM ioctl and we can assume that it is
common use in deployed kernels, some grub operations still assume they
can modify the block device where the second-stage grub bootloader is
located.

In the long term, when ext4 can start assuming that we can suppress
writes to the block device (and we find a solution to the grub issue),
we'll probably want to have a way to suppress write access to block
devices on a per-super basis, without clearing the Kconfig 
CONFIG_BLK_DEV_WRITE_MOUNTED.   But that's a problem for another day...

Cheers,

						- Ted