From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-pj1-f49.google.com (mail-pj1-f49.google.com [209.85.216.49]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 4D1F713DBA0 for ; Fri, 17 Apr 2026 01:16:19 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.216.49 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1776388580; cv=none; b=SJMQ8EkUu/f0CLyYfECJl+ZiFFtf+rNbBaxD1+FgnvCenYWtECAhZ9tD9dXVAGddQkvflWCxDglcSuCVl3QldbZf9TN4pDJwTjlsaIg0BqFYgxHO/fP3pTa79x5Ixrh8k+3iFi1LCGylhvLMdQc2x5VtIO3BtkVGhPGZ2J6Lp5Y= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1776388580; c=relaxed/simple; bh=lkb0B7CCKtHNg1nK7RVM7egWREnBgJP92eLXdlxI9HA=; h=From:To:Cc:Subject:Date:Message-ID:MIME-Version; b=FLXAxL+N4VONW04+xED7pvSwdnWYaC8VdqlnuALF4LnY7yedZOjMOQ2PhbrqrCQaMCnJCchJQUAJEQ09y+7h2eSYnu1iu0UJQSWbbYN6HghC6Cp2QngpAxnBgEXGgadaYFOWNaNzP3CInVYdjYq0eJ1wKX+tWVdxJ6JM9lUCQfY= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com; spf=pass smtp.mailfrom=gmail.com; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b=EuxCQeSF; arc=none smtp.client-ip=209.85.216.49 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="EuxCQeSF" Received: by mail-pj1-f49.google.com with SMTP id 98e67ed59e1d1-35d965648a2so174085a91.0 for ; Thu, 16 Apr 2026 18:16:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1776388579; x=1776993379; darn=vger.kernel.org; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:from:to:cc:subject:date:message-id:reply-to; bh=asg74WJhLQYJ7UIfGwSHS141GuqqTNXs+jX/zqQ3Kx4=; b=EuxCQeSFDt9odmRTQZWldN8zldlF+A5wdLtgLzPDAZAAWuIVr0K8j3gQ/IGxiBhq7B iKsnKQThWrcXkmhrVLOOUtuPOvPM1rRmbbqC2aDN/O39YYqkwfr+EsA6d7kg70uMRsqA cLjIq1B43tnYm5XmSXS8DjJk82tx/rr45HU/S6ibTv+8jrbi+x75EL0mITGvLW5tmjUt xYR++qrJP3yKPIqp+AcclK3RW328VFIvHdsJObBbtESOR7xJ4KxLJSuVBqlJAxk+s0WV KoqMkN8+FTB9Mu8okmBReodKAHiLSqfmgi2QsyW4GTFhM/UhU5pje98NRc9DsrGYFAsS 5Hew== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1776388579; x=1776993379; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=asg74WJhLQYJ7UIfGwSHS141GuqqTNXs+jX/zqQ3Kx4=; b=AcP/xWqSQOmcYG8yq+HQme0XPAEOYg2ed2AGHMrsICZ5tN3VHigLZDl4Mt8V/Q3cxW mbRQUurJGf8WtOMrju05g1rMcCjbEKr61lpeRn3WnTbNY7NlWmhU9h5l2CgmY8Zb3WLI 4j/sd9Bfp6hCWRxaodhBfvQROGhyaGRHOlWZSZ9m/1O5vsVv6UpsoCsgQQDxV8AN/CPv 8wHVoYVH2ZfYu8hvH7PFzBSw7p4KLyLNtSBzPwiqy+/UgP+wbdOve57g/5PvgoAcmxd0 /iRBrJqhPvfDyxqivZa6HWQf48O2rtdZFNltklsiO5gp9w5gDqF1mg/yu6lCPhpiWSpw UY/g== X-Forwarded-Encrypted: i=1; AFNElJ+MAMxbWIixnYOWvti2eJ0yUY8F1MeidihnUq2rQAdjaLNx4mOjhfC6Q/iDnTRXlcgxix2SsSD+gy0gmCQ=@vger.kernel.org X-Gm-Message-State: AOJu0YxkDgbAt1AOdKPiyhNK77s42nhW8tpYzHCLK3Z9WGU30g0L2Int 2WovrbvJf3a5D7xYYrgAMbjlXeq4+PBpKrABwdSX8QPFRaUzsAOPlMsB X-Gm-Gg: AeBDietQuoRqWc/P2MFL2db7ATRfxgMIEjxk4QBWZ1UveqUi8LNY1WAzVFb71uqN+e9 fmUQ5gaGdU7x4lamIi17+NAyZ0bl6w36jokrsRWehi8eAt6sLIG17CAwvSQzH5apr0xi6Jea2Gf pVt5Sr21ZARf02rxRP88mnBwOw682seqRv7te669fDfNjlr3ECHiv743QcBlhc9kngxsqciF9tr 2kzyZ9bgt0qEfdq46RkYJN9NZwtwC86rpuFlltAC61PwfGuJK4n6j6XQ8OCnK+gBIqDKWZq/cBC V6y5y07u4szcq/GnJcguIrj7XzMvlH/dfLFuGWQV2qbaxwW7sqCWQuAdW2m2xV4o8VmBCEHb5T1 7PUSxS2imJaDQGoMf/tdF36soxkotmuHaAutIXKuIGdkQamPIxYGWhr+bKTUExpfeMz5oJzDRjE qnauOxNanZHol0Ft6UgmT0wZEt0fo2+XM4H5NEcT8G5/vi4UkzaAczqnu+E4Ly3EaE3MjY5etgO QJgiwCw5Q== X-Received: by 2002:a17:90b:5583:b0:35b:8d89:7199 with SMTP id 98e67ed59e1d1-36140468a44mr642291a91.15.1776388578362; Thu, 16 Apr 2026 18:16:18 -0700 (PDT) Received: from kernel-fuzz.. ([103.172.182.26]) by smtp.gmail.com with ESMTPSA id 98e67ed59e1d1-36141990bb6sm87274a91.17.2026.04.16.18.16.13 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 16 Apr 2026 18:16:17 -0700 (PDT) From: ZhengYuan Huang To: akpm@linux-foundation.org, david@kernel.org, ljs@kernel.org, Liam.Howlett@oracle.com, vbabka@kernel.org, rppt@kernel.org, surenb@google.com, mhocko@suse.com, willy@infradead.org Cc: linux-mm@kvack.org, linux-kernel@vger.kernel.org, baijiaju1990@gmail.com, r33s3n6@gmail.com, zzzccc427@gmail.com, ZhengYuan Huang Subject: [PATCH] mm: prepare anon_vma before swapin rmap Date: Fri, 17 Apr 2026 09:16:06 +0800 Message-ID: <20260417011606.1089985-1-gality369@gmail.com> X-Mailer: git-send-email 2.43.0 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit [BUG] madvise(MADV_HWPOISON) can fault a swap entry back in through get_user_pages_fast() and hit: kernel BUG at mm/rmap.c:1364! Oops: invalid opcode: 0000 [#1] SMP KASAN NOPTI RIP: 0010:__folio_set_anon mm/rmap.c:1364 [inline] RIP: 0010:folio_add_new_anon_rmap+0x41d/0xc10 mm/rmap.c:1553 Call Trace: do_swap_page+0x14c5/0x5c30 mm/memory.c:4963 handle_pte_fault mm/memory.c:6198 [inline] __handle_mm_fault+0x1512/0x22f0 mm/memory.c:6336 handle_mm_fault+0x42f/0x820 mm/memory.c:6505 faultin_page mm/gup.c:1126 [inline] __get_user_pages+0x4b3/0x3400 mm/gup.c:1428 __get_user_pages_locked mm/gup.c:1692 [inline] __gup_longterm_locked+0x945/0x14b0 mm/gup.c:2476 gup_fast_fallback+0x8a3/0x2440 mm/gup.c:3220 get_user_pages_fast+0x64/0xb0 mm/gup.c:3298 madvise_inject_error mm/madvise.c:1456 [inline] madvise_do_behavior+0x503/0x860 mm/madvise.c:1875 do_madvise+0x17e/0x210 mm/madvise.c:1978 __do_sys_madvise mm/madvise.c:1987 [inline] __se_sys_madvise mm/madvise.c:1985 [inline] __x64_sys_madvise+0xae/0x120 mm/madvise.c:1985 ... [CAUSE] Commit a373baed5a9d ("mm: delay the check for a NULL anon_vma") moved anon_vma preparation out of the generic fault path and into the fault handlers that actually need to install anonymous rmap state. do_swap_page() was left behind. It can still restore anonymous mappings via folio_add_new_anon_rmap() or folio_add_anon_rmap_ptes(), but it does not call vmf_anon_prepare() first. On a VMA-lock fault this can leave vma->anon_vma NULL all the way down to __folio_set_anon(), which BUG_ONs on that violated invariant. [FIX] Prepare the faulting VMA's anon_vma once do_swap_page() has confirmed it is handling a real swap entry, before any swapin path can install anonymous rmap state. vmf_anon_prepare() already handles the retry rules for VMA-lock faults, and when anon_vma is already present this stays a single likely branch in the swap fault hot path. Fixes: a373baed5a9d ("mm: delay the check for a NULL anon_vma") Signed-off-by: ZhengYuan Huang --- I can reproduce this issue deterministically on v6.18, but I have not been able to reproduce it with the same setup on next-20260415. However, I have not identified a change that clearly explains the difference. From code inspection, do_swap_page() still appears able to reach folio_add_new_anon_rmap()/folio_add_anon_rmap_ptes() without a prior vmf_anon_prepare(), while __folio_set_anon() still BUG_ONs if vma->anon_vma is NULL. So although I could not reproduce the issue on next-20260415, I also could not confirm that it has been fixed there. Recent changes around the swap fault path may have affected the reproduction conditions, but I may also be missing another relevant change. --- mm/memory.c | 5 +++++ 1 file changed, 5 insertions(+) diff --git a/mm/memory.c b/mm/memory.c index ea6568571131..a64bc9826cc5 100644 --- a/mm/memory.c +++ b/mm/memory.c @@ -4850,6 +4850,11 @@ vm_fault_t do_swap_page(struct vm_fault *vmf) goto out; } + /* Swapin installs anonymous rmap state into the faulting VMA. */ + ret = vmf_anon_prepare(vmf); + if (ret) + goto out; + /* Prevent swapoff from happening to us. */ si = get_swap_device(entry); if (unlikely(!si)) -- 2.49.0