From: Tang Yizhou <tangyeechou@gmail.com>
To: Tang Yizhou <yizhou.tang@shopee.com>,
Martin Doucha <mdoucha@suse.cz>, Cyril Hrubis <chrubis@suse.cz>
Cc: Vlastimil Babka <vbabka@kernel.org>, ltp@lists.linux.it
Subject: Re: [LTP] [PATCH v2] perf_event_open03: Track SUnreclaim growth instead of MemAvailable
Date: Tue, 28 Jul 2026 12:00:45 +0800 [thread overview]
Message-ID: <44dc40d3-c0a5-4ed5-bd9f-9911df65cd1f@gmail.com> (raw)
In-Reply-To: <20260722054125.197919-1-yizhou.tang@shopee.com>
On 22/7/26 1:41 pm, Tang Yizhou via ltp wrote:
> From: Tang Yizhou <yizhou.tang@shopee.com>
>
> CVE-2020-25704 leaks a small kmalloc() allocation (the filter's file
> name string) on every failed PERF_EVENT_IOC_SET_FILTER call. The test
> detected this by watching MemAvailable in /proc/meminfo drop by more
> than 100MB over 12M iterations.
>
> MemAvailable is a global, system-wide estimate. It is heavily influenced
> by other memory activities of unrelated processes. This produces
> intermittent false positives: the test passes when run alone but
> occasionally fails when run with other tasks.
>
> An improvement is to track the growth of SUnreclaim instead. It is less
> sensitive to other kinds of memory activities.
>
> Also note in the failure output that unreclaimable slab can still grow
> due to unrelated slab activities, so a failure should be confirmed on an
> idle system or with kmemleak before being treated as a regression.
>
> Reviewed-by: Vlastimil Babka (SUSE) <vbabka@kernel.org>
> Reviewed-by: Cyril Hrubis <chrubis@suse.cz>
> Signed-off-by: Tang Yizhou <yizhou.tang@shopee.com>
> ---
> v2:
> Take Vlastimil and Cyril's reviewed-by tag.
> Update the printed error message.
>
> .../perf_event_open/perf_event_open03.c | 30 +++++++++++--------
> 1 file changed, 18 insertions(+), 12 deletions(-)
>
> diff --git a/testcases/kernel/syscalls/perf_event_open/perf_event_open03.c b/testcases/kernel/syscalls/perf_event_open/perf_event_open03.c
> index 389cc35111b4..a4ce6eaffc02 100644
> --- a/testcases/kernel/syscalls/perf_event_open/perf_event_open03.c
> +++ b/testcases/kernel/syscalls/perf_event_open/perf_event_open03.c
> @@ -77,13 +77,13 @@ static void check_progress(int i)
>
> static void run(void)
> {
> - long diff, diff_total, mem_avail, mem_avail_prev;
> + long diff, diff_total, slab, slab_prev;
> int i, sample;
>
> sample = 0;
> diff_total = 0;
>
> - mem_avail_prev = SAFE_READ_MEMINFO("MemAvailable:");
> + slab_prev = SAFE_READ_MEMINFO("SUnreclaim:");
> tst_timer_start(CLOCK_MONOTONIC);
>
> /* leak about 100MB of RAM */
> @@ -92,28 +92,34 @@ static void run(void)
> check_progress(i);
>
> /*
> - * Every 1200000 iterations, calculate the difference in memory
> - * availability. If the difference is greater than 20 * 1024 (20MB),
> - * increment the sample counter and log the event.
> + * Every 1200000 iterations, calculate how much the unreclaimable
> + * slab has grown. If the increase is greater than 20 * 1024
> + * (20MB), increment the sample counter and log the event.
> */
> if ((i % 1200000) == 0) {
> - mem_avail = SAFE_READ_MEMINFO("MemAvailable:");
> - diff = mem_avail_prev - mem_avail;
> + slab = SAFE_READ_MEMINFO("SUnreclaim:");
> + diff = slab - slab_prev;
> diff_total += diff;
>
> if (diff > 20 * 1024) {
> sample++;
> - tst_res(TINFO, "MemAvailable decreased by %ld kB at iteration %d", diff, i);
> + tst_res(TINFO, "SUnreclaim increased by %ld kB at iteration %d", diff, i);
> }
>
> - mem_avail_prev = mem_avail;
> + slab_prev = slab;
> }
> }
>
> - if ((sample > 5) || (diff_total > 100 * 1024))
> - tst_res(TFAIL, "Likely kernel memory leak detected, total decrease: %ld kB", diff_total);
> - else
> + if ((sample > 5) || (diff_total > 100 * 1024)) {
> + tst_res(TFAIL,
> + "Likely kernel memory leak detected, SUnreclaim increased by %ld kB total",
> + diff_total);
> + tst_res(TINFO,
> + "Unreclaimable slab can also grow due to unrelated reasons as well. "
> + "You can rerun the test with CONFIG_DEBUG_KMEMLEAK to make sure the leak is real");
> + } else {
> tst_res(TPASS, "No memory leak found");
> + }
> }
>
> static void cleanup(void)
Gentle ping.
--
Best Regards,
Yi
--
Mailing list info: https://lists.linux.it/listinfo/ltp
next prev parent reply other threads:[~2026-07-28 4:01 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-07-22 5:41 [LTP] [PATCH v2] perf_event_open03: Track SUnreclaim growth instead of MemAvailable Tang Yizhou via ltp
2026-07-22 5:55 ` [LTP] " linuxtestproject.agent
2026-07-28 4:00 ` Tang Yizhou [this message]
2026-07-31 18:15 ` [LTP] [PATCH v2] " Tang Yizhou
2026-08-03 7:54 ` Cyril Hrubis
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=44dc40d3-c0a5-4ed5-bd9f-9911df65cd1f@gmail.com \
--to=tangyeechou@gmail.com \
--cc=chrubis@suse.cz \
--cc=ltp@lists.linux.it \
--cc=mdoucha@suse.cz \
--cc=vbabka@kernel.org \
--cc=yizhou.tang@shopee.com \
/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