[LTP] [PATCH v2] kernel/device-drivers/zram/zram01.sh : don't fill from /dev/zero

[Richard Palethorpe]

Hello,

Ian Wienand <iwienand@redhat.com> writes:

> On Wed, Sep 13, 2023 at 03:35:18PM +0100, Richard Palethorpe wrote:
>> I would suggest just using sync, but Petr originally suggested using a
>> wait loop. Then reported that the bug was still reproducible with the
>> loop:
>> 
>> https://lore.kernel.org/linux-block/Y3s+Czg8sBsGYO+1@pevik/
>> 
>> Then said it wasn't reproducible. The problem is that if using a loop
>> doesn't solve it then possibly the VFAT meta-data doesn't get written to
>> disk in the absence of any pressure.
>> 
>> So instead I'd suggest resurrecting Petr's original patch or at least
>> his approach. If we merge that and still see failures then maybe it's
>> worth investigating more with tracing/debugging.
>
> I do not think the original patch [1] is the correct solution in light
> of the further investigation that has happened after it was proposed.
>
> [2] is about the clearest explaination I can come up with, other than
> the patch description and comments added in the v2 patch [3].  I am of
> the opinion that to be useful these tests need to explicitly make sure
> they are not just writing data that can be de-duplicated.  I do not
> believe the the intent of these tests was to have the only data
> managed by the disk a very small amount of file-system metadata.
>
> Sorry to sound like a broken record, but I spent some time
> investigating the paths taken with [2] and confirming the stats that
> were coming out were not due to some kernel issue, but it really was
> that the backing area had no pages allocated to it at all.
>
> Looping on a sync might make the test pass in more cases, but I hope
> we can agree the idea is to make the test better, not just pass so we
> can continue to ignore it.

We don't want to remove coverage of ZRAM_SAME! A bug in ZRAM_SAME is a
potential expoit or data-corruption.

If you want to change the test you have to show where ZRAM_SAME is being
covered instead.

It's not that I think ZRAM_SAME is any more or less important than the
true compression path. It's that if we never allow coverage to be
swapped out or removed, then we systematically increase coverage.

>
> -i
>
> [1] https://lore.kernel.org/linux-block/20221107191136.18048-2-pvorel@suse.cz/
> [2] https://lore.kernel.org/linux-block/ZNB2kORYiKdl3vSq@fedora19.localdomain/
> [3] https://lore.kernel.org/ltp/ZPpOuK9lyWr2wZWI@fedora19.localdomain/T/#m1e037003252012ac115e57285a926db77380897f


-- 
Thank you,
Richard.