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 B05E1C71136 for ; Mon, 16 Jun 2025 22:09:44 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 529F96B0092; Mon, 16 Jun 2025 18:09:44 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 500926B0093; Mon, 16 Jun 2025 18:09:44 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 43DC46B0095; Mon, 16 Jun 2025 18:09:44 -0400 (EDT) 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 2E9056B0092 for ; Mon, 16 Jun 2025 18:09:44 -0400 (EDT) Received: from smtpin21.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay10.hostedemail.com (Postfix) with ESMTP id D561FC0FEA for ; Mon, 16 Jun 2025 22:09:43 +0000 (UTC) X-FDA: 83562656646.21.6297761 Received: from tor.source.kernel.org (tor.source.kernel.org [172.105.4.254]) by imf06.hostedemail.com (Postfix) with ESMTP id 357D0180010 for ; Mon, 16 Jun 2025 22:09:42 +0000 (UTC) Authentication-Results: imf06.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=VS9eI5T+; dmarc=pass (policy=quarantine) header.from=kernel.org; spf=pass (imf06.hostedemail.com: domain of broonie@kernel.org designates 172.105.4.254 as permitted sender) smtp.mailfrom=broonie@kernel.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1750111782; 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=3ZhKnppoPp8vl7852odID1hFmOj/wtUXvpyD0DpqlAc=; b=A1aR1W1ogNwSg6zyb7qN65plhYS07K0nwQny3I5EZqSfg1GqjHhUV/XMROJ8cPPbQK+fFg WRLIQBGEiI2fJMneG15hfMNbYMmU6Q0YwIYSWp0IY3JiVX2QNWLw+ps+7hNi2mvbF//fkU xMAKw4nP7ArDlAP3QSKAiD6ShvLGma4= ARC-Authentication-Results: i=1; imf06.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=VS9eI5T+; dmarc=pass (policy=quarantine) header.from=kernel.org; spf=pass (imf06.hostedemail.com: domain of broonie@kernel.org designates 172.105.4.254 as permitted sender) smtp.mailfrom=broonie@kernel.org ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1750111782; a=rsa-sha256; cv=none; b=zaDtVxP6B0WV72P1hJhD0rCcJo6DT9j/Pn4eeDhEbXwOrCjCpUnWbKrY6uuJ7nRe0pThaN nbngbiWeVi4WR4sDWPx9DO8/KgLOUJmwX56XeBLirT6qQ7DYPcxx9mpMNhEJQmePdDiu5W DSe0a4bkgBWOMEJWgvHlc7Pj/D6WQ1g= Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by tor.source.kernel.org (Postfix) with ESMTP id 7511E629C0; Mon, 16 Jun 2025 22:09:41 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 78401C4CEEA; Mon, 16 Jun 2025 22:09:39 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1750111781; bh=h/WWz4/20G1NN6IEo+6ubMkiD+y4onmYRmgG5AX8SeI=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=VS9eI5T+oYS280w24QCXC3HjAJDHEKCuCj2F/+CRszxhnrKZGmozzg1jLVAvYgnQA 4dix332iSAsLkiX9X7YHzZWPvAZ6mEr+aSNYLZMCyUsoGMUVElWBuFip/2lqATF7dg OG8vOHrZA/NPXn3GYN6PASPJr6U6fMMvLJsv/2I/8RwkdLd7isE+DNLXMng7tbXsD6 U7gjYk9LglvyC5QRwUw+vqxxuDTH8r+Ow80XGih24LZNJiRRyXJHvxm9y5x7TI/Z2f u9Ft+3JpuvpwOjGR/tBaDFio7+WP0yyXwfMo53TlOdo+fs2GrQ6yS/sze7BH+1lnYt riwA8/Ei5BX2w== Date: Mon, 16 Jun 2025 23:09:36 +0100 From: Mark Brown To: Jann Horn Cc: Andrew Morton , Muchun Song , Oscar Salvador , linux-mm@kvack.org, Lorenzo Stoakes , Aishwarya.TCV@arm.com, Naresh Kamboju Subject: Re: [PATCH] hugetlb: block hugetlb file creation if hugetlb is not set up Message-ID: <5777f917-fe36-4e78-8a10-913c9241816d@sirena.org.uk> References: <20250528-hugetlb-nerf-v1-1-a404ca33e819@google.com> <20250602204107.177e2fdf2209b0926b5ce28e@linux-foundation.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="gxx+s6Ze2jwxK237" Content-Disposition: inline In-Reply-To: X-Cookie: No passing. X-Rspamd-Server: rspam08 X-Rspamd-Queue-Id: 357D0180010 X-Stat-Signature: 93qtzams8hcf5rahd4j4jm9cfaeg3wf1 X-Rspam-User: X-HE-Tag: 1750111782-679309 X-HE-Meta: U2FsdGVkX1+sF9s5nC8A0DzObfRYW7tKEBWghq+zzaZzrNDDHjxza3ZWRWDp95TUJjqskS1YPuCOo7QlD9uLHQ2fU/ATcQgW+o30Jsq0qmK9arfJXIf0eo9VBn6Kh8me9AvHxmobtExXXnut9CZGGHJQ0Qar3Xy1W+Ypx105/TTFJx5kQe7mhV26r7Z9z03+SXtjPoWPww9/tN/iZtQbvWD0YPfBVofPNgXbEoeViKQswREb19+xCITl0wbgiHoHWUoEt+Sv5rU6xDg3YrWpAxTw2pRjxbBLrkuBV2996v/miMYlXWsvO5zq1WhWzrT9S1r5a5cLBCCiOZm5/WlyGbjD7/vmdRqnvLb8Mx5XdCKdGIxb+sBH8+bkZEPFnTx4bXIsjmrW0nv3IekfMU+5dz/60/JBZYGha/KQWRHCZNvivGUsw8HxjglXjLAbEjA5OsFvTsGaCLNH3TcW21/yIteEUdvWWycSyTE4eW+uqwYJvKjyJGEU0UoGiuODxopDB4zjPrBS54682Ju/5q00vELc6ZmRIvD7x1rxvP25Jz5SuUzv5NIVJmOckADb37ErIfXz6fw5caqkK8hU5g2ouOiTb8TVVvGbn5Cq7l/Vpu7X8npiwe8d1Tf0r+NqaCqY/l5j6DSI0QvQM1tJcis7DpV80touj1yXLLn8k6CYGzvHJmDO0wvh0UP7xPyLDnCvXfugRScFAnMjBkrP5gXWRMbmlB+MHEZkFTbuECvRTdephb2LkW0VagdXfbUthVm1SpBfU/jnJXOwhQlP2PnrYV+7zwO5sx1cTkifAUj3whb/M00R9Fp6Gs8aygJ+kS66j+Sng6wG2jTu1gnwNprlQH3o9CFmZmYr2srI8jvw4tPIerfAEA2kIpFVgeRHojBrNHThvsL9+t6z5tD5I78fAoSGovCm0ViCj/ZvLhtwEV/sr2j1UskMba195YUnQLtypeNHu+mEdtgTxdFTkjd emYTN97b +2oUr73/bQ7eVYtc7xe1duQGnqJXmwOcatd2TT8y7cZ1c5SYCA47+ph9RejyFqiBamesmqNRwJueIbq+tA2wrUd67z8mHPGkpNl6yvP++zQ+TXYN4A5x8WKWBse0hsoRoX+9s4E6/ArWlWT/jwO8UMM2DDjvdxOFE1fRVg1tvt+/q7HwT7lpeZeRRKzPjZDZ+VFVqH5iWGK5EVHsbpVT5U0jfSwUWVXrBrYyFMzuB0gRx/bsZzsNxWhckk/sjBJUcKqq7sPthO795xOaVfaeLPrfpqX2A4+9IjT/LRRUGMmXc3YacnASDuaZ4paQqyeqskRU+O/j9OucqM1nH5gde/Fq4zAv4+1aBCH/SRjkghAnxTTAm4FqTU60iOmyBFfv+Qqdqf6SmdyUzAPYRIzWkEPCArOKxAZKV/KfxFFVYojwYykQCIUIogbqOc+ZF1cS0rG9JLxHmaWvv/yEFt9SDiG1JN3qgOn36CToEcWzTfPmKQ4CEAy0F3pqt9Q== X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: List-Subscribe: List-Unsubscribe: --gxx+s6Ze2jwxK237 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Jun 03, 2025 at 06:29:24AM +0200, Jann Horn wrote: > On Tue, Jun 3, 2025 at 5:41=E2=80=AFAM Andrew Morton wrote: > > On Wed, 28 May 2025 19:51:29 +0200 Jann Horn wrote: > > > Lock it down by completely denying creation of hugetlb files if no hu= ge > > > pages for the hstate could be allocated without administratively > > > changing huge page limits. > > So this is a non-backward-compatible change? > Yes, this change changes kernel behavior that is userspace-visible, > and causes syscalls to return errors where they worked before. > > If any userspace is affected it's probably either stupid or evil, but I > > do wonder if there are legit cases for doing this, such as "I don't > > know if there are any hugepages configured, but I'll try this anyway > > and figure out what to do later on". And maybe there are other legit > > cases! > Right. I think an affected case would be if userspace tries to detect > whether the kernel supports hugepages by creating a MAP_NORESERVE > mapping or huge memfd, and if that works, twiddles sysfs knobs to This does indeed cause at least the LTP memfd_create04 testcase to fall over on systems with less memory, if it finds hugepages information in /sys it explicitly creates a MFD_HUGETLB memfd at various sizes and then just closes them without verifying that there are any actual pages at any of the supported sizes. I don't think this is a particular problem, it's pure test code rather than an actual use case, but seems worth highlighting and people will notice LTP issues if this gets backported to stable. It seems reasonable to update LTP here (probably with better hugepages enumeration code?). tst_test.c:1900: TINFO: LTP version: 20250130-1-g60fe84aaf tst_test.c:1904: TINFO: Tested kernel: 6.16.0-rc2-next-20250616 #1 SMP PR= EEMPT Mon Jun 16 07:16:11 UTC 2025 aarch64 tst_kconfig.c:88: TINFO: Parsing kernel config '/proc/config.gz' tst_test.c:1722: TINFO: Overall timeout per run is 0h 01m 30s memfd_create04.c:66: TINFO: Attempt to create file using 64kB huge page s= ize memfd_create04.c:75: TFAIL: memfd_create() failed unexpectedly: ENOMEM (1= 2) The mm selftests might also be impacted here, some of them do a similar check for supported huge page sizes by looking in /proc without checking if there's any actual pages available. I should resurrect the thread where I asked about that. Our CI only runs the mm selftests with hugepages explicitly configured so wouldn't notice. bisect log FWIW: git bisect start # status: waiting for both good and bad commits # bad: [050f8ad7b58d9079455af171ac279c4b9b828c11] Add linux-next specific f= iles for 20250616 git bisect bad 050f8ad7b58d9079455af171ac279c4b9b828c11 # status: waiting for good commit(s), bad commit known # good: [d39a02e47d1e0fba70992a45ec6a6591268a11a8] Merge branch 'for-linux-= next-fixes' of https://gitlab.freedesktop.org/drm/misc/kernel.git git bisect good d39a02e47d1e0fba70992a45ec6a6591268a11a8 # bad: [852f31106c2bd9d7ca17ab766fcaf6ac5a96f037] Merge branch 'for-linux-n= ext' of git://git.kernel.org/pub/scm/linux/kernel/git/daeinki/drm-exynos.git git bisect bad 852f31106c2bd9d7ca17ab766fcaf6ac5a96f037 # bad: [c9b6136d8ef32de2441225e47dfa7b32342fb67b] Merge branch 'xtensa-for-= next' of git://github.com/jcmvbkbc/linux-xtensa.git git bisect bad c9b6136d8ef32de2441225e47dfa7b32342fb67b # bad: [496dd87c6e8bdad67563009b6793c59178b117fa] Merge branch 'next' of ht= tps://github.com/Broadcom/stblinux.git git bisect bad 496dd87c6e8bdad67563009b6793c59178b117fa # bad: [5091252d7c0bb144d359fbfb5838adcea29f5601] Merge branch 'mm-nonmm-un= stable' of git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm git bisect bad 5091252d7c0bb144d359fbfb5838adcea29f5601 # bad: [3e546482aa3d3a3bb0ee9bbaaaa396d7d57a2b63] drivers,cxl: use node-not= ifier instead of memory-notifier git bisect bad 3e546482aa3d3a3bb0ee9bbaaaa396d7d57a2b63 # bad: [e5437627e74d7f610a296c215fc557e6b5436610] mm: rename CONFIG_PAGE_BL= OCK_ORDER to CONFIG_PAGE_BLOCK_MAX_ORDER git bisect bad e5437627e74d7f610a296c215fc557e6b5436610 # good: [c03ff8cc73ddad14444dde3384c34d3d4dfbc354] mm: ksm: have KSM VMA ch= ecks not require a VMA pointer git bisect good c03ff8cc73ddad14444dde3384c34d3d4dfbc354 # bad: [1b8405a9525fafb31b0feb38e1be73aefaee9ce0] mm: Kconfig: use verb *us= e* in plural form in description git bisect bad 1b8405a9525fafb31b0feb38e1be73aefaee9ce0 # good: [42da1e1d4762be8d70db9d8cefea7cd0fb6e3d15] mm/hugetlb: convert huge= tlb_change_protection() to folios git bisect good 42da1e1d4762be8d70db9d8cefea7cd0fb6e3d15 # bad: [326969ed54efc372555acbf726a28ce537c43525] mm/vmstat: make MEMCG sel= ect VM_EVENT_COUNTERS git bisect bad 326969ed54efc372555acbf726a28ce537c43525 # bad: [3b0376d70ab0de716559b10fa8211743c9288529] hugetlb: block hugetlb fi= le creation if hugetlb is not set up git bisect bad 3b0376d70ab0de716559b10fa8211743c9288529 # first bad commit: [3b0376d70ab0de716559b10fa8211743c9288529] hugetlb: blo= ck hugetlb file creation if hugetlb is not set up --gxx+s6Ze2jwxK237 Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAABCgAdFiEEreZoqmdXGLWf4p/qJNaLcl1Uh9AFAmhQliAACgkQJNaLcl1U h9DR5QgAhFdnVfQmgafZZ+wcDpGs8SAqDFOpSMVU55BJfNHyFkTIN8rcyDeEGFKc AXpN3kI+r9aBtIbmbXUUUzy5ExYc0eZq9FU5YuoNkKbGvwS+3XbzbB5DSsF0mPWv +iy5hom8YK12U4qiY8UNEo6sfuNSTc1XtQNLERO5bSn0/QBvDlxoRYT8aH9+XgvY 2QzPahBYwujmI+L9QqtRkRvbZTBR9unI4hdT3/bf7jY899mruKVNIJ0dbC15mQ9w 77zGjsS8kA0lFHw7/0aAfW3/YiYOeu21V6iaz16S7zX9ORS7PKHKoHjj7S9NKkLN GocbgzNjqin6DCE7FpiZCtfrJKQ9Hg== =A8xX -----END PGP SIGNATURE----- --gxx+s6Ze2jwxK237--