From: Guillaume Morin <guillaume@morinfr.org>
To: Mike Rapoport <rppt@kernel.org>
Cc: Guillaume Morin <guillaume@morinfr.org>,
linux-mm@kvack.org, leitao@debian.org
Subject: Re: [PATCH v2] selftests/mm: hugetlb_madv_vs_map: add underflow test
Date: Mon, 31 Aug 2026 19:38:49 +0200 [thread overview]
Message-ID: <apW8KS4D6k8621Ca@bender.morinfr.org> (raw)
In-Reply-To: <apVC2D11bMz-QHic@kernel.org>
On 31 Aug 12:01, Mike Rapoport wrote:
> > + return;
> > + }
> > +
> > + /* Parent */
> > + close(pipe_fds[0]);
> > +
> > + /* First unmap, this will close the vma */
> > + if (munmap(huge_ptr, mmap_size) != 0) {
> > + kill(pid, SIGKILL);
> > + ksft_exit_fail_msg("munmap failed");
>
> Won't this leave the child as a zombie?
It will, for a brief amount of time then re-parented to init which will
wait(). Happy to add a waitpid() here but I was concerned it added more
complexity for not much benefit (it's very very unlikely munmap will
fail). Let me know.
> > + }
> > + close(pipe_fds[1]);
> > + if (waitpid(pid, NULL, 0) <= 0)
> > + ksft_exit_fail_msg("write failed");
> > +
> > + nr_reserved = hugetlb_nr_resv_pages(default_huge_page_size());
> > + if (nr_reserved == 0) {
> > + ksft_test_result_pass("After the child dies, HugePages_Rsvd is properly set to 0\n");
>
> This makes this count the test as two, right?
Yes, it checks both that there is no underflow but that the count is
restorred as well. is that a problem?
> And do you need to re-check what happens after the child exits if you
> already detected the underflow?
Need is a strong word. It can be done either way really.
>
> > + } else {
> > + ksft_exit_fail_msg("Unexpected HugePages_Rsvd=%ld after the child termination munmap, should be 0 or -1. Repeat the test\n",
> > + nr_reserved);
> > + }
> > +}
> > +
> > +int main(void)
> > +{
> > + ksft_print_header();
> > + ksft_set_plan(3);
>
> The comment at the header implies we've added the second test, so they plan
> should be bumped to 2.
So you're saying that every test function should only fail or pass once?
--
Guillaume Morin <guillaume@morinfr.org>
next prev parent reply other threads:[~2026-08-31 17:38 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-08-28 14:29 [PATCH v2] selftests/mm: hugetlb_madv_vs_map: add underflow test Guillaume Morin
2026-08-31 9:01 ` Mike Rapoport
2026-08-31 17:38 ` Guillaume Morin [this message]
2026-09-01 7:50 ` Mike Rapoport
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=apW8KS4D6k8621Ca@bender.morinfr.org \
--to=guillaume@morinfr.org \
--cc=leitao@debian.org \
--cc=linux-mm@kvack.org \
--cc=rppt@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.