[LTP] [PATCH] block: add BLK_FEAT_LBS to check for PAGE_SIZE limit
Hannes Reinecke
hare@suse.de
Thu Mar 13 09:26:41 CET 2025
On 3/13/25 03:54, Li Wang wrote:
>
>
> On Wed, Mar 12, 2025 at 9:59 PM Christoph Hellwig <hch@lst.de
> <mailto:hch@lst.de>> wrote:
>
> On Wed, Mar 12, 2025 at 05:19:36PM +0800, Li Wang wrote:
> > Well, does that patch for ioctl_loop06 still make sense?
> > Or any other workaround?
> > https://lists.linux.it/pipermail/ltp/2025-March/042599.html
> <https://lists.linux.it/pipermail/ltp/2025-March/042599.html>
>
> The real question is what block sizes we want to support for the
> loop driver. Because if it is larger than the physical block size
> it can lead to torn writes. But I guess no one cared about those
> on loop so far, so why care about this now..
>
>
> That's because the kernel test-robot reports a LTP/ioctl_loop06 test
> fail in kernel commit:
> 47dd67532303803 ("block/bdev: lift block size restrictions to 64k")
>
> The ioctl_loop06 is a boundary testing and always fail with
> LOOP_SET_BLOCK_SIZE set a value larger than PAGE_SIZE.
> But now it's set successfully unexpectedly.
>
> If you all believe the boundary test for loopback driver is redundant,
> I can help remove that from LTP code.
>
I would remove it.
Yes, we might incur torn writes, but previously we hadn't cared about
that. And if we cared we should have a dedicated test for that; there's
no guarantee that we cannot have torn writes even with 4k blocks.
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
More information about the ltp
mailing list