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 90923C61DB2 for ; Fri, 13 Jun 2025 09:12:39 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 1BAEF6B0089; Fri, 13 Jun 2025 05:12:39 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 164E66B008A; Fri, 13 Jun 2025 05:12:39 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 07B996B008C; Fri, 13 Jun 2025 05:12:39 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0012.hostedemail.com [216.40.44.12]) by kanga.kvack.org (Postfix) with ESMTP id DD5966B0089 for ; Fri, 13 Jun 2025 05:12:38 -0400 (EDT) Received: from smtpin15.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay10.hostedemail.com (Postfix) with ESMTP id 863E1C1551 for ; Fri, 13 Jun 2025 09:12:38 +0000 (UTC) X-FDA: 83549811996.15.841E901 Received: from out30-110.freemail.mail.aliyun.com (out30-110.freemail.mail.aliyun.com [115.124.30.110]) by imf17.hostedemail.com (Postfix) with ESMTP id 897564000D for ; Fri, 13 Jun 2025 09:12:35 +0000 (UTC) Authentication-Results: imf17.hostedemail.com; dkim=pass header.d=linux.alibaba.com header.s=default header.b=Squ5aHPw; spf=pass (imf17.hostedemail.com: domain of baolin.wang@linux.alibaba.com designates 115.124.30.110 as permitted sender) smtp.mailfrom=baolin.wang@linux.alibaba.com; dmarc=pass (policy=none) header.from=linux.alibaba.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1749805957; 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-transfer-encoding:content-transfer-encoding: in-reply-to:references:dkim-signature; bh=mChSD/u8wIZMVmHw/Zc0kj2t+KuBko5/1GsKc3/KtCc=; b=1Ts8UZEq4gfPOyqzbp0EOdLt5S1puPE/9jNR/d9aMji0k8sQvkUQt48GRS0klaYNuqfm+x igu3n441GVzvQB5nrA4oKj5hBr8LbsMzlZv9GzHdv3t3w/craVMHEhzMwAQ3TCp2XA4y52 ZjEy0BxKqAZHsEyE1+371MGDSuq+KSg= ARC-Authentication-Results: i=1; imf17.hostedemail.com; dkim=pass header.d=linux.alibaba.com header.s=default header.b=Squ5aHPw; spf=pass (imf17.hostedemail.com: domain of baolin.wang@linux.alibaba.com designates 115.124.30.110 as permitted sender) smtp.mailfrom=baolin.wang@linux.alibaba.com; dmarc=pass (policy=none) header.from=linux.alibaba.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1749805957; a=rsa-sha256; cv=none; b=KC6nEateggTWPWrAsegEqoSGHzZamz7qG/poFvEWJ0j7TyqkOvQYkw2xBtdDrk4W3DwYk4 C75CBl71kyU+PH3X6ELSG6fUgzIDS4EUhqLkW5E2fN0/RHOuJDb5IL6rhWpnHsh1jFWOxY JBF8yjbanTXklv8setZjMNdbLhjQlhE= DKIM-Signature:v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.alibaba.com; s=default; t=1749805951; h=From:To:Subject:Date:Message-ID:MIME-Version; bh=mChSD/u8wIZMVmHw/Zc0kj2t+KuBko5/1GsKc3/KtCc=; b=Squ5aHPwL/z24oK8Z1nSD0/eccTHJmoX0v2tYK0b2DuGlZqhuvBze0Ui24m0GpAZxp5fp1W+K7OpYKG621NmNrYs0SB7pMtoYD3Tu3PUMW1QSVOEKpgDMKa0W0O41Ck6CGr1jWARp/G4x7TfZF1hit3v8HzXSKHy7eGywbZDs1c= Received: from localhost(mailfrom:baolin.wang@linux.alibaba.com fp:SMTPD_---0Wdjy3Cr_1749805950 cluster:ay36) by smtp.aliyun-inc.com; Fri, 13 Jun 2025 17:12:30 +0800 From: Baolin Wang To: akpm@linux-foundation.org, david@redhat.com Cc: ziy@nvidia.com, lorenzo.stoakes@oracle.com, Liam.Howlett@oracle.com, npache@redhat.com, ryan.roberts@arm.com, dev.jain@arm.com, baohua@kernel.org, baolin.wang@linux.alibaba.com, linux-mm@kvack.org, linux-kernel@vger.kernel.org Subject: [PATCH] mm: huge_memory: fix the check for allowed huge orders in shmem Date: Fri, 13 Jun 2025 17:12:19 +0800 Message-ID: <529affb3220153d0d5a542960b535cdfc33f51d7.1749804835.git.baolin.wang@linux.alibaba.com> X-Mailer: git-send-email 2.43.5 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Rspamd-Server: rspam12 X-Rspamd-Queue-Id: 897564000D X-Stat-Signature: 1jo98p61zkbesadeykexxjrwxsbtyks5 X-Rspam-User: X-HE-Tag: 1749805955-433900 X-HE-Meta: U2FsdGVkX184NifDjo/mU9WC8A+DgOLwnkdG6NPoUIRUtUNeTWkobhSMoZ65XfqgKG5jm/LTN1WrUetClL/2XaJVzeb8nRsT2Eq3jW8vEzvqK7SmEjACgRdaqlK0KqKxktJ3lBIm0TfknoT0Cp7Es3ltt8AroMXSUpazmSpx9kR5J/RDqOpP96tRW/mYb4mq+/+h+rMm7KS/V1wTIY5TYg9ztzn+22MLEi9vdcTtL/SVYY6Ohg9/AH0Mr6Hh0a4NIoUhJsK4p08M6kRjm+0HY903ONEBg2pHSR5scUgCSLvZUZfiKPUXesXD98G1vMpCjDi9FevJW//SkvYy/BsB9KK69hPyvQlUY0dU2rbEoidWttvSFn82KhkbQBALPjeqFuLlyC47gDjsSNEIsm3DnSlqSbKvMEVaqUnvkkZ5Nshn0H+Q1JPOtSxvDm8Trqcy6iEN+EG2xYeJJB07h7rXVF4Ts9lVB57ejnJfYbcBwa/34LkZKBVpEzA5zIUzqJf1B4eA4w/ezlPIOAE7pDp3wiQ58ZsLBveeRx3A61LcVUabt8kb1WCokHDtGwu6LcxwqAlMh4KSJutWCnNkLgoiASFE669puURV9xjNpK2y4K/27fzvegeAPXunBpt1FZVZ7zLyst5NJGjL/W0UhSjWgYnvFdV8Ncm5miLKdrzjITShZLYn9Q8Krj/yJDXvwx1m+YrJ/WUyA73crrJg5Qhq72UMqXsS9NnkoasdTYbZr8WY2lFYbVG9K35rsYHW9rnmQnVQfpL7ry3lGIr6TqgidCbPSRCyImPktFIoIWvsKEg+B33ATSBjorV9DXR+FeB9Ks+I3W4N9FI7uHbanMxdArBGiW/Z/qP1sQPR+rSLdsX+X1VFPNBdShDrMEhVWTRQlbPUNXi3wZHMoW4XOQRAa+c5K/pXrRG8JpQ53PlLDjUoQ+Tv0Te3h6xLY+8b04IXEOiHFNdfpKUfqaE4n6J iB08hEoP eAXOzpRY6WvhoY9e8EjFyaGJOZXScYp4Lq2usMv5hr7nIuxqtlKDA59PLKafQ+Gxa6lUpIreO/3BFUhfAoWDPQFI0n9CZ4a7nU85Difb1r2h7JRBR0iRa/4Ojx8dMWtik/ntsqjElq8yzT44KLl/j78VmuKYF1QRJJdaCEsIvth9Jk/NVRXk0k96F5Cqd9yOyJ5bxtmI+PO7mP0Mo3sdobvEyYnlTEmQjqlwWhu0fm27s6QC9Fme7XDpCYC0qX1d3uCSmVk0WeBXiOE0BxlcJ4HxdnDr0EEw2mKouxdwVTt5SY64hqJQ9BAU1hzSYnYpGdgzFKKc+C0mfTXYGyuR1N0cGHONQ1IWlAdqsQtLOxU1CvNw= 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: Shmem already supports mTHP, and shmem_allowable_huge_orders() will return the huge orders allowed by shmem. However, there is no check against the 'orders' parameter passed by __thp_vma_allowable_orders(), which can lead to incorrect check results for __thp_vma_allowable_orders(). For example, when a user wants to check if shmem supports PMD-sized THP by thp_vma_allowable_order(), if shmem only enables 64K mTHP, the current logic would cause thp_vma_allowable_order() to return true, implying that shmem allows PMD-sized THP allocation, which it actually does not. I don't think this will cause a significant impact on users, and this will only have some impact on the shmem THP collapse. That is to say, even though the shmem sysfs setting does not enable the PMD-sized THP, the thp_vma_allowable_order() still indicates that shmem allows PMD-sized collapse, meaning it might successfully collapse into THP, or it might not (for example, thp_vma_suitable_order() check failed in the collapse process). However, this still does not align with the shmem sysfs configuration, fix it. Fixes: 26c7d8413aaf ("mm: thp: support "THPeligible" semantics for mTHP with anonymous shmem") Signed-off-by: Baolin Wang --- Note: this general change is suitable to be split out as a bugfix patch based on the discussions in the previous thread[1]. [1] https://lore.kernel.org/all/86bf2dcd-4be9-4fd9-98cc-da55aea52be0@lucifer.local/ --- mm/huge_memory.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/mm/huge_memory.c b/mm/huge_memory.c index d3e66136e41a..a8cfa37cae72 100644 --- a/mm/huge_memory.c +++ b/mm/huge_memory.c @@ -166,7 +166,7 @@ unsigned long __thp_vma_allowable_orders(struct vm_area_struct *vma, * own flags. */ if (!in_pf && shmem_file(vma->vm_file)) - return shmem_allowable_huge_orders(file_inode(vma->vm_file), + return orders & shmem_allowable_huge_orders(file_inode(vma->vm_file), vma, vma->vm_pgoff, 0, !enforce_sysfs); -- 2.43.5