From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from out30-124.freemail.mail.aliyun.com (out30-124.freemail.mail.aliyun.com [115.124.30.124]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id EB82235BDC2 for ; Tue, 18 Aug 2026 02:47:40 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=115.124.30.124 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1787021263; cv=none; b=h58sptH7LtgH7WNt+YXn0afeiLhlchHnNluriWmLAfO7x5N7SQuPmSCwrG7o73ueSuoSRiBKLNFU8897kNUSrB1U8c3ad6Xc2ih/NkD/TGmI7JD2e/0wQvVXZj08pIzAmgNT3LHomh/bjo6ZJP4H2DZP9+ALynzLBk33GCSyM4g= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1787021263; c=relaxed/simple; bh=+LsfLw9vH+H5IdecqJXXiFJLMOzYrBmZUsm2FpJ/ft4=; h=From:To:Cc:Subject:Date:Message-ID:MIME-Version; b=Ip8UBObnrCYFHt1f33d3QRl0w7ia2urqdirQ24jeMF0x9ExFl55BIsHQiYUNzedvQXcow++9VAL28ZTU6Ckyucj2p5XSE9WI2y5RjC48ZO/YQK43eMmi3eHlK+OxBlNSFtbGlP6l1340MA0wuPuLHOGqrz/M3uRfSAbpZNxxzs0= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.alibaba.com; spf=pass smtp.mailfrom=linux.alibaba.com; dkim=pass (1024-bit key) header.d=linux.alibaba.com header.i=@linux.alibaba.com header.b=cmnvVKlQ; arc=none smtp.client-ip=115.124.30.124 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.alibaba.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=linux.alibaba.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linux.alibaba.com header.i=@linux.alibaba.com header.b="cmnvVKlQ" DKIM-Signature:v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.alibaba.com; s=default; t=1787021257; h=From:To:Subject:Date:Message-ID:MIME-Version; bh=o8HXjTmtSGyMNj4VnIyLtTJCTZHouZ2WYIC15u5uiAg=; b=cmnvVKlQP3E5flRN3Kvy6un40CbiLroq5Fqua72D4hnO2/OB3zsDqUeOZqu2gib6tpU8lsxRFStPKeaHgSAEFFdLv81+4UY/jOIWGsE+qouykzEInDIejrEtlSHZcbXNnpMbyo9DBAIM7K9YMlQDP59kz4yi9WRg+eL//XGaeA0= X-Alimail-AntiSpam:AC=PASS;BC=-1|-1;BR=01201311R611e4;CH=green;DM=||false|;DS=||;FP=0|-1|-1|-1|0|-1|-1|-1;HT=maildocker-contentspam033037033178;MF=baolin.wang@linux.alibaba.com;NM=1;PH=DS;RN=17;SR=0;TI=SMTPD_---0X9Blfsr_1787021256; Received: from localhost(mailfrom:baolin.wang@linux.alibaba.com fp:SMTPD_---0X9Blfsr_1787021256 cluster:ay36) by smtp.aliyun-inc.com; Tue, 18 Aug 2026 10:47:37 +0800 From: Baolin Wang To: akpm@linux-foundation.org, david@kernel.org, ljs@kernel.org, hughd@google.com Cc: vbabka@kernel.org, annh@google.com, ziy@nvidia.com, liam@infradead.org, nico.pache@linux.dev, dev.jain@arm.com, ryan.roberts@arm.com, baohua@kernel.org, lance.yang@linux.dev, usama.arif@linux.dev, baolin.wang@linux.alibaba.com, linux-mm@kvack.org, linux-kernel@vger.kernel.org Subject: [PATCH v2] mm: fix incorrect vm_flags usage when checking allowable orders for tmpfs Date: Tue, 18 Aug 2026 10:47:26 +0800 Message-ID: <7d5b5eb27be798f89d563b06254c947ff53db0b2.1787020910.git.baolin.wang@linux.alibaba.com> X-Mailer: git-send-email 2.43.5 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Lance reported that when nothing else causes the mm to be considered for khugepaged collapse, an MADV_HUGEPAGE-advised tmpfs VMA alone does not trigger scanning. After commit 6beeab870e70 ("mm: shmem: move shmem_huge_global_enabled() into shmem_allowable_huge_orders()"), the shmem/tmpfs allowable order check reads vma->flags directly. However, when MADV_HUGEPAGE is handled, khugepaged_enter_vma() is called before the VMA's flags have been updated, so the check uses stale flags and incorrectly rejects the VMA for collapse. As a result, khugepaged does not collapse the tmpfs file into PMD order in time. Fix this by calling khugepaged_enter_vma() with the new VMA flags in madvise_update_vma(). Meanwhile we can remove the khugepaged_enter_vma() in hugepage_madvise(). Reported-by: Lance Yang Closes: https://lore.kernel.org/all/20260815181632.21453-1-lance.yang@linux.dev/ Fixes: 6beeab870e70 ("mm: shmem: move shmem_huge_global_enabled() into shmem_allowable_huge_orders()") Cc: stable@vger.kernel.org Suggested-by: Lorenzo Stoakes (ARM) Signed-off-by: Baolin Wang --- Changes from v1: v1: https://lore.kernel.org/all/ed34ca03ae7d65e89467fb87bc961f5497049c00.1786948410.git.baolin.wang@linux.alibaba.com/ - Update the commit message (per Lorenzo). - Call khugepaged_enter_vma() in madvise_update_vma() (per Lorenzo). --- mm/khugepaged.c | 6 ------ mm/madvise.c | 8 ++++++++ 2 files changed, 8 insertions(+), 6 deletions(-) diff --git a/mm/khugepaged.c b/mm/khugepaged.c index 5a06e3942e88..79effd3f3da4 100644 --- a/mm/khugepaged.c +++ b/mm/khugepaged.c @@ -454,12 +454,6 @@ int hugepage_madvise(struct vm_area_struct *vma, case MADV_HUGEPAGE: *vm_flags &= ~VM_NOHUGEPAGE; *vm_flags |= VM_HUGEPAGE; - /* - * If the vma become good for khugepaged to scan, - * register it here without waiting a page fault that - * may not happen any time soon. - */ - khugepaged_enter_vma(vma, *vm_flags); break; case MADV_NOHUGEPAGE: *vm_flags &= ~VM_HUGEPAGE; diff --git a/mm/madvise.c b/mm/madvise.c index c179938097bf..cb93cf82d8df 100644 --- a/mm/madvise.c +++ b/mm/madvise.c @@ -178,6 +178,14 @@ static int madvise_update_vma(vm_flags_t new_flags, /* vm_flags is protected by the mmap_lock held in write mode. */ vma_start_write(vma); vma->flags = new_vma_flags; + /* + * If the vma become good for khugepaged to scan, + * register it here without waiting a page fault that + * may not happen any time soon. + */ + if (vma_flags_test(&new_vma_flags, VMA_HUGEPAGE_BIT)) + khugepaged_enter_vma(vma, vma_flags_to_legacy(new_vma_flags)); + if (set_new_anon_name) return replace_anon_vma_name(vma, anon_name); -- 2.47.3