[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