From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-pl1-f170.google.com (mail-pl1-f170.google.com [209.85.214.170]) (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 B37C6433AD for ; Thu, 1 Jan 2026 13:09:12 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.214.170 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1767272954; cv=none; b=h6JxPEeYyIQN+Tu3Keox3bvzTf9DCNoQWi4wZ+hvrFCLxfJ8xKVoFmc25k9Mo9QVL/nv/BbdiIKX2QDbnslBes2F1LYtqHpaYdo0g28k4aC0fXHlG91NSlE2ipduGihve6APITCP8HSnXoBn/uTprrxHMa1naQRZoNEF6iZt/RE= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1767272954; c=relaxed/simple; bh=jpVjHPUKElinABDL8EpxSEegbw5zqEXHsLy84EBXwwE=; h=From:To:Cc:Subject:Date:Message-Id:In-Reply-To:References: MIME-Version; b=fQbuP95ZAyxBhGG+PNtHqc6Kxkq9djCAuKf5R2i6EH3LzfDbdan2oVzI1hXzeQva8swKeOhr6FxJk3SCSFtIv5sZFj1fh4R5VXqZwvNYpyyTaaznQU5J/7fCqKsljOiZI7up4yMez6ljvkED410kAIHCiIDjga+hoUOfQisOfNk= 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=HG4F/+oa; arc=none smtp.client-ip=209.85.214.170 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="HG4F/+oa" Received: by mail-pl1-f170.google.com with SMTP id d9443c01a7336-2a0d5c365ceso151808605ad.3 for ; Thu, 01 Jan 2026 05:09:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1767272952; x=1767877752; darn=vger.kernel.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to; bh=nzS+Hy30FELScvyGLAQhm0QHElXtHjtPJGwOfXP5M0s=; b=HG4F/+oas8hbDxoHO40hJbO2FieNCnMhgdV9DeICubZ2fkmJ9IpFz0H2UXzh0y9CRI +Rjo9LoBGrs1rUPfVls6uwN9Jsa1oubotXrHBnzbPU72tqsSAtpMW1QZgU7xtTS6vZW1 xEJp7OrceHyOMbZX/DsbOCDiX7W3RAnZTTvp3D19yAdz/Kp2Gsv2VCsnh0lQ343BkKDz Mqb4kydDBa7/a9r40gKRYVK56KxokhYfUiSFhAiv2nmPZ+29dfACFAEYr97Xz5thtJd+ T/jYdeTOGAlu23H/tvvGqFkKEW8QHzTQ6Z7xmsL35CLZ8mzk3Y0azT40ctIyYhclwGea gpjA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1767272952; x=1767877752; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-gg:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to; bh=nzS+Hy30FELScvyGLAQhm0QHElXtHjtPJGwOfXP5M0s=; b=cNhbcthE+E9eE36z6UDD8iTN1ISnhy/mALkcGl41N4BWYH1iNJDYc77+bcRofCBATs t2UL3HRdemIaixKRPHwqhYhEf2eR1H+yqHoDdh/HjYlFOdZWhlk99JHMmMf1iUz/NNvs VwoHpM4max64P8OPBamUc0XUg94mST2OFX6H6lxeh6V9ZBw7q2XjjH85h1LKHwdBqNUX Ou/Uo0QzIhQhvLuK7mztU9dHqKFWno2x5lYqPmeilZI10kJNvkDrQdnGwmcsNEP5grYO WCCQFxN1tIMZpgentoe/SOH/MuKgGWiM+4sKL/76PakAAUpWPVcJK5Z3a2cu9g7oIMvn 4XCA== X-Forwarded-Encrypted: i=1; AJvYcCXm0lgfNsmVToZwEfYIhtWYc/2djfQInzqZ+G0FNtrfkYn82cHNgRoWMPjcpXFBWkxmWFfB2YGmRMYRdt8=@vger.kernel.org X-Gm-Message-State: AOJu0YyunqRE7koGSKCpcjog7Nnohz+Bi44tsAF4p/B8vfYBwomZPg+0 IFumDXZaFZygv4QXvQexFBJBlH95dDhmyrut/wc7WxjSf/B1gDECVzbC X-Gm-Gg: AY/fxX6l7+Zw6gQngCyZy4Jp+0vCuM67lTFVyZd9iYyaVnM542YMeSHagFSgzSsjvFu HlblT6QwSIThooz+kRBYDa68eOQBuez6DR5atAYcea7/seCcoIfaBMgHpt2KRxBrTC0lcPSSCoa lLVsKDpEvVMZBp8y+3FTzIrRI5bDMPGd+mmlj7AB52/Pu5bHtwgx+LrL6YNtisQ9q6qCH9g94p3 mG6zNvkPFWPrrBacdfDPOKB2YyrX5FxsFy9F/nYdfOfbQ0Kz1f7hzLdhFsNle8BpnRvNzidaf1z HhOrI/lV4h6j/SicStCWda7KHSBjIIXA8X357X2d1xk9Ds6ElYU/a2jSNFqKlM1RaTCc2cWNu5y bPJGSg/eD25c78WKq8YXDCbJLf8Ymk1yOqvc0+w/JWF55gGZt+KkkBpEpMDVGdwLOi+WY6Ej6Jf LY7OPgWzPC9t4VYoa9Bhqeg5DWaHgKkXQTrvk2A8AU6jbGN281 X-Google-Smtp-Source: AGHT+IFyKM4HrPlnSDkCxENTLwE2h5QfTHvvznDHmte+JFg7pvwa2rlXh6qxgJYoi3FRxN9WYb4ESA== X-Received: by 2002:a17:902:e552:b0:2a0:8360:3a74 with SMTP id d9443c01a7336-2a2f2835cfdmr281796915ad.51.1767272951863; Thu, 01 Jan 2026 05:09:11 -0800 (PST) Received: from name2965-Precision-7820-Tower.. ([121.185.186.233]) by smtp.gmail.com with ESMTPSA id d9443c01a7336-2a2f3d5f5dasm345652335ad.82.2026.01.01.05.09.09 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 01 Jan 2026 05:09:11 -0800 (PST) From: Jeongjun Park To: harry.yoo@oracle.com Cc: Liam.Howlett@oracle.com, akpm@linux-foundation.org, david@kernel.org, jannh@google.com, linux-kernel@vger.kernel.org, linux-mm@kvack.org, lorenzo.stoakes@oracle.com, riel@surriel.com, syzbot+b165fc2e11771c66d8ba@syzkaller.appspotmail.com, syzkaller-bugs@googlegroups.com, vbabka@suse.cz Subject: Re: [syzbot] [mm?] WARNING in folio_remove_rmap_ptes Date: Thu, 1 Jan 2026 22:09:06 +0900 Message-Id: <20260101130906.839504-1-aha310510@gmail.com> X-Mailer: git-send-email 2.34.1 In-Reply-To: References: Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Harry Yoo wrote: > On Tue, Dec 30, 2025 at 11:02:18PM +0100, David Hildenbrand (Red Hat) wrote: > > On 12/24/25 06:35, Harry Yoo wrote: > > > On Mon, Dec 22, 2025 at 09:23:17PM -0800, syzbot wrote: > > > Perhaps we want yet another DEBUG_VM feature to record when it's been > > > dropped to zero and report it in the sanity check, or... imagine harder > > > how a file VMA that has anon_vma involving CoW / GUP / migration / > > > reclamation could somehow drop the refcount to zero? > > > > > > Sounds fun ;) > > > > > > > Can we bisect the issue given that we have a reproducer? > > Unfortunately I could not reproduce the issue with the C reproducer, > even with the provided kernel config. Maybe it's a race condition and > I didn't wait long enough... > > > This only popped up just now, so I would assume it's actually something that > > went into this release that makes it trigger. > > I was assuming the bug has been there even before the addition of > VM_WARN_ON_ONCE(), as the commit a222439e1e27 ("mm/rmap: add anon_vma > lifetime debug check") says: > > There have been syzkaller reports a few months ago[1][2] of UAF in rmap > > walks that seems to indicate that there can be pages with elevated > > mapcount whose anon_vma has already been freed, but I think we never > > figured out what the cause is; and syzkaller only hit these UAFs when > > memory pressure randomly caused reclaim to rmap-walk the affected pages, > > so it of course didn't manage to create a reproducer. > > > > Add a VM_WARN_ON_FOLIO() when we add/remove mappings of anonymous folios > > to hopefully catch such issues more reliably. > I tested this myself and found that the bug is caused by commit d23cb648e365 ("mm/mremap: permit mremap() move of multiple VMAs"). This commit doesn't mention anything about MREMAP_DONTUNMAP. Is it really acceptable for MREMAP_DONTUNMAP, which maintains old_address and aliases new_address, to use move-only fastpath? If MREMAP_DONTUNMAP can also use fastpath, I think a sophisticated refactoring of remap_move is needed to manage anon_vma/rmap lifetimes. Otherwise, adding simple flag check logic to vrm_move_only() is likely necessary. What are your thoughts? > -- > Cheers, > Harry / Hyeonggon Regards, Jeongjun Park