From owner-freebsd-hackers@freebsd.org Fri Oct 16 10:11:53 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 4060742F7BE for ; Fri, 16 Oct 2020 10:11:53 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4CCMQ00145z4jXs for ; Fri, 16 Oct 2020 10:11:51 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from tom.home (kib@localhost [127.0.0.1]) by kib.kiev.ua (8.16.1/8.16.1) with ESMTPS id 09GABiEi016641 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Fri, 16 Oct 2020 13:11:47 +0300 (EEST) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua 09GABiEi016641 Received: (from kostik@localhost) by tom.home (8.16.1/8.16.1/Submit) id 09GABiGk016640; Fri, 16 Oct 2020 13:11:44 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Fri, 16 Oct 2020 13:11:44 +0300 From: Konstantin Belousov To: karnajit wangkhem Cc: Paul Floyd , FreeBSD Hackers Subject: Re: Extra memory mapping seen on freebsd-12 which was not seen in freebsd-11 Message-ID: <20201016101144.GS2643@kib.kiev.ua> References: <9CCF59F6-06F2-4352-94E5-C508E165D0C2@wanadoo.fr> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Spam-Status: No, score=-1.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FORGED_GMAIL_RCVD,FREEMAIL_FROM, NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on tom.home X-Rspamd-Queue-Id: 4CCMQ00145z4jXs X-Spamd-Bar: + Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=fail reason="No valid SPF, No valid DKIM" header.from=gmail.com (policy=none); spf=softfail (mx1.freebsd.org: 2001:470:d5e7:1::1 is neither permitted nor denied by domain of kostikbel@gmail.com) smtp.mailfrom=kostikbel@gmail.com X-Spamd-Result: default: False [1.09 / 15.00]; ARC_NA(0.00)[]; FREEMAIL_ENVFROM(0.00)[gmail.com]; DMARC_POLICY_SOFTFAIL(0.10)[gmail.com : No valid SPF, No valid DKIM,none]; RCVD_TLS_ALL(0.00)[]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; FREEMAIL_FROM(0.00)[gmail.com]; NEURAL_SPAM_SHORT(0.16)[0.163]; MIME_GOOD(-0.10)[text/plain]; HAS_XAW(0.00)[]; R_SPF_SOFTFAIL(0.00)[~all:c]; NEURAL_SPAM_MEDIUM(0.50)[0.500]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; NEURAL_SPAM_LONG(0.43)[0.429]; FREEMAIL_TO(0.00)[gmail.com]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:6939, ipnet:2001:470::/32, country:US]; FREEMAIL_CC(0.00)[wanadoo.fr,freebsd.org]; MAILMAN_DEST(0.00)[freebsd-hackers]; RCVD_COUNT_TWO(0.00)[2] 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 10:11:53 -0000 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 > #include > #include > #include > > 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.