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 46593C02194 for ; Fri, 7 Feb 2025 10:49:53 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id BAD01280005; Fri, 7 Feb 2025 05:49:52 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id B3576280001; Fri, 7 Feb 2025 05:49:52 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 9AF64280005; Fri, 7 Feb 2025 05:49:52 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0014.hostedemail.com [216.40.44.14]) by kanga.kvack.org (Postfix) with ESMTP id 7AF85280001 for ; Fri, 7 Feb 2025 05:49:52 -0500 (EST) Received: from smtpin23.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay10.hostedemail.com (Postfix) with ESMTP id DF08FC1833 for ; Fri, 7 Feb 2025 10:49:51 +0000 (UTC) X-FDA: 83092828182.23.425EBEA Received: from smtp-out1.suse.de (smtp-out1.suse.de [195.135.223.130]) by imf04.hostedemail.com (Postfix) with ESMTP id 372FC40006 for ; Fri, 7 Feb 2025 10:49:45 +0000 (UTC) Authentication-Results: imf04.hostedemail.com; dkim=pass header.d=suse.cz header.s=susede2_rsa header.b="RI/4XY0k"; dkim=pass header.d=suse.cz header.s=susede2_ed25519 header.b=gOgoWFRx; dkim=pass header.d=suse.cz header.s=susede2_rsa header.b="RI/4XY0k"; dkim=pass header.d=suse.cz header.s=susede2_ed25519 header.b=gOgoWFRx; spf=pass (imf04.hostedemail.com: domain of vbabka@suse.cz designates 195.135.223.130 as permitted sender) smtp.mailfrom=vbabka@suse.cz; dmarc=none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1738925387; 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:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=lN+az3Uf2Akn6EX7bw5lVoS0KdojlAIwisP0zU0Pxow=; b=JyKc6i/HRHamknJC2OLeF5E5GyzM8kpNHzjdVCAg6/g9f8+wMPqb8SjKI49qILIfncAhhN ItiI/d+Y4oWf1HdEkpCv+c5cJjfGokOg5QJE7RkUZet2tY6WeiBaXWWzXLLlecp0ZKyohB tSN7QZNvlkUNcdC+jvjicaz2Jf2KVRE= ARC-Authentication-Results: i=1; imf04.hostedemail.com; dkim=pass header.d=suse.cz header.s=susede2_rsa header.b="RI/4XY0k"; dkim=pass header.d=suse.cz header.s=susede2_ed25519 header.b=gOgoWFRx; dkim=pass header.d=suse.cz header.s=susede2_rsa header.b="RI/4XY0k"; dkim=pass header.d=suse.cz header.s=susede2_ed25519 header.b=gOgoWFRx; spf=pass (imf04.hostedemail.com: domain of vbabka@suse.cz designates 195.135.223.130 as permitted sender) smtp.mailfrom=vbabka@suse.cz; dmarc=none ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1738925387; a=rsa-sha256; cv=none; b=JJlRNDo4OB0NXlqdz3/DkRHRWSJrFz/mDCOhFhX/rqFkobWfY0jX7l+bE6B4EmngmzevyP S3BX7YqNPlzkHTx2zGjCwtb31v0CUS3fQP3jZ+KdORonaYcKYtsz3JH09UmSdJ2NQUrNZ8 F8Wz0Z3dCmtypH2sYsKtDSiHxbbkM4A= 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 68F0521269; Fri, 7 Feb 2025 10:49:44 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.cz; s=susede2_rsa; t=1738925384; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=lN+az3Uf2Akn6EX7bw5lVoS0KdojlAIwisP0zU0Pxow=; b=RI/4XY0kee0Aio4I4LSkkpawxIB9d7PIZD80gtum2yooKI/zzSj8dWE5Our+YYeVjVIkTO 829KNdD7MZwiBY8eHKwo7C3gEpJ9htA+40smWVPQBYi8mS8dZKQlucSTXPDDrvw17O2+t2 Gnwy3wFt2keQmwIJivzq/9bonh31zbQ= DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.cz; s=susede2_ed25519; t=1738925384; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=lN+az3Uf2Akn6EX7bw5lVoS0KdojlAIwisP0zU0Pxow=; b=gOgoWFRxop3KTiGKCO2bjVqZQv01Blrc4TuooBA1QRq+a/TjXBhG09e7c+dw9dHM6ZrZJn ocBieH81PUmSRMCg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.cz; s=susede2_rsa; t=1738925384; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=lN+az3Uf2Akn6EX7bw5lVoS0KdojlAIwisP0zU0Pxow=; b=RI/4XY0kee0Aio4I4LSkkpawxIB9d7PIZD80gtum2yooKI/zzSj8dWE5Our+YYeVjVIkTO 829KNdD7MZwiBY8eHKwo7C3gEpJ9htA+40smWVPQBYi8mS8dZKQlucSTXPDDrvw17O2+t2 Gnwy3wFt2keQmwIJivzq/9bonh31zbQ= DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.cz; s=susede2_ed25519; t=1738925384; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=lN+az3Uf2Akn6EX7bw5lVoS0KdojlAIwisP0zU0Pxow=; b=gOgoWFRxop3KTiGKCO2bjVqZQv01Blrc4TuooBA1QRq+a/TjXBhG09e7c+dw9dHM6ZrZJn ocBieH81PUmSRMCg== 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 55F65139CB; Fri, 7 Feb 2025 10:49:44 +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 qFL5EkjlpWeRdwAAD6G6ig (envelope-from ); Fri, 07 Feb 2025 10:49:44 +0000 Message-ID: Date: Fri, 7 Feb 2025 11:49:43 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [bug report?] unintuitive behavior when mapping over hugepage-backed PROT_NONE regions Content-Language: en-US To: =?UTF-8?Q?J=C3=B6rn_Engel?= , Oscar Salvador , Lorenzo Stoakes Cc: Uday Shankar , Muchun Song , Andrew Morton , linux-mm@kvack.org References: From: Vlastimil Babka In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Rspam-User: X-Rspamd-Server: rspam08 X-Rspamd-Queue-Id: 372FC40006 X-Stat-Signature: ndnp1khtmiaqxctrjwwowt4d45nsy1fr X-HE-Tag: 1738925385-844342 X-HE-Meta: U2FsdGVkX18Ra3C1mcjQrwPbXxfGgsC46Od7Qpx1ONYb9zVWXvPXfWN+wK3yITmIAi00KR3/OrDvIcL7/RWPAHRvI11bBVdJf6DZ3ZheusNB1EPbaFKwIJwqqskDLDkCm/hh9tMtIg2kqGYWqrAPFUJhzB9oPbxQs8MJf4ZYq/kH/+XpRzds0yORbBvCq/vkiYAXXB0Z88/diHuTu4HwHZoQIyuFbA2lPus/9gM/DYmge0Oz0X596+z5RtqLz47FAg8vWfTh6Xucnbb9/WX5RhIBlZ39guZXVbUTTEdSOY8IPWMZUdVV5wJiaWGiwxesToBUFyOfLFfqO+4qLTyhES6GPKI9Id+iyQ70tTDbv/bSA7l6Jm01QT7rkNBrz3M1pQg4vSWqFfWIoBk6M737qnA09dfVDB429KW7RVRDhPSk/E9mIRJOo82ljN5S/w+x7HLgemYSLEVtB0eiV5Ku/4TUSw8En8YgN5NMhNPDMTodAE9990FcBkeSA5A8fPnk1VuL4Aaw+gyRtAgrctUcNAGcxQxVonLheAL8FsRRqSw/Ntgt0Mnw0ro6ljOc3wm7Zdhph0z0n0lDjMciO3fTt23U85OeI12mF4nVgwJoVAnKqXPvUp207nCQz72Wl2w1VXD8sx65o/G8X/LrLxTldhUvA0XBd2t9dJqpB6dfa1gTMhv4Mik3G0gxipLuztaxV5wNM+2eCU8nXnk5nNRwtwo/Lz3/JO01OAydUwbYGABAEB6rDHkHWPYdO9OBw5ZCmKZn0+9F273m31/z0hFtKl3MNeCOTQj19EP97jJJVkohAPpWH/rUYQENyMNTRkQEctd1yl0/JVcx4XO2fdFjB0i3iNvPkh2DVcMnHIyL1eUGZ3amsd6ypNfwokfRfGzJLB/eY5QoAqXoR2fc4lTipAOO4jAtPE3QqMHH83+6/FWlVWM3z77x23Vd4UgJFwCikYVbsMnDzOmuQsh4LZn KBOQJZRH eES23iNGdnBFwZ4hb5Nflhyq/2bEA/xSa1h9E42aKN+Sy4OIoQgzguv5fici+8/cdqC4mf3bE4V3XdOoPPfWKyqSW0Fi6E2ox4993n1+PwDQ/RHvZ8a19JmiEy9iAydk5XTyMeLgonO2XDhwtr7TecAOeiKABnfvmQz3fEAXG5JBa1i9Sv4URzWxvRrj4EsOUux+dfTAZfRLwv8IUEmBcnkwAZn11AIYQFJ0kxvCS5aPsxuyZvI8jxoN/jeaxQlGtT7sOw/O6m50dVeSr7yZKojdFf0OaepvwoubSJtGEnpzQJlzedQA/0IiiITwfjGhXnBJgKmB9rGBZEO3yrg3Q0U0sLdPWmSM6XR9lpZSCkc48VrEuL0iMsp3IlfdhXpg8awDKLM/wTdhc6ZrPyWOHVpE8OQ== X-Bogosity: Ham, tests=bogofilter, spamicity=0.131326, 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 2/6/25 19:11, Jörn Engel wrote: > On Thu, Feb 06, 2025 at 10:01:05AM +0100, Oscar Salvador wrote: >> >> 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. > > The big question (to me at least) is whether the current behavior is > correct or not. I cannot find any documentation to that end, so maybe > this is a new question we have to answer for the first time. So: > > In case of failure, should munmap() change the process address space? > > As a user I would like the answer to be "no". Partially because I was > personally surprised to see a change and surprises often result in bugs. > Partially because the specific change isn't even well-defined. The size > of the unmapped region depends on the kernel configuration, you might > unmap a 2M-aligned chunk or a 1G-aligned chunk. > > Are there contrary opinions out there? Would it ever be useful to have > a failed mmap or munmap make changes to the process address space? > > Jörn > > -- > I don't care what anything was designed to do, > I care about what it can do. Incidentally, a similar thing may apply to existing userspace application that learned to expect the unmap on failure, and if we now fix the kernel to stop doing that, that application might break. However in this case it's probably very unlikely such application exists, so we might try and see if anyone complains... > -- Gene Kranz >