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 81E3EC0219E for ; Sat, 8 Feb 2025 17:37:42 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 8F08D280001; Sat, 8 Feb 2025 12:37:41 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 8A0FE6B0088; Sat, 8 Feb 2025 12:37:41 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 769C1280001; Sat, 8 Feb 2025 12:37:41 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0015.hostedemail.com [216.40.44.15]) by kanga.kvack.org (Postfix) with ESMTP id 5C1766B0083 for ; Sat, 8 Feb 2025 12:37:41 -0500 (EST) Received: from smtpin05.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay07.hostedemail.com (Postfix) with ESMTP id C3131162931 for ; Sat, 8 Feb 2025 17:37:40 +0000 (UTC) X-FDA: 83097484680.05.8718A8C Received: from mail-pl1-f174.google.com (mail-pl1-f174.google.com [209.85.214.174]) by imf28.hostedemail.com (Postfix) with ESMTP id B4C90C0003 for ; Sat, 8 Feb 2025 17:37:38 +0000 (UTC) Authentication-Results: imf28.hostedemail.com; dkim=pass header.d=purestorage.com header.s=google2022 header.b=AfeTMkqT; spf=pass (imf28.hostedemail.com: domain of joern@purestorage.com designates 209.85.214.174 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=1739036258; 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=o13An88DBBiikPRk7tvcchkHZ4UK/KA+EJbR0tV1/hQ=; b=LN5e6xad4O3eSvSeASIhX901T1pj8Uw1Hze7JDTIwQvhv1otcfi3NjriqEIF9+ZEl8/dQG S2v01pPR5MIfetG4Pw3FlW8rGPZSb0gVhQwuiQFMPxHBeLYqoksxvzUMyLbDM/sCzBYtCd Y9S+Yf+6reO5eiDkWdo5ODzG7Z8JCHU= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1739036258; a=rsa-sha256; cv=none; b=jzFHVVsUbj5uqn1pN7hiFGDjpP3N7q67GkKyCMTNQWZEM/UVIpmF2iUeDACXmMT6RoJ5S7 QvzDh48OrNMuiuC1D34opbJC56LgMROHi+iGwB3ml8OKVL0rKz4EWu9Es1+Zg8xNcJ/cDy p5pHJ0iE7f2B2GVsd7lgGEb5qHR9KTo= ARC-Authentication-Results: i=1; imf28.hostedemail.com; dkim=pass header.d=purestorage.com header.s=google2022 header.b=AfeTMkqT; spf=pass (imf28.hostedemail.com: domain of joern@purestorage.com designates 209.85.214.174 as permitted sender) smtp.mailfrom=joern@purestorage.com; dmarc=pass (policy=reject) header.from=purestorage.com Received: by mail-pl1-f174.google.com with SMTP id d9443c01a7336-21f2339dcfdso49172185ad.1 for ; Sat, 08 Feb 2025 09:37:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=purestorage.com; s=google2022; t=1739036257; x=1739641057; 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=o13An88DBBiikPRk7tvcchkHZ4UK/KA+EJbR0tV1/hQ=; b=AfeTMkqTTUoKxoQU4Lwpvn7LsfMR4kp2EY9jF+A19aUBtMEMVMsod36BcrpVmzFvwy fiabBLu/eEO4iMDcI/E+7GBk/pTC038HdCedaoHYOO/KJSkRm63eGmtET57mcI9XMF6G k1xR2U40zRLjTCdQxYG31EWWxQmO/edAchmGw30iue0Or7g2q+TJJdTIbW7rJH93CBRI LM/sf7SEEuWD/B7pBeOEKUwJPerND8baMk5wLm6LaaiaXKIKCf5L6B5NMRJOumg0pQTL H5B0dua+2mtt67a3rtymSPAFcxLEZCbN28uw66WJyzeX/sS/3AlJOt1A/TBTcKP3qMpU WAXA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1739036257; x=1739641057; 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=o13An88DBBiikPRk7tvcchkHZ4UK/KA+EJbR0tV1/hQ=; b=mPz4C5U3uCmSH6x+rXS4VtmyEV0SGabcN3Yf0lm/FWd4mW4XUDp0i7k2wuHsENQIB0 p/W5LZ2WVKEHPc+3bw2qS5SJx5UshFSao6X0nxg0W58Laq8rcErH7g94qJ0XPgyJzR+S 059ilDJy9g6AmAtUf50+os6W+IA0wSoHsxkutf+9A9Kj/bqPDT2aD88yhJ++bzoWNF4I xN85IF5W0w04qvOuJ98imrqixF0AtWwkSnviuuufqPYeEjHzh/kXOixDmJs+NKBHYZWF bRKC1KDtbTYzE75i9uT/w9tfjq7n/X0qhb/ljH42j9EgJuJj3X+/rJzGBdOQs/2NzeeU ft2w== X-Forwarded-Encrypted: i=1; AJvYcCW2Ax/Yo0W+ig3Yv7ajv526PAubn1Qw4+5nTH4b3GS+C3WtpYt8id4Al++60WawCBBUnXyKHsLsHw==@kvack.org X-Gm-Message-State: AOJu0YxtqdLV40R5701LWa/vIf8z4j04e74wk9kaYWkxZsju8EgFmI6I epEtc8Va6Lka7jTvVk/pjobtUtbUMNfkP61VR/sWAHWe02MRaxTLgWzPvoJAWHI= X-Gm-Gg: ASbGncuBSGpdAqNC6B+SCxFuWGowGoJq/8JYJ/WcOn11VO5rhCBpi0rlKJHNgLJR76i dN61HpJYXMfmyMOdyaxjsOpW07Gqg8mSqc1wT+AXKkcGzSbuPsBqemc45mNrbet7Se0qTgXmgYl Ss0o/cFnET6iGVbkpgadMEkZEthdSEsf3rwX36q007+ROKRaMivP1ZE/WjBwCo87HDoomeeWO77 Ek0HPGi18SxGvFYPnZTwHhvYgXHkHykS6O1D7axS/Q8kMkd/KktktWjgb36bgonlXvm12LVyYhG 1v+wECfuTQe4kHuw0uzsBqN/UoZWRDQB6nBYJrVrfg== X-Google-Smtp-Source: AGHT+IGThjrQAcDA0pQMxIf6QdJguVmk4whDqp9QoJFGme4slC3yaqU+OGa1Gi4sEiwX3PRHi13fng== X-Received: by 2002:a17:902:f68f:b0:21f:5e6f:a406 with SMTP id d9443c01a7336-21f5e6ffcbamr79394365ad.20.1739036257327; Sat, 08 Feb 2025 09:37:37 -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 98e67ed59e1d1-2fa0b600316sm5360317a91.43.2025.02.08.09.37.35 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sat, 08 Feb 2025 09:37:36 -0800 (PST) Date: Sat, 8 Feb 2025 09:37:34 -0800 From: =?iso-8859-1?Q?J=F6rn?= Engel To: Lorenzo Stoakes Cc: Uday Shankar , Muchun Song , Andrew Morton , linux-mm@kvack.org, "Liam R. Howlett" , Vlastimil Babka , Jann Horn , Oscar Salvador Subject: Re: [bug report?] unintuitive behavior when mapping over hugepage-backed PROT_NONE regions Message-ID: References: <82afe852-4098-4eea-a646-37beab88604f@lucifer.local> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <82afe852-4098-4eea-a646-37beab88604f@lucifer.local> X-Rspam-User: X-Rspamd-Queue-Id: B4C90C0003 X-Rspamd-Server: rspam07 X-Stat-Signature: wajdpnxgoy6xr6a6zrjybasya8yizuqb X-HE-Tag: 1739036258-52710 X-HE-Meta: U2FsdGVkX1/3ABSZP7NV+N+x6aLmPfwttafqi5AVBGG+juNURI+gIXs7A1Pv3NlPo+HhQMCKDdQn5hCcgPervMUM24BgO8wl0Bnq/hA9E58Vh+fla2UKMX6ZOR47EUOuWjyPHwib4VufLRcp+tVwoT8Sgc10hRqGXCSOnUBJzNvqVB4ZFAJr8qD0tlbWoVsy2k3taqOTNKaf3/BjAhhDpUAH4PqQBpD35Ig/not/4vXjcegcVBrxIM8QAxFpsie/B9wC0BY1FhxL8eLmnfLmg0UhE6JfIui3sxiNWfnnBpnAZZK5AQG1Bzn7eGyYbtEd6/TCXTJ3F9Uxiw67XVC7+e7qqS1C27u/3Al4EVqmhRdy0U4gci8GLvELyTAi6IUb8yUJc/atXoFwzYdQqNXMVjCHT8mCz0LjayoD7e0YYfczfSQKw7T7RO+r8Ehf72aYFGWmXZeWfTq/abEmEJcow5DcUBWOe8ZqId28Cbql5gwENsS5AlDATsAasAdQHccSJBp40J74feCDMnyXKanqPQO9AdcdPTb4JwYF//17vupvL1LnF9wx6aX8HjQVCml3RCwbxk/hbGnhlU2yOHnHxTbyqT6vu1pet1znoznsGRA06h3DFKq6KG1PulHN/k8qy5B/XUPnb5v/n1dfK7ryLFaqJelauni7ykWMzc04OLHeMjYT2FN5/M/3EvdUg/Yv2wJSoaW+TVIaU/1xpXngkdw75x6oAF/sgrSirVQgGv10fNxEDfAj8kb4qA7y6e0qQ1OAGqPTsBcWFqcCGhvD1E+CPcPOG3SdOx9MOZwHilG98RXCexqTjmvMPWcue7ha3sgzvMt5J3XZnSB6bz8NkhNOb0kOEZKY9ukkFPb1XzoEVturEYO2423LYI+i2EL5QOdioZICvsbQYyZzPejWmRqxMMr/n6V00d9GpuqtTQ+23RfAzaLoZCCECfbAT4vMuVdSwOpIPK9OwD0FVez dw8btHzo 9SL5uFutmQbEXEOwblFr2xYXhZqyDHvE1hfOKYzK+WHE087EJOTQsOEE7XQSYzC+Z2erCM5XU4wXkkJLiI9/b6bHiS4/yN1U5I92cOFRJfivDyTuz45WBSUks3RbRwlGd6Nyzd/O+4/bHl2jgRSdYLsk8fCip+iXWAyKSIX+liCVIfrl7aopn2NuoG6hk8zaFsup5eaqpbEIku8O7HQNf4YV0ZKApOrso3n1b8kTCQl/TvXUFCxJntLAACysx/9K9owAw0Grh1EVcV73gpPIGQwXOkDbGylq0VTC2FaX1D/cyZhQ15jDFnp4ccGvUCx6qIyHLH/rprTNf8kA1N8e61Lm9mNEoRZBnzca6RPOZyLSqJ0Nek7GLs4s1pzmb2QvwrVAjMckwOaw5T/jMad+Qs0r39mA7m7H0ySJn6Xf4AUEp/R0U1rN7CLqHRd2vVCneGkTofOJZvA3YWaDf6wHnBXgUS0j1aYInSpa3 X-Bogosity: Ham, tests=bogofilter, spamicity=0.157536, 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 Sat, Feb 08, 2025 at 04:02:47PM +0000, Lorenzo Stoakes wrote: > > To be clear, you won't get any kind of undefined behaviour (what that means > wrt the kernel is not entirely clear - but if it were to mean as equivalent > to the compiler sort 'anything might happen' - then no) or incomplete state. Going off on that tangent, I think compiler folks completely abuse undefined behavior. Historically it simply meant that you might get two or more different (and well-defined) results, depending on which specific hardware you ran on. Somehow that was reinterpreted as "I have license to do whatever I want". > I guess you mean PROT_NONE? :) For the case in the thread you would have to > have mapped a hugetlb area over the PROT_NONE one without MAP_NORESERVE and > with insufficiently reserved hugetlb pages, a combination which should be > expected to possibly fail. > > If you perform an mprotect() to R/W the range, you will end up with a 'one > and done' operation. > > I'd also suggest that hugetlb doesn't seem to fit a malloc library like to > me, as you rely on reserved pages, rather wouldn't it make more sense to > try to allocate memory that gets THP pages? You could MADV_COLLAPSE to try > to make sure... > > However, if aligned correctly, we should automagically give you those. We tried THP around 2012 and rejected it. The latency tail became a lot longer and fatter. Various things have changed that might make THP less bad today, but I am not aware of anyone reevaluating it. I think the problem with THP was the mmap_sem. Given a heavily threaded process, the mmap_sem tends to be the one dominant lock in the kernel. A secondary problem might have been the background thread scanning for pages that can be merged. Not sure about this part. We just disabled THP and moved on to other problems. And yes, PROT_NONE/PROT_RW. Sorry! Jörn -- Every hour workers spend doing something else is an hour that they aren't doing their jobs. -- unknown