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] [thread-next>] [day] [month] [year] [list]

Message-ID: <CADrL8HX03P1f2E7NzufXU3enW1EXz2Bk2qNh5KQg-X1KFQed8g@mail.gmail.com>
Date: Mon, 28 Apr 2025 15:54:41 -0400
From: James Houghton <jthoughton@...gle.com>
To: Sean Christopherson <seanjc@...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 Fri, Apr 25, 2025 at 8:31 PM Sean Christopherson <seanjc@...gle.com> wrote:
>
> 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.

Ah sorry, yes, this selftest needs to be patched when running the
devrez userspace, which uses a combination of cgroup-v1 and cgroup-v2.
Simply hard-coding the root to "/dev/cgroup/memory" (which is in fact
a cgroup-v1 mount) should be what you need if you want to give it
another go.

> 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.

Yeah this can be better. I should at least check that the found
cgroup-v2 root's cgroup.controllers contains "memory". In your case,
it did not.

(cgroup.controllers is not available for cgroup-v1 -- because it
doesn't make sense -- so if I patch the selftest to check this file,
using cgroup-v1 mounts will stop working. So, again, you'd need to
patch the test to work on devrez.)

> 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 think the change I've already made to this string is sufficient
(happy to change it further if you like):
> > +               __TEST_REQUIRE(page_idle_fd >= 0,
> > +                              "Couldn't open /sys/kernel/mm/page_idle/bitmap. "
> > +                              "Is CONFIG_IDLE_PAGE_TRACKING 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.

Fair enough, I'll change the output from the test for that
configuration to say something like: "please either enable the missing
MGLRU features (e.g. `echo 3 > /sys/kernel/mm/lru_gen/enabled`) or
recompile your kernel with CONFIG_IDLE_PAGE_TRACKING=y."

> ==== 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

Thanks for taking a look!