Skip site navigation (1)Skip section navigation (2) 
Date:      Fri, 16 Oct 2020 10:43:32 +0530
From:      karnajit wangkhem <karnajitw@gmail.com>
To:        Paul Floyd <pjfloyd@wanadoo.fr>
Cc:        FreeBSD Hackers <freebsd-hackers@freebsd.org>
Subject:   Re: Extra memory mapping seen on freebsd-12 which was not seen in freebsd-11
Message-ID:  <CAB6rxaRMOpx9eotjuNuUX_Ua3UZ-0KCbFdTSdEwXptjbG1%2BGUA@mail.gmail.com>
In-Reply-To: <9CCF59F6-06F2-4352-94E5-C508E165D0C2@wanadoo.fr>
References:  <CAB6rxaSNSoCywTy6tx6w%2B%2B-aJhQHb3FJiHoRL0vXs2CJAHe1OA@mail.gmail.com> <9CCF59F6-06F2-4352-94E5-C508E165D0C2@wanadoo.fr>
next in thread | previous in thread | raw e-mail | index | archive | help 
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 =3D NULL;
  str =3D (char *)mmap((void *)0x7fffdfffe000UL, 0x2000, PROT_READ |
PROT_WRITE, MAP_FIXED | MAP_ANON, -1, 0);
  if ((void *)str =3D=3D (void *)MAP_FAILED) {
    int err =3D errno;
    printf("mmap failed. err (%s)\n", strerror(err));
  } else {
    memcpy(str, "Hello World", 12);
    printf("str =3D %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 =3D 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?

Regards,
Karan

On Thu, Oct 15, 2020 at 11:56 PM Paul Floyd <pjfloyd@wanadoo.fr> wrote:

>
> > On 15 Oct 2020, at 16:54, karnajit wangkhem <karnajitw@gmail.com> wrote=
:
> >
> > Hi freebsd team,
> >
> > While checking on a valgrind issue, I encountered the following mapping
> of
> > a simple test program on a freebsd-12.
>
> ;-)
>
>
> > [Stable 11]
> >
> > # procstat -v 85507
> >
> >  PID              START                END PRT  RES PRES REF SHD FLAG T=
P
> > PATH
> >
> > <SNIP>
> >
> > 85507        0x800820000        0x800822000 rw-    1    1   1   0 ---- =
df
> > 85507     0x7ffffffdf000     0x7ffffffff000 rw-    1    1   1   0 ---D =
df
> > 85507     0x7ffffffff000     0x800000000000 r-x    1    1 104   0 ---- =
ph
> >
> > There is an extra ~511MB reserved mmap area starting at 0x7fffdffff000 =
in
> > stable 12. Could you please give me an insight of what this is for and =
is
> > it ok for a userspace program to modify this mapping?
> >
> > The reason is that our applications reserve some fixed memory that
> > crosses/modify the above region. As this mapping was not called by the
> > client program, valgrind had taken control of it. So, I have to decide
> > whether to give the control to the client and allow
> modifications(mprotect,
> > unmap, mmap, etc) on this memory segment or logically(not mandatorily) =
a
> > client program should be allowed to modify this area?
>
>
> This extra memory is the MAP_GUARD, which was introduced in FreeBSD 10.4
> and changed to be a large zone in FreeBSD 11.1.
>
> If I understand correctly, it=E2=80=99s a kind of super-sized guard page =
for the
> stack.
> There are more details in the mmap man page.
>
> If you run Valgrind with the -d option it will print a table of the memor=
y
> mapping
> (Prefixed with =E2=80=98aspacem=E2=80=99 for Address Space Manager). If y=
ou want to see
> some
> more Valgrind details, see aspacemgr-linux.c from line 1646 (despite the
> name
> it's used by all supported platforms).
>
> A+
> Paul
>
> _______________________________________________
> freebsd-hackers@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-hackers
> To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org=
"
>

Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAB6rxaRMOpx9eotjuNuUX_Ua3UZ-0KCbFdTSdEwXptjbG1%2BGUA>