On Wed, 2 Sep 2026 12:45:20 -0700 Joshua Hahn <[email protected]> wrote:
> The test_no_invasive_cgroup_shrink selftest checks that when a cgroup
> has zswapped out more memory than memory.zswap.max, it does not
> trigger writeback for other cgroups. To do this, it compares the
> writeback count in a control cgroup and makes sure that it is 0,
> and then checks the writeback count in an aggressor cgroup who does
> expect to see writeback.
>
> However, when the zswap shrinker is enabled, the victim cgroup can see
> legitimate writebacks not triggered by the aggressor. In some Meta CI
> tests, we have seen this failure mode happen.
>
> Instead of checking that the victim cgroup has 0 writeback, compare the
> writeback values before and after the aggressor runs and check that
> the victim cgroup did not perform any additional writeback. Note that
> this can still lead to probabilistic failures if writebacks take longer
> than 5 seconds, but this should fix the systematic failure case.
>
> Fixes: b5ba474f3f51 ("zswap: shrink zswap pool based on memory pressure")
Thanks.
I do support backporting selftests fixes. We want selftests to work
well in the kernel with which they are shipped. But, as ever, we
should include a clear explanation of the userspace-visible runtime
effects of the bug.
Seems the short answer is "false-positive test failures" but we can
perhaps do a little better than that. Quoting the failure messages
would be a good way - very recognizable.
> Reported-by: Krush Chavan <[email protected]>
Relatedly, is there a Link:/Closes:?
