From: "Ville Syrjälä" <ville.syrjala@linux.intel.com>
To: Jake Freeland <jake@technologyfriends.net>
Cc: igt-dev@lists.freedesktop.org, Jake Freeland <jfree@freebsd.org>
Subject: Re: [igt-dev] [PATCH i-g-t] lib/tests/igt_fork.c: Fix error in mmap() flags
Date: Fri, 7 Oct 2022 18:44:07 +0300 [thread overview]
Message-ID: <Y0BJRw9CQ1EK9l/h@intel.com> (raw)
In-Reply-To: <Y0BAFmzQs1faXzN7@intel.com>
On Fri, Oct 07, 2022 at 06:04:54PM +0300, Ville Syrjälä wrote:
> On Fri, Oct 07, 2022 at 09:52:41AM -0500, Jake Freeland wrote:
> > In subtest_leak(), mmap() is called with the flag PROT_WRITE,
> > but no PROT_READ. Later in the function, the mapped memory is
> > read using `children[i]`. In FreeBSD, the lack of PROT_READ
> > causes SIGSEGV. Adding the PROT_READ flag to the mmap() call
> > fixes this.
>
> Isn't it a CPU architecture thing rather than an OS thing?
> Well, I guess it could be both in some cases.
So I was confused by this since x86 only has the present
bit and the r/w bit, and those can't express a write only
page.
The (always trustworthy) interwebs suggest that FreeBSD will
give an entirely unusable "mapping" when you ask for just
PROT_WRITE. Ie. a mapping that you cannot read or write.
Why? Who knows.
So based on that the fault should already happen when we
assign the pids to children[].
Anyways the patch looks correct so
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
>
> >
> > Signed-off-by: Jake Freeland <jfree@freebsd.org>
> > ---
> > lib/tests/igt_fork.c | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/lib/tests/igt_fork.c b/lib/tests/igt_fork.c
> > index d19d0945..d883aba4 100644
> > --- a/lib/tests/igt_fork.c
> > +++ b/lib/tests/igt_fork.c
> > @@ -109,7 +109,7 @@ __noreturn static void igt_fork_timeout_leak(void)
> > __noreturn static void subtest_leak(void)
> > {
> > pid_t *children =
> > - mmap(0, 4096, PROT_WRITE, MAP_SHARED | MAP_ANON, -1, 0);
> > + mmap(0, 4096, PROT_READ | PROT_WRITE, MAP_SHARED | MAP_ANON, -1, 0);
> > const int num_children = 4096 / sizeof(*children);
> >
> > igt_subtest_init(fake_argc, fake_argv);
> > --
> > 2.37.0 (Apple Git-136)
>
> --
> Ville Syrjälä
> Intel
--
Ville Syrjälä
Intel
next prev parent reply other threads:[~2022-10-07 15:44 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-10-07 14:52 [igt-dev] [PATCH i-g-t] lib/tests/igt_fork.c: Fix error in mmap() flags Jake Freeland
2022-10-07 15:04 ` Ville Syrjälä
2022-10-07 15:44 ` Ville Syrjälä [this message]
2022-10-07 15:35 ` [igt-dev] ✗ Fi.CI.BAT: failure for " Patchwork
2022-10-07 19:10 ` Kamil Konieczny
2022-10-09 16:28 ` Vudum, Lakshminarayana
2022-10-07 19:08 ` [igt-dev] [PATCH i-g-t] " Kamil Konieczny
2022-10-07 20:18 ` Jake Freeland
2022-10-09 16:08 ` [igt-dev] ✗ Fi.CI.BAT: failure for " Patchwork
2022-10-09 16:18 ` [igt-dev] ✓ Fi.CI.BAT: success " Patchwork
2022-10-09 17:42 ` [igt-dev] ✓ Fi.CI.IGT: " Patchwork
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=Y0BJRw9CQ1EK9l/h@intel.com \
--to=ville.syrjala@linux.intel.com \
--cc=igt-dev@lists.freedesktop.org \
--cc=jake@technologyfriends.net \
--cc=jfree@freebsd.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.