[LTP] [PATCH v2] ioctl_loop06: update loopback block size validation

[Li Wang]

On Fri, Mar 14, 2025 at 1:57 PM Luis Chamberlain <mcgrof@kernel.org> wrote:

> On Thu, Mar 13, 2025 at 10:52:31PM -0700, Luis Chamberlain wrote:
> > On Fri, Mar 14, 2025 at 10:24:52AM +0800, Li Wang wrote:
> > > Hi Luis,
> > >
> > > On Fri, Mar 14, 2025 at 6:59 AM Luis Chamberlain <mcgrof@kernel.org>
> wrote:
> > >
> > > > On Thu, Mar 13, 2025 at 05:24:45PM +0800, Li Wang wrote:
> > > > > The kernel commit 47dd6753 ("block/bdev: lift block size
> restrictions to
> > > > 64k")
> > > > > now supports block sizes larger than PAGE_SIZE, with a new upper
> limit of
> > > > > BLK_MAX_BLOCK_SIZE (64K). But ioctl_loop06 still assumes that
> PAGE_SIZE
> > > > is the
> > > > > maximum allowed block size, causing failures on newer kernels(>=
> 6.14):
> > > >
> > >
> > > Well, this sounds like we need to go back to patch v1:
> > >   https://lists.linux.it/pipermail/ltp/2025-March/042599.html
> > >
> > > Note: LTP has a function tst_kvercmp() for comparing kernel versions.
> >
> > Close.
> >
> > BLK_MAX_BLOCK_SIZE may change in the future so the only real way to
> > test for an invalid block size is having a check for linux/blkdev.h.
> >
> > I see commit 7c84fa710f75 ("ioprio: use ioprio.h kernel header if it
> > exists") is an example of using a kernel header file. I think similar
> > thing can be done to use linux/blkdev.h and if you don't have
> > HAVE_LINUX_BLKDEV_H then you can define BLK_MAX_BLOCK_SIZE to 64k for
> > for older kernels.
> >
> > A more appropriate invalid value would be BLK_MAX_BLOCK_SIZE * 2 as
> > non power of 2 values will be outright disallowed.
>
> While at it, be sure to scale tst_fill_file("test.img", 0, 1024, 1024)
> (I think that is bs=1024, count=1024, so 1 MiB file size) so that you
> take into consideration the BLK_MAX_BLOCK_SIZE so that the file size
> will be at least maybe 10 * BLK_MAX_BLOCK_SIZE or something sensible.
>
> Because as soon as we can support a BLK_MAX_BLOCK_SIZE of 2 MiB this
> test will also fail again.
>

Make sense!! I will improve this in the next version, too.


-- 
Regards,
Li Wang