From owner-freebsd-hackers@freebsd.org Fri Oct 16 05:13:45 2020 Return-Path: Delivered-To: freebsd-hackers@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 6A1A544FF47 for ; Fri, 16 Oct 2020 05:13:45 +0000 (UTC) (envelope-from karnajitw@gmail.com) Received: from mail-yb1-xb31.google.com (mail-yb1-xb31.google.com [IPv6:2607:f8b0:4864:20::b31]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4CCDp04xd3z4SQj for ; Fri, 16 Oct 2020 05:13:44 +0000 (UTC) (envelope-from karnajitw@gmail.com) Received: by mail-yb1-xb31.google.com with SMTP id a4so881298ybq.13 for ; Thu, 15 Oct 2020 22:13:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=EWnjUFZBthNcaqhIPQ92NS09Fo3nktZIxtZ/wIb6IqY=; b=QERr/Q2iuYNuD8YH1IijtfvOybhYKTYpnavgK9X62ihDUD00Havy3s9wFfU31mdQZn EoLXTes47nBrMmc9C3YYk9LA2CBxoAvNj+VkANAd2XywXFiF37SbqJBllwsf5ErDo4KQ rmOFH+g94ga7LEwHraHp4Hc6VAygXRQhfNWjZ6EXDE0Q0S65QLv6i/L6bR61y8Zy3atT bE9u4ErSw86aWnRz1li2IUtHMr+4HwxSaXN3XvSdFwaZnKbHIVBlPePqS/kpaP9NOJ6m sc+ul6KPta/hLHZsv16Z+/qla4Ad4Bmhy+/xPqfP2S4EVQe3GCUPj4p6R1C9uvwT5lQn vxrg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=EWnjUFZBthNcaqhIPQ92NS09Fo3nktZIxtZ/wIb6IqY=; b=UIruiBiC7WL1AWGDxTemvvCqTttONUKWsiVgcBcLm/5ijyoLysZrWguz5L1bedqcxj PLm/CJtvswwM+z/XR9wWmdBljjoHFRgTOWcZ2L2uKjfdqTjp022LeSYk/z+9SuvmyQ9p C2fCrg4FejYgQDslLIJ4vnlL7dTpLKGHcFDlOP1dtyDKrn4NH44ohuZ7IWRV3GeYbbS2 aWsr/6wsR6B7w655Hq1TIe7rip7QFM0g6Tp5rm1ixchbXBg7UxS+pWl/Rw1ubKnmxUX6 7igsrLzj55xbbf0PGvK3EBMBJZge3byxL421t9dA3by4DLIaE3gfpI005x+/TtV9cSWe 21Ng== X-Gm-Message-State: AOAM531lN/NvXhw7lRwxQdoSi7H6UPmvxjrBKFN4h2mRtd0y1/VkblX+ 5Qre1Ad1EOqZYP08ndfmKiIHmgeiujXd3xVQ/8A= X-Google-Smtp-Source: ABdhPJwwd5j4Sx6IQCLrgPQg3s4b0tALCcGS9MeRHqbqsaUJQTh+3QX34IA0CQtKDKUppsXRj+v4IB4gQSa46KtksCg= X-Received: by 2002:a25:e649:: with SMTP id d70mr2411282ybh.249.1602825223617; Thu, 15 Oct 2020 22:13:43 -0700 (PDT) MIME-Version: 1.0 References: <9CCF59F6-06F2-4352-94E5-C508E165D0C2@wanadoo.fr> In-Reply-To: <9CCF59F6-06F2-4352-94E5-C508E165D0C2@wanadoo.fr> From: karnajit wangkhem Date: Fri, 16 Oct 2020 10:43:32 +0530 Message-ID: Subject: Re: Extra memory mapping seen on freebsd-12 which was not seen in freebsd-11 To: Paul Floyd Cc: FreeBSD Hackers X-Rspamd-Queue-Id: 4CCDp04xd3z4SQj X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20161025 header.b=QERr/Q2i; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of karnajitw@gmail.com designates 2607:f8b0:4864:20::b31 as permitted sender) smtp.mailfrom=karnajitw@gmail.com X-Spamd-Result: default: False [-3.44 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.05)[-1.055]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20161025]; RCVD_TLS_ALL(0.00)[]; FROM_HAS_DN(0.00)[]; R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36:c]; FREEMAIL_FROM(0.00)[gmail.com]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; NEURAL_HAM_LONG(-0.99)[-0.994]; NEURAL_HAM_SHORT(-0.39)[-0.389]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[gmail.com:+]; RCPT_COUNT_TWO(0.00)[2]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::b31:from]; FREEMAIL_TO(0.00)[wanadoo.fr]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; RCVD_COUNT_TWO(0.00)[2]; MAILMAN_DEST(0.00)[freebsd-hackers]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim] Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.33 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Oct 2020 05:13:45 -0000 Thanks for the reply. It helped in my understanding. Below is a sample code #include #include #include #include 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 wrote: > > > On 15 Oct 2020, at 16:54, karnajit wangkhem 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 > > > > > > > > 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= " >