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 E1756C02194 for ; Thu, 6 Feb 2025 18:11:37 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 75069280003; Thu, 6 Feb 2025 13:11:37 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 6D9B0280001; Thu, 6 Feb 2025 13:11:37 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 55342280003; Thu, 6 Feb 2025 13:11:37 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0016.hostedemail.com [216.40.44.16]) by kanga.kvack.org (Postfix) with ESMTP id 34CB8280001 for ; Thu, 6 Feb 2025 13:11:37 -0500 (EST) Received: from smtpin29.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay02.hostedemail.com (Postfix) with ESMTP id CFFB6121453 for ; Thu, 6 Feb 2025 18:11:36 +0000 (UTC) X-FDA: 83090312592.29.2BD4B27 Received: from mail-pj1-f43.google.com (mail-pj1-f43.google.com [209.85.216.43]) by imf11.hostedemail.com (Postfix) with ESMTP id B651C4001A for ; Thu, 6 Feb 2025 18:11:34 +0000 (UTC) Authentication-Results: imf11.hostedemail.com; dkim=pass header.d=purestorage.com header.s=google2022 header.b=M+CKO3dI; spf=pass (imf11.hostedemail.com: domain of joern@purestorage.com designates 209.85.216.43 as permitted sender) smtp.mailfrom=joern@purestorage.com; dmarc=pass (policy=reject) header.from=purestorage.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1738865494; 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=4syKEbMTyi1YxgRmoVCTrUtPofOHembQnaDkGI7tyig=; b=yHVqMVnqsAKhFWbm1eA7gTtWNa/xknh4D99Vh6h+nuNuAh2B7qbnA5PNqPNRM4WKAkKXQU WM+4R76ohCaBP8eH7mbCUcOrftM55vc+4+YTbgE6I+KKrQ3akmmaJDsWp3ib3uBRyxhMjq G/rcW9Yj7FKEXXNZajqf4Y+PiXtcodM= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1738865494; a=rsa-sha256; cv=none; b=SYOOj3RJOBByS3OEV0G25cGjyeChWZot5RFLma4RNe5dweWqXYrsW3XgvHnTHn7abwp7pe 0O3fLUGKqAHr7LZHqpYP8eXT59Zheqi9rFmZjkC924BUP3MTUs8rJkjUHw/tm7qWQFgiDW SIP7bsBXn8TtlrZ4WV0JVxfMYA3xuK8= ARC-Authentication-Results: i=1; imf11.hostedemail.com; dkim=pass header.d=purestorage.com header.s=google2022 header.b=M+CKO3dI; spf=pass (imf11.hostedemail.com: domain of joern@purestorage.com designates 209.85.216.43 as permitted sender) smtp.mailfrom=joern@purestorage.com; dmarc=pass (policy=reject) header.from=purestorage.com Received: by mail-pj1-f43.google.com with SMTP id 98e67ed59e1d1-2fa21145217so346442a91.3 for ; Thu, 06 Feb 2025 10:11:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=purestorage.com; s=google2022; t=1738865493; x=1739470293; darn=kvack.org; h=in-reply-to:content-transfer-encoding:content-disposition :mime-version:references:message-id:subject:cc:to:from:date:from:to :cc:subject:date:message-id:reply-to; bh=4syKEbMTyi1YxgRmoVCTrUtPofOHembQnaDkGI7tyig=; b=M+CKO3dI70MgZK3APG3affxhGhDfyIMrcp90B4DSlQf/Mz2RcgPcEKVF7WebEwDpmk ysfeqPHuS3bTWz6I+esqg2O+h4uQw4r+LpUQL+SA8FoFFNupp718dyqcj7/j1Svxqb/K gtPHmgarnk8ym9Di282pUBJYDdosmExO7MtJEIO/wp7TDwBOU3zXXfRXr/dB998xx9ZV pW5CKvDOOhDKejtC2h6pvjX0jj/t+INNWKEkl4hp+6Nbt576/ruUnBPaNy2PLeTqRqZP l2lQcGjFyOwM03fs20MAUxv9nh9aHjRj6HESCNx+DCB4Os5iVANx8eukyTv14KuPi3Fd B38Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1738865493; x=1739470293; h=in-reply-to:content-transfer-encoding:content-disposition :mime-version:references:message-id:subject:cc:to:from:date :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=4syKEbMTyi1YxgRmoVCTrUtPofOHembQnaDkGI7tyig=; b=tGLdpOCURoMK4abGst1m7Nduki00lxH/rGAi1l4LUo1GNN/pToiYAbGxkt29MMSt71 DiPU4Y3jVOeLRq23pgwHfikg3p92wE8eJFHszlLHPrHHQo3DYGFgMlTIq2p+7OXH0L13 foVxrLhqbd51r/pdAntjoOcTCJRnt5p6eK8zwJO0KiDoAU4nax69p70ZGPD8P6kWd0bN 0KZlAZc6jslMRjx7REQUTKqO17YlgwhoR2kcjTA3g+SQBuY9bpuGlT4ZNEG7kROcNNkt 3OodxeCtVb7OowKiCXYqJP7+V53qLq5Zh3LVa8jacjXUPRsYZEqQwlhBBZGchRmaqY1k BU1A== X-Forwarded-Encrypted: i=1; AJvYcCUx2Cw2PQ1lTvlcBKPNrDID5HfixGmJnO9dM8OGpo7IMpDrdYe9ISNovKSMRwQIi/rl4YdDHSHsdw==@kvack.org X-Gm-Message-State: AOJu0YwICcKloZpU3JdnYyoKMxzm79iIIk3X8roYtvK5HziB/mbUAVGm CiR3l2gDetCC5rK6LLzoFPcolbbr2qc3Q88BFOfTHie9ub5CLb7eDk/0okNN2Dc= X-Gm-Gg: ASbGncuQtqH04qdbbq68aE1RyCHbbsQzzlLc58hhCy54fFejb/XURyyI7gkzCpnK40j fIVrndhO1SfxkkkP2+ZI0CLdGzbV25y6Pbu/rsPICaR40qffGqmmnx2T3YRRyMnD0uP3xK8KA3O x4r4Y4fJet7CB/lwrrobeCo8qtBu3ECD2yHVuUGNe7f1jvRmdDlyVUwHBMWy/PocnGcrdDfHdMC Icd8wl/pWHz0Ysyskh07iAUee/AZ1KlQYPMqouQSnryKoDcsTcqmuxPlockAfDDl8wFM+LONKVO o6FRlL5BBe9DLyldBYsMxv7YH+N5/Lg06U2C+aCAUA== X-Google-Smtp-Source: AGHT+IFfEzzxgHuDIF4upeoV9jC9CpWXIlbUVKa+m+FuGgNenyXOaKzW0C7mHkSHB67pvYyKdl4klw== X-Received: by 2002:a17:90b:4a8e:b0:2ea:4c8d:c7a2 with SMTP id 98e67ed59e1d1-2f9e0811dd3mr13087954a91.24.1738865493507; Thu, 06 Feb 2025 10:11:33 -0800 (PST) Received: from cork (c-73-158-249-15.hsd1.ca.comcast.net. [73.158.249.15]) by smtp.gmail.com with ESMTPSA id d9443c01a7336-21f368b4fcasm15839405ad.230.2025.02.06.10.11.32 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 06 Feb 2025 10:11:32 -0800 (PST) Date: Thu, 6 Feb 2025 10:11:30 -0800 From: =?iso-8859-1?Q?J=F6rn?= Engel To: Oscar Salvador Cc: Uday Shankar , Muchun Song , Andrew Morton , 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=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: X-Rspam-User: X-Rspamd-Queue-Id: B651C4001A X-Rspamd-Server: rspam07 X-Stat-Signature: if6egf5dnubaicexn5y516uetpkxe833 X-HE-Tag: 1738865494-126002 X-HE-Meta: U2FsdGVkX193+H3l1JosC4MpUNgBlmALP9Er1gBBF5PN6cwZL9xJUdw47bfuUb3ULtSiFtsZd3nPnuFE/MGs66ck6FjMkhm5Rdvz+Ea6pBJKwq3DNbFRO/xzNMkdi9LfHNBgAIHmgUPLbL5ergoFK8AWJx7SB5XoyndYzI8zfUjrPZR/8ekFRsGTdhdqa3VFehLsFDiUonmb+vBZndwYj/LvuKlnhK3AoM4g6coWoQF8yj2vorEZAtHs8bCVuw51A8F91HXTPvGmZgex93HT71FKIHiYH+XEWlBPaGz8ed/AhT6YyBI1bDMItA22hdLuIJJQF3jxh9EFhBFsJ0qIiV3qbQicuGZAnHKgvUgvWX83qdbi21RpH2Gr1SGqeidjo/QM+OPtgYDLnrvQdQxivPsopFe+19YUATQo9Q07LxBvL8Q/UBQrxIMB+0+AOD2eDzH4nH/bnYNrwTmC4CM3ZT56vjIeIaVGvZ5YU2feemi8MMgYEGGFGJMUtmZFSMa0cjg8LYn0L1my6ax7R8I+9pPt/0WWoSzpTdKhu6LptVsaI2Br1T/3C8tY216EVkPrvQML8GUXwJPzBYzrSGkenZrMkudM0sTrtV0DurGwfS3IaISeSPhbOJrFELiF9ksJJ7yx9OfxpD/ff+CyehXaG5xfQfFPRbBKzb1NyIbp7Tmj0ncTbuMHhqvyW4qmUrnYcPs+bZYnEkHN1cbHYYSgvMvMm4nQglW3B40Lbz0ka6lYd/sO9oaIdYgBiZ147HqL0X43vj6vKSk/ohdaeWEddrR9rR5N7CYV2yoV+Li242zfJ6ZW9aXSMTDnUc9SmZeZweWrcvUsZS1sdr0RAndWt1lx8pYhX3QycOSJ4phPu8XW+N/OZawxKxVo3IWLdjsbcugIAZIkJnpI2sg/IDaxBlT9A52Q6v+LZyYvRkce6HIEzqbVk0PFQeJ5xOaQ7fNHfYxoc5aoNksX03E0y4Y G6kSQH6Q 5enoZ5SjhNFgcem6AOh1hzTfhN4THOndBBnDYdA7NBE9D2UQwHYook5LG0ab2vHRwb5bs0311d4igjr2PBS0UPipyaWEnRyggtL/j4CHsG5qIWW5PLjia+J9AyZOhaPGnGbAm+X6s88Lw157HwQr5VOLG0JWiKJVqSU5rKiriNBG2XuDda5o8r87TKg9L/A/HTJwIMiaAtO7jozehfafUvQQBkICBH+4Z008Cda3wMPglF6iNj+USApM93RvW2VrS9OQWi8O01FRFi0/cvwKJbddX23afmtzsy2jCF1/PRDnoZVNks6JOa1FjW6v5ruZngQ6Hjbvqzz2lCu3ScqU5bheYkYvunLTJZTV2c8NBXIwlKUDAFF+TL7kMh80QNkifd0qOqn4xp3FdN5z9RfVVOPs0//zvo7WdRWmvb0djX9PoqjnlSFF6FtIPP/bW724G1y98GYQN9o1aOqW1NPMQJq1adro9m65I3CJD X-Bogosity: Ham, tests=bogofilter, spamicity=0.172845, 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 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. -- Gene Kranz