From: Andrew Morton <akpm@linux-foundation.org>
To: CaoRuichuang <create0818@163.com>
Cc: david@kernel.org, ljs@kernel.org, Liam.Howlett@oracle.com,
vbabka@kernel.org, rppt@kernel.org, surenb@google.com,
mhocko@suse.com, shuah@kernel.org, linux-mm@kvack.org,
linux-kselftest@vger.kernel.org, linux-kernel@vger.kernel.org,
Mina Almasry <almasrymina@google.com>
Subject: Re: [PATCH] selftests: mm: capture write_hugetlb_memory.sh exit status
Date: Sun, 5 Apr 2026 13:20:57 -0700 [thread overview]
Message-ID: <20260405132057.c1ae7267911c5657cd5a3fe9@linux-foundation.org> (raw)
In-Reply-To: <20260405194623.84218-1-create0818@163.com>
On Mon, 6 Apr 2026 03:46:23 +0800 CaoRuichuang <create0818@163.com> wrote:
Please word-wrap your emails!
I fixed it.
> charge_reserved_hugetlb.sh backgrounds write_hugetlb_memory.sh and
> immediately stores $? in write_result.
Yes.
> That only records whether the background job was started successfully,
> not whether write_hugetlb_memory.sh itself later failed. As a result,
> the test can miss reservation failure and OOM-kill outcomes that are
> inferred from the writer exit status.
Seems that way.
> Redirect the writer output straight to the temporary log file and wait
> for the background process before inspecting write_result, so the test
> records the actual exit status.
Looks good to me.
It appears that this code is from 2020.
Question is, will this change break the selftests because it discovers
previously undiscovered failures!
> index 447769657..2f52ad7c8 100755
> --- a/tools/testing/selftests/mm/charge_reserved_hugetlb.sh
> +++ b/tools/testing/selftests/mm/charge_reserved_hugetlb.sh
> @@ -193,9 +193,9 @@ function write_hugetlbfs_and_get_usage() {
> [[ "$private" == "-r" ]] && [[ "$expect_failure" != 1 ]]; then
>
> bash write_hugetlb_memory.sh "$size" "$populate" "$write" \
> - "$cgroup" "$path" "$method" "$private" "-l" "$reserve" 2>&1 | tee $output &
> + "$cgroup" "$path" "$method" "$private" "-l" "$reserve" \
> + >"$output" 2>&1 &
>
> - local write_result=$?
> local write_pid=$!
>
> until grep -q -i "DONE" $output; do
> @@ -223,6 +223,8 @@ function write_hugetlbfs_and_get_usage() {
> sleep 0.5
> fi
>
> + wait "$write_pid"
> + local write_result=$?
> echo write_result is $write_result
> else
> bash write_hugetlb_memory.sh "$size" "$populate" "$write" \
Do we actually need to play these backgrounding games? We run
write_hugetlb_memory.sh then synchronously wait for it, polling its
output. Why don't we simply run write_hugetlb_memory.sh synchronously?
Do away with that grep loop and the replaying of
write_hugetlb_memory.sh's output.
The 29750f71a9b4c changelog doesn't explain why it's done this way.
Maybe Mina recalls?
Thanks, I'll set this aside for consideration after -rc1. I expect a
cc:stable will be wanted.
next prev parent reply other threads:[~2026-04-05 20:21 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-04-05 19:46 CaoRuichuang
2026-04-05 20:20 ` Andrew Morton [this message]
2026-04-05 21:35 ` CaoRuichuang
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=20260405132057.c1ae7267911c5657cd5a3fe9@linux-foundation.org \
--to=akpm@linux-foundation.org \
--cc=Liam.Howlett@oracle.com \
--cc=almasrymina@google.com \
--cc=create0818@163.com \
--cc=david@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-kselftest@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=ljs@kernel.org \
--cc=mhocko@suse.com \
--cc=rppt@kernel.org \
--cc=shuah@kernel.org \
--cc=surenb@google.com \
--cc=vbabka@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