From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id C3B35C02196 for ; Thu, 6 Feb 2025 09:01:13 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 2D623280005; Thu, 6 Feb 2025 04:01:13 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 2860A280003; Thu, 6 Feb 2025 04:01:13 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 0FFF5280005; Thu, 6 Feb 2025 04:01:13 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0010.hostedemail.com [216.40.44.10]) by kanga.kvack.org (Postfix) with ESMTP id E4848280003 for ; Thu, 6 Feb 2025 04:01:12 -0500 (EST) Received: from smtpin04.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay03.hostedemail.com (Postfix) with ESMTP id 947EAA1018 for ; Thu, 6 Feb 2025 09:01:12 +0000 (UTC) X-FDA: 83088925584.04.0C081A4 Received: from smtp-out1.suse.de (smtp-out1.suse.de [195.135.223.130]) by imf03.hostedemail.com (Postfix) with ESMTP id 496102005B for ; Thu, 6 Feb 2025 09:01:10 +0000 (UTC) Authentication-Results: imf03.hostedemail.com; dkim=pass header.d=suse.de header.s=susede2_rsa header.b=akxPa90s; dkim=pass header.d=suse.de header.s=susede2_ed25519 header.b="ubn/XUFG"; dkim=pass header.d=suse.de header.s=susede2_rsa header.b=i+ThtSoD; dkim=pass header.d=suse.de header.s=susede2_ed25519 header.b="AatJis/S"; spf=pass (imf03.hostedemail.com: domain of osalvador@suse.de designates 195.135.223.130 as permitted sender) smtp.mailfrom=osalvador@suse.de; dmarc=pass (policy=none) header.from=suse.de ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1738832470; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=9ddnodsIDS4rDaqmjQzqug7f7f84/OMZTdy0YY9/bRc=; b=ssgrI25VuYYM43rhXuPEr6dMBIikabaVCpLWiAwZi1xaGWACNfuVjnBRtTfC6xOKpkDtcv GX4z/i0y0xMB+UtMdS2hXeTNZnHrXpwjpwCkFJQHRI4iDzdlICt8feY6jj+QIEgUK6a9gn a2kGU+AAj8c66z5fikD9EmwBsU7m50o= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1738832470; a=rsa-sha256; cv=none; b=T2xxU0AJSLU5HWDcFct9YPeHVqtZmlwUB/sA2mWkAEFmY44k2bw6hDr3cSZhFxrfcO3YN1 9VLc8D1uZjcQ7GnpKrix4T5C8ObEaW6D5KdCnyOeaVnwCt6RqmVPjFwn6VSRhs7dgXvibQ Mp1gJcHs13HGjLB614Een+58L7LqGzc= ARC-Authentication-Results: i=1; imf03.hostedemail.com; dkim=pass header.d=suse.de header.s=susede2_rsa header.b=akxPa90s; dkim=pass header.d=suse.de header.s=susede2_ed25519 header.b="ubn/XUFG"; dkim=pass header.d=suse.de header.s=susede2_rsa header.b=i+ThtSoD; dkim=pass header.d=suse.de header.s=susede2_ed25519 header.b="AatJis/S"; spf=pass (imf03.hostedemail.com: domain of osalvador@suse.de designates 195.135.223.130 as permitted sender) smtp.mailfrom=osalvador@suse.de; dmarc=pass (policy=none) header.from=suse.de Received: from imap1.dmz-prg2.suse.org (unknown [10.150.64.97]) (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) (No client certificate requested) by smtp-out1.suse.de (Postfix) with ESMTPS id 7400D2111F; Thu, 6 Feb 2025 09:01:07 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_rsa; t=1738832468; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=9ddnodsIDS4rDaqmjQzqug7f7f84/OMZTdy0YY9/bRc=; b=akxPa90sTsI7pWLmJ7hrjULQT8dXy+wRwtM8GtrbyzszBvGFTugjsLAM/s2bNDQb5dKxes 08sNyeyCEmrfLPZiMk/e+1sNAT6aE6uCYegssq7vJn4tBt30DHOrR7lkTmtUyc2Doa1Pjw 1mOKNA5hl3Qdny0auVnCiuOaWXRZWO8= DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_ed25519; t=1738832468; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=9ddnodsIDS4rDaqmjQzqug7f7f84/OMZTdy0YY9/bRc=; b=ubn/XUFGbJ7oBH4iEqYkbZkX9pPw1jaTlPT8Brli3OCWGfBpKdZSeF9phlzrATg40pnyKn wE0l+i8OmmN3hoAg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_rsa; t=1738832467; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=9ddnodsIDS4rDaqmjQzqug7f7f84/OMZTdy0YY9/bRc=; b=i+ThtSoD+E7H66JCssbyx5UXPGn1vKdkYOgT9Ukb0oZGvxgMZFeg+rkta8TkrbSHYhP967 gtFpqlVNokLsNMXhSJfBa+6WyTck/FD6a/vIMN9V/PcqXG6xQX1g0sORaxlxA3xBLCX0gd nPo0CEOz2pbEILEZ4x7bGsylP9Q7Htc= DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_ed25519; t=1738832467; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=9ddnodsIDS4rDaqmjQzqug7f7f84/OMZTdy0YY9/bRc=; b=AatJis/SVnOHCSprQ0aLqjFp0ISKHwAUJbIBY6Pou8uPMfCr3q1Jj2LNbIPvUJ2yU4fPay uQ/+ZEoGWl15DiBQ== Received: from imap1.dmz-prg2.suse.org (localhost [127.0.0.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) (No client certificate requested) by imap1.dmz-prg2.suse.org (Postfix) with ESMTPS id 2017A13694; Thu, 6 Feb 2025 09:01:07 +0000 (UTC) Received: from dovecot-director2.suse.de ([2a07:de40:b281:106:10:150:64:167]) by imap1.dmz-prg2.suse.org with ESMTPSA id usy0A1N6pGe6PQAAD6G6ig (envelope-from ); Thu, 06 Feb 2025 09:01:07 +0000 Date: Thu, 6 Feb 2025 10:01:05 +0100 From: Oscar Salvador To: Uday Shankar Cc: Muchun Song , Andrew Morton , Joern Engel , linux-mm@kvack.org Subject: Re: [bug report?] unintuitive behavior when mapping over hugepage-backed PROT_NONE regions Message-ID: References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Stat-Signature: 6pm54ccumj6umrgxo4rechrjuscf6ge1 X-Rspamd-Queue-Id: 496102005B X-Rspam-User: X-Rspamd-Server: rspam06 X-HE-Tag: 1738832470-476877 X-HE-Meta: U2FsdGVkX19Tfk/e5nLLLI1Q4gcMsSQO/+tIWvpqRmGT0/DjWM9BLHN0On7qwonbD17XRuYu75rW2gA3G5UodJov7KiKY80xostAYCtpPKxgnN4Ib0qh4sVN98jv4tSK8L9jtByvNclQ1zntiOkUXSHoKoPrDtPIhOCDi3cAwDi5GufYisGbA/Kn0b4rqLFgCkuruE1TzFDWag8byCnR9kFNsR4PiE+VbBHq5hlBh1hhKom7nmn/5qwSqUtO6/cGkYdeRXQkTeWe7r7TtRNWy6lYM4h03miA5eFnqOTUmwQxcDSxliqQ4mD0Q98kGkO/MswgJ/Yxruf8NJvh3UVmmwJXO5j+IGN9poHEqfAyqw9EovIfBqYZvMahGmjtM2+oYt4mJkwwVmRaA06xX9B/RfBmYDDrYn3tcfTpO/Zi3k8UP61s2EDH7d4D3gQGpFTZwo8nBo7rNz994jmKoR2EeEmRRh5S/GzVuK099kXWuYdI/Cp9bvgAepueraLHp+tA0n8J8kPMz3MoVgkAdIU84Uib+oGLLDA7LaheI9JhQ8o4yZkuUsoDAymvYT68T96tiInXOw4mZfvLVzj97JyKBf67Mj7nZfWC8csE/kQSBJLMmXR188cVg90Q16fN2/DVv/fsMtFh7XSXo98CtA5fKbGcLt88TtZ/Py7pXx/Rypn2AE2N92VZkH5M3MNXqJRPUZpsPL2cfBG6sR9Myg2niTNo1hNgfpl9WXt30ymAwjZSyCL/XK6USl4OqsVqWlhuftV6KGNvqDPpsqRFZ35emsowapg59byPm0BQNKUQXnCWMn8RD3Z5WVKGRAXn7iSaDzS4ej+mdENgp1Rk7Lhx9/3QdEvr+ezUtEM6BAMWA2HVu8Yct8MyGoS5BXbxWZcUjLh4ANl3d1mD1lduYOQQzsg+0RdW4rF/HTZs178r4t6pxYT8gvyymB1ZjmDzAWWkeXYmyHxlD2JaybBzK2I CwSqQS+z ohfGTzvnx5z7TqSAr25s40LGPzeD1T+xWcnFwIB4CPP2jCa1FmYW3vcneHekHa9FpkDdjn0XzLeoeymTtiClQwozFcSLionQm2Qp03uqTYoba0IdRmRTMUDb8ECRBuJe7Y08y7bOlOBes9jjl94W/E/YwmveF+qUtpvN83ITnuKLyb8onMnQqIf5wRX8r9/Ymrz2UHNyycPQd9wcqCC074rkeRINCAx9T1+DCE4NAJ8J5ExU9rvN0eJ3gIwR92sJ5bLjX7FKkgxcxTWZt5j5CNIBZSZk/7EpjTdSXW8tEOL5z+/MpQLcpS3Cq31/ZADgh9uVjXHOw5PIgymLx+qxRXfBqO1654QYNQCyz X-Bogosity: Ham, tests=bogofilter, spamicity=0.002970, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: List-Subscribe: List-Unsubscribe: On Wed, Feb 05, 2025 at 11:18:34PM -0700, Uday Shankar wrote: > I was debugging an issue with a malloc implementation when I noticed > some unintuitive behavior that happens when someone attempts to > overwrite part of a hugepage-backed PROT_NONE mapping with another > mapping. I've isolated the issue and reproduced it with the following > program: ... > First, we map a 2G PROT_NONE region using hugepages. This succeeds. Then > we try to map a 4096-length PROT_READ | PROT_WRITE region at the > beginning of the PROT_NONE region, still using hugepages. This fails, as > expected, because 4096 is much smaller than the hugepage size configured > on the system (this is x86 with a default hugepage size of 2M). The Not really, see how ksys_mmap_pgoff() aligns len to huge_page_size if we set MAP_HUGETLB. It fails with ENOMEM because likely you did not preallocate any hugetlb pages, so by the time we do hugetlbfs_file_mmap()->hugetlb_reserve_pages(), it sees that we do not have enough hugetlb pages in the pool to be reserved, so it bails out. > surprising thing is the difference in /proc/pid/smaps before and after > the failed mmap. Even though the mmap failed, the value in > /proc/pid/smaps changed, with a 2M-sized bite being taken out the front > of the mapping. This feels unintuitive to me, as I'd expect a failed > mmap to have no effect on the virtual memory mappings of the calling > process whatsoever. That is because the above happens after __mmap_prepare(), which is responsible of unmapping any overlapping areas, is executed. I guess this is done this way because rolling back at this point would be quite tricky. -- Oscar Salvador SUSE Labs