linux-kernel - Re: [PATCH v3 5/5] KVM: selftests: access_tracking_perf

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <aAwpWwMIJEjtL5F9@google.com>
Date: Fri, 25 Apr 2025 17:31:23 -0700
From: Sean Christopherson <seanjc@...gle.com>
To: James Houghton <jthoughton@...gle.com>
Cc: kvm@...r.kernel.org, Maxim Levitsky <mlevitsk@...hat.com>, 
	Axel Rasmussen <axelrasmussen@...gle.com>, Tejun Heo <tj@...nel.org>, 
	Johannes Weiner <hannes@...xchg.org>, mkoutny@...e.com, Yosry Ahmed <yosry.ahmed@...ux.dev>, 
	Yu Zhao <yuzhao@...gle.com>, David Matlack <dmatlack@...gle.com>, cgroups@...r.kernel.org, 
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH v3 5/5] KVM: selftests: access_tracking_perf_test: Use
 MGLRU for access tracking

On Mon, Apr 14, 2025, James Houghton wrote:
> By using MGLRU's debugfs for invoking test_young() and clear_young(), we
> avoid page_idle's incompatibility with MGLRU, and we can mark pages as
> idle (clear_young()) much faster.
> 
> The ability to use page_idle is left in, as it is useful for kernels
> that do not have MGLRU built in. If MGLRU is enabled but is not usable
> (e.g. we can't access the debugfs mount), the test will fail, as
> page_idle is not compatible with MGLRU.
> 
> cgroup utility functions have been borrowed so that, when running with
> MGLRU, we can create a memcg in which to run our test.
> 
> Other MGLRU-debugfs-specific parsing code has been added to
> lru_gen_util.{c,h}.

This fails on my end due to not being able to find the cgroup.  I spent about 15
minutes poking at it and gave it.  FWIW, this is on our devrez hosts, so it's
presumably similar hardware to what you tested on.

Even if this turns out to be PEBKAC or some CONFIG_XXX incompatibility, there
needs to be better hints provided to the user of how they can some this.

And this would be a perfect opportunity to clean up this:

 	__TEST_REQUIRE(page_idle_fd >= 0,
		       "CONFIG_IDLE_PAGE_TRACKING is not enabled");

I can't count the number of times I've forgotten to run the test with root
privileges, and wasted a bunch of time remembering it's not that the kernel
doesn't have CONFIG_IDLE_PAGE_TRACKING, but that /sys/kernel/mm/page_idle/bitmap
isn't accessible.

I mention that, because on a kernel with MGRLU available but disabled, and
CONFIG_IDLE_PAGE_TRACKING=n, the user has no idea that they _can_ run the test
without mucking with their kernel.

==== Test Assertion Failure ====
  lib/lru_gen_util.c:229: stats->memcg_id > 0
  pid=423298 tid=423298 errno=2 - No such file or directory
     1	0x0000000000408b45: lru_gen_read_memcg_stats at lru_gen_util.c:229
     2	0x0000000000402e4c: run_test at access_tracking_perf_test.c:421
     3	0x0000000000403694: for_each_guest_mode at guest_modes.c:96
     4	0x00000000004023dd: run_test_in_cg at access_tracking_perf_test.c:467
     5	0x000000000041ba65: cg_run at cgroup_util.c:362
     6	0x0000000000402042: main at access_tracking_perf_test.c:583
     7	0x000000000041c753: __libc_start_call_main at libc-start.o:?
     8	0x000000000041e9ac: __libc_start_main_impl at ??:?
     9	0x0000000000402280: _start at ??:?
  Couldn't find memcg: access_tracking_perf_test
Did the memcg get created in the proper mount?
Destroying cgroup: /sys/fs/cgroup/access_tracking_perf_test