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>