mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Tejun Heo <tj@kernel.org>
To: Wilson Felipe Pereira <wfelipe@google.com>
Cc: "Andrew Morton" <akpm@linux-foundation.org>,
	"Michal Koutný" <mkoutny@suse.com>,
	"Johannes Weiner" <hannes@cmpxchg.org>,
	"Yosry Ahmed" <yosry@kernel.org>, "Nhat Pham" <nphamcs@gmail.com>,
	"Chengming Zhou" <chengming.zhou@linux.dev>,
	"Shuah Khan" <shuah@kernel.org>,
	"Michal Hocko" <mhocko@kernel.org>,
	"Roman Gushchin" <roman.gushchin@linux.dev>,
	"Shakeel Butt" <shakeel.butt@linux.dev>,
	"Muchun Song" <muchun.song@linux.dev>,
	cgroups@vger.kernel.org, linux-mm@kvack.org,
	linux-kselftest@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] selftests/cgroup: convert cg_read_key_*() helpers to s64
Date: Fri, 23 Oct 2026 10:05:11 -1000	[thread overview]
Message-ID: <100602397eadeaae2e3206e1d9aae55e@kernel.org> (raw)
In-Reply-To: <20261022042921.711624-1-wfelipe@google.com>

Hello, Wilson.

The following is a Claude-generated review.

On Thu, Oct 22, 2026 at 04:28:57AM +0000, Wilson Felipe Pereira wrote:
> On 32-bit platforms, cg_read_key_long() relies on atol(), which returns a
> 32-bit signed long. When values in memory.stat or event counters exceed
> 2.14GB (such as on 32-bit systems with large memory), the parsed value
> overflows and wraps into negative numbers, leading to subtle bugs and
> false test failures.

On 32-bit, glibc's atol() saturates at LONG_MAX instead of wrapping:
atol("3000000000") returns 2147483647. Event counters are counts, not
bytes. No test reads a value near 2^31 from its cgroups, so the false
failures are hypothetical. Can the description be updated to match?

cg_read_long() and cg_read_long_fd() still use atol() and return long.
They read memory.current, memory.peak and the swap counters, which the
same reasoning covers.

> - Migrate helper functions (get_cg_wb_count(), get_zswpout(),
>   get_zswap_incomp(), wait_for_writeback(), and cg_check_freezetime())
>   and their callers to s64.

In test_freezer.c, only test_cgfreezer_time_empty() is converted.
test_cgfreezer_time_simple(), _populate(), _migrate(), _parent(),
_child() and _nested() still store cg_check_freezetime() results in
long and print them with %ld. In test_cpu.c, overprovision_validate()
still computes "long delta" from two s64 usage values. A 32-bit build
with -Wshorten-64-to-32 flags all of these.

>     rebased on top of mm-stable to complete the s64 conversion across the
>     cgroup selftests (including updating test_no_kmem_bypass() to s64).

This doesn't apply to mainline. The test_zswap.c hunks depend on the
test_zswap fixes in mm-stable, which aren't in mainline yet. The
tcp_client() hunk in test_memcontrol.c conflicts with eb69e955de7b
("selftests: cgroup: make test_memcg_sock check flushed sock stats"),
which went in through the cgroup tree for v7.4. Can it be rebased on
v7.4-rc1 once that's out?

> +typedef signed long long s64;

This is the main problem. The KVM selftests build libcgroup too:
kvm/Makefile.kvm includes ../cgroup/lib/libcgroup.mk and links
cgroup_util.o into every KVM test, and access_tracking_perf_test.c
includes cgroup_util.h. That build uses -I tools/include, and
tools/include/linux/types.h has "typedef int64_t s64;", which is long
on 64-bit.

cgroup_util.c then fails with "typedef redefinition with different
types ('long long' vs 'int64_t' (aka 'long'))", so none of the KVM
selftests build on 64-bit. Maybe use int64_t with PRId64 from
<inttypes.h> instead of the local typedef and %lld?

> -
>  	ret = KSFT_PASS;

The blank line removal is unrelated to the conversion, same for the one
in test_cpu.c.

> +		ksft_print_msg("debug: zswpout=%lld zswapped=%lld zswap_b=%lld\n",
> +				zswpout, zswapped, zswap_b);

The continuation line was aligned with the opening parenthesis before
and now isn't.

Thanks.

--
tejun

  reply	other threads:[~2026-10-23 20:05 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-10-22  4:28 Wilson Felipe Pereira
2026-10-23 20:05 ` Tejun Heo [this message]
2026-10-24  0:22   ` Wilson Felipe Pereira

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=100602397eadeaae2e3206e1d9aae55e@kernel.org \
    --to=tj@kernel.org \
    --cc=akpm@linux-foundation.org \
    --cc=cgroups@vger.kernel.org \
    --cc=chengming.zhou@linux.dev \
    --cc=hannes@cmpxchg.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-kselftest@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=mhocko@kernel.org \
    --cc=mkoutny@suse.com \
    --cc=muchun.song@linux.dev \
    --cc=nphamcs@gmail.com \
    --cc=roman.gushchin@linux.dev \
    --cc=shakeel.butt@linux.dev \
    --cc=shuah@kernel.org \
    --cc=wfelipe@google.com \
    --cc=yosry@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®