Date: Sat, 17 Oct 2020 09:51:16 +0530 From: karnajit wangkhem <karnajitw@gmail.com> To: Konstantin Belousov <kostikbel@gmail.com> Cc: Paul Floyd <pjfloyd@wanadoo.fr>, FreeBSD Hackers <freebsd-hackers@freebsd.org> Subject: Re: Extra memory mapping seen on freebsd-12 which was not seen in freebsd-11 Message-ID: <CAB6rxaQUPCFOPsFhZJA=CzBs9bgNS8emqzt2ptYgEzcxURrAbQ@mail.gmail.com> In-Reply-To: <20201016101144.GS2643@kib.kiev.ua> References: <CAB6rxaSNSoCywTy6tx6w%2B%2B-aJhQHb3FJiHoRL0vXs2CJAHe1OA@mail.gmail.com> <9CCF59F6-06F2-4352-94E5-C508E165D0C2@wanadoo.fr> <CAB6rxaRMOpx9eotjuNuUX_Ua3UZ-0KCbFdTSdEwXptjbG1%2BGUA@mail.gmail.com> <20201016101144.GS2643@kib.kiev.ua>
next in thread | previous in thread | raw e-mail | index | archive | help
Thanks for the info. This was exactly my worry.
On one side valgrind should have allowed this mapping and at the same time
the application would be doing wrong. I will keep this in mind.
On Fri, Oct 16, 2020 at 3:41 PM Konstantin Belousov <kostikbel@gmail.com>
wrote:
> On Fri, Oct 16, 2020 at 10:43:32AM +0530, karnajit wangkhem wrote:
> > Thanks for the reply. It helped in my understanding.
> >
> > Below is a sample code
> >
> > #include <stdio.h>
> > #include <string.h>
> > #include <errno.h>
> > #include <sys/mman.h>
> >
> > int main()
> > {
> > char *str = NULL;
> > str = (char *)mmap((void *)0x7fffdfffe000UL, 0x2000, PROT_READ |
> > PROT_WRITE, MAP_FIXED | MAP_ANON, -1, 0);
> > if ((void *)str == (void *)MAP_FAILED) {
> > int err = errno;
> > printf("mmap failed. err (%s)\n", strerror(err));
> > } else {
> > memcpy(str, "Hello World", 12);
> > printf("str = %s\n", str);
> > }
> >
> > return 0;
> > }
> >
> > Now, the below code under valgrind will give
> > - mmap failed. err (Invalid argument)
> >
> > But, if we give control of this segment to the client program
> > with VG_(am_change_ownership_v_to_c), then valgrind allows the client to
> do
> > the following mmap.
> > - str = Hello World
> >
> > And, the resultant procstat result looks like this:
> > 2382 0x7fbfff000 0x7fc001000 rwx 2 2 1 0 -----
> df
> > 2382 0x7fffdfffe000 0x7fffe0000000 rw- 0 0 0 0 -----
> --
> > <<< Client mmap call
> > 2382 0x7fffe0000000 0x7ffffffdf000 --- 0 0 0 0 -----
> --
> > <<< 0x1000 bytes is taken away from the MAP_GUARD area
> > 2382 0x7ffffffdf000 0x7ffffffff000 rw- 1 1 1 0 ---D-
> df
> > 2382 0x7ffffffff000 0x800000000000 r-x 1 1 104 0 -----
> ph
> >
> > So, is it right for the application with or without valgrind to cross the
> > above boundary, If that memory which the application reserved is just for
> > normal application specific use?
>
> You called mmap(2) with MAP_FIXED flag, which means that mmap must destroy
> any mapping existing at the specified address, and create the requested
> mapping instead. This should work as far as the requested range fits into
> the userspace virtual address space, and mapping object provides requested
> permissions.
>
> If valgrind does not emulate that behavior of MAP_FIXED correctly, it is
> valgrind bug.
>
> That said, application trying to mmap something at the guard holding the
> stack grow area is most likely buggy. Old libthr intentionally split main
> thread' stack into stacks of the new threads, but this was changed.
>
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAB6rxaQUPCFOPsFhZJA=CzBs9bgNS8emqzt2ptYgEzcxURrAbQ>