On Tue, Sep 01, 2026 at 05:22:28AM +0000, Wilson Felipe Pereira <[email protected]> wrote: > In test_no_kmem_bypass(), delta (stored_pages * page_size - zswapped) is > checked against stored_pages * page_size / 4 to verify that the pages > pushed to zswap belong to the test memory cgroup. > > Due to slight stat update timing differences, delta can evaluate to a small > negative number (e.g. -5MB out of 1GB). Because delta is declared as a > signed int and stored_pages is an unsigned size_t, C's usual arithmetic > conversions implicitly promote a negative delta to a large unsigned 64-bit > integer, causing `delta < stored_pages * page_size / 4` to falsely evaluate > to 0 and fail the test. > > Fix this by declaring zswapped and delta as signed long long and comparing > against a signed threshold, ensuring negative deltas correctly evaluate > to true. > > Fixes: a549f9f31561a ("selftests: cgroup: add test_zswap with no kmem bypass > test") > Signed-off-by: Wilson Felipe Pereira <[email protected]> > Acked-by: Michal Koutný <[email protected]>
(The long long helper is a non-trivial change, so the ack should be
stripped on this version (unless you can convince me ;-).)
I'm afraid this bitness propagated too broadly.
The long vs long long difference is only relevant on 32b, right?
And the bit-width issue only appears because of the product, not the
values read from memory.stat [1].
I'd consider three ways forward:
a) Consolidate the helpers into one cg_read_key_s64() (same explicit size
regardless of arch),
b) keep single arch-dependent helper and tackle product(s) only,
c) do not bother with 32b in these selftests (I have a hunch that
they're not so relevant on such archs).
WDYT?
Michal
[1] At least the values derived from available memory, memory events
could grow indefinitely. It's true that kernel uses explicit u64 for
all of the entries.
signature.asc
Description: PGP signature
