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 3F0EFC369B2 for ; Thu, 17 Apr 2025 05:03:41 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 0556F280046; Thu, 17 Apr 2025 01:03:39 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 001DB280035; Thu, 17 Apr 2025 01:03:38 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id DE6A0280046; Thu, 17 Apr 2025 01:03:38 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0014.hostedemail.com [216.40.44.14]) by kanga.kvack.org (Postfix) with ESMTP id C080F280035 for ; Thu, 17 Apr 2025 01:03:38 -0400 (EDT) Received: from smtpin15.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay02.hostedemail.com (Postfix) with ESMTP id 6FD2E120F0D for ; Thu, 17 Apr 2025 05:03:39 +0000 (UTC) X-FDA: 83342342958.15.20D3B13 Received: from mail-pl1-f172.google.com (mail-pl1-f172.google.com [209.85.214.172]) by imf08.hostedemail.com (Postfix) with ESMTP id 94C2816000B for ; Thu, 17 Apr 2025 05:03:37 +0000 (UTC) Authentication-Results: imf08.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=JYtZASgM; spf=pass (imf08.hostedemail.com: domain of hughd@google.com designates 209.85.214.172 as permitted sender) smtp.mailfrom=hughd@google.com; dmarc=pass (policy=reject) header.from=google.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1744866217; 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=Bz/XOU6GJUjnIHziBMa/ejaxLXDiuXn3yPYLfVwKjWo=; b=UwUGURX1wc3RL5qiC7dURJiB2AR60hxr3hEAX6j8VThffwpxfninG2/AGKzngR5mhXcc0E iNIB3h80FWqgG/Yv/hzOMSrnsgZ3DlELLwinFBL3TnpxEc03PJOjtxL/g3n8zHzapN4BIZ NKUt37q9IG5GeKA+QsLY0fk5TwpAcnw= ARC-Authentication-Results: i=1; imf08.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=JYtZASgM; spf=pass (imf08.hostedemail.com: domain of hughd@google.com designates 209.85.214.172 as permitted sender) smtp.mailfrom=hughd@google.com; dmarc=pass (policy=reject) header.from=google.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1744866217; a=rsa-sha256; cv=none; b=n9kzeKs+3QlOCF+wWg5AMK4eoNpyjLzMoWJL3dt5p1g3dfgbFv0uhi6ViLcOWlaMk0ntWd cobLrcKbORT3NwsmE59uCu//yVfNrm/x3MLtLQ4JPsaaD0lrENs3RBrqrmP6q4wJNcsvvM 1aWGXZVc5Bs581FAUYbwXcTSrypvBMI= Received: by mail-pl1-f172.google.com with SMTP id d9443c01a7336-223fd89d036so4542625ad.1 for ; Wed, 16 Apr 2025 22:03:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1744866216; x=1745471016; darn=kvack.org; h=mime-version:references:message-id:in-reply-to:subject:cc:to:from :date:from:to:cc:subject:date:message-id:reply-to; bh=Bz/XOU6GJUjnIHziBMa/ejaxLXDiuXn3yPYLfVwKjWo=; b=JYtZASgM2lwLgZDGiEc7AcXen/GdODpD/C5a71H34awMTkbg9Y+6NkJaEUY2rb21+L 5JOhdRlhOtEH8INtsN9Cs7F48QycL5M0ruHv7U035eX3jXabdqtTABD8ZXaUJHaaNFqm dnSLLPA6PC/fivPlw+CRNpMmYIm4J1VwuuknFQTSw0JLt8YNksTe6fg6M4KzvLsXIxwz rs+QQAayIutNovQeyukeWasg5Qo+HkFBbdGP5y33EdwnTUZl8tVib3d7rOBYj5li6yzT NmIq9N/AvQBr2xBX5+GpIvV6QwlfTuUWrrGDdRYOh4oZeRkpSDUyxKIJmXwAam9MMycf 9RDQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1744866216; x=1745471016; h=mime-version:references:message-id:in-reply-to:subject:cc:to:from :date:x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=Bz/XOU6GJUjnIHziBMa/ejaxLXDiuXn3yPYLfVwKjWo=; b=DsNlH7QzpzUu4p72/oXFDmEYEM507+efEeTMuRMy/P569bNVfqRevyJ9facFo7dV45 WtOV3zcV7hpnf+0nEku7LocECjcZSUumtkKcFnovD6RO/XVUqCUL+ewS7TEpz5S2hQDK Ert1ULiZoSKw2lkPdxm/wTqh04Ku4EHlt5nZH/u36lcSBmQaOpmlBoEKGDT6pJ8a0JfJ fKhJqhWt+9qw50L03qZVtJtZTy1h/L0vXfLmMOYH8OhMxlQOsV/UCl25FD6yAZJBKoOf vVjmorM/TVz2at2w4qa7ajUbQDEZ2MdVId2Ff96KQ1L8ViDMUt79ErYRPa8vkw16TqjR LXBQ== X-Forwarded-Encrypted: i=1; AJvYcCUXjbvnlMjIymY/+5GVutDvfK8YjRcI3kTVKSjQv9P3EdXX+OkQ/nhB0rCZuYgk3mFgObTNZY0Vqg==@kvack.org X-Gm-Message-State: AOJu0YxmgkX9V7RwnyZWNghYmk1hiwKnFjh84NKQt77wOnRTlv/wtY6L JssRWUHoAtAuQkK1o+OipD9peZageOw7c0bOm7j4YoTow+nHo3IyW4nEVA9PXw== X-Gm-Gg: ASbGncvYX5m2mLMC+6NZ0yrnBCO6/DqhOldKwrZPGbFztlxBeretw0Q9L/oLUqDgekm 5ZmLBgYbKKHAvDLT0LEw/MdSNP1+Gi4vdHhVPYsBlADVpzKaOQj2g0dKTT8DlId6WGwTchVEkdm 5bRFZCy8hztkWJXCOSAbLW6nA4rliSgsrmuFqGaFxOEODoXcUtTRtMa+dlJutMiSOjJKzKxMsNC wYU3J7grRTdgtelXKHbtNlTMEmK8Sdz9vOpIWmKVJWJ0OG/dCXEs39uvnfEkdPfjD4nnn06lI+F AKjVlCVamNoN2rHKtRuJMIP0to3I+g0b60nh/x7rigOrpdFU25qTbQSZsQdmyLjZhnhKb0nUtWE 6gmV6P4cgnJHtblI9WEKtRAub X-Google-Smtp-Source: AGHT+IERG0jv4hzWyJchJgTRcqJ4HywpEjypOZy8IrUAQQsiFDrXebt5WGosFtJLR6VQALxZ6cQziw== X-Received: by 2002:a17:902:c405:b0:224:2384:5b40 with SMTP id d9443c01a7336-22c35916c90mr72088015ad.24.1744866216101; Wed, 16 Apr 2025 22:03:36 -0700 (PDT) Received: from darker.attlocal.net (172-10-233-147.lightspeed.sntcca.sbcglobal.net. [172.10.233.147]) by smtp.gmail.com with ESMTPSA id d9443c01a7336-22c33fa5f59sm24056305ad.129.2025.04.16.22.03.34 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 16 Apr 2025 22:03:35 -0700 (PDT) Date: Wed, 16 Apr 2025 22:03:33 -0700 (PDT) From: Hugh Dickins To: Zi Yan cc: Gavin Guo , linux-mm@kvack.org, akpm@linux-foundation.org, willy@infradead.org, linmiaohe@huawei.com, hughd@google.com, revest@google.com, kernel-dev@igalia.com, linux-kernel@vger.kernel.org, stable@vger.kernel.org, Naoya Horiguchi Subject: Re: [PATCH] mm/huge_memory: fix dereferencing invalid pmd migration entry In-Reply-To: Message-ID: References: <20250414072737.1698513-1-gavinguo@igalia.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="-1463770367-916831765-1744866215=:4537" X-Stat-Signature: btswcmhbftpnxdm181nkcacej5cs36bj X-Rspamd-Server: rspam01 X-Rspamd-Queue-Id: 94C2816000B X-Rspam-User: X-HE-Tag: 1744866217-556756 X-HE-Meta: U2FsdGVkX18kb1ZXB+LsxDRNqe52c0ESnad6a5ICBAnHls3Z2hRTEvk8nMDn1cX8La0uAxrLnMMm52eFBIbK3sMTOLjQcrI11IUQtMKMQuPPH158pW1yYaMm5nHJ2WyWJxraZ1LM7iaVB99iUE+ifuTmMLrzFdgEmEM63LGDnS5OswPdV2cvCkmyji1on8nIEMHLnZ/+W8JyTZHACH7yfqEtuLW1swXAo4GaxNP3VdMSEgReam+/1PXzWIunzYchePrNwP+pnUrKRbHr+Tjrb3+U3yqLqYUB4usWont1t9gKtyXzZJRCozQutgxt3HJK2FNF9EfCC5qKq64zeyruUUJ0ztXBsje2jzN7D/2OAvzSj2Ie6gBEK6+v0PLpWSB0WmHgdwJG9IGsJPZdSs1pBRIT58idkj1fMGDDGuvAD6sdFfkl1eVXWA7j/xMhFWauZbEN+9LaAl9MthoABESwPPkQI39tQv6P90D4iLGVh7Loc+1mNbhIT2A+iQa1yf9nwRnhsiOGoJAZ2fMabFoVEeZoSI0U+0kLasKgoSrDLC6jlc3c5eDaK4AAloVZ1wEm+XZ6hnCWYptJfYqpf+1OVpjU0PduaFzmj8J8YoCGz9G5yrWwVGTJQeJOx11PU4XnvAqprg+toTvLerTzpHqPtlmFE0c5r001fpOJd4Yledfygznu125cE+5wOqF6oTr84CnoUW6t7SH9UuVnongiFiOFuA8cYjcWDDgB48v8Tmbr6x9t27OwnqzB9ktfRqMdxour1xgMnYamf33NK7ZksGDSqVYjcK6Yh4cueTDV3+SUgqlEuOct6OvXizHBb2aLSA6oBG2OPf+QKO4Lo9PPMG8cTUQ93pGlj4FBjrZn/LHYNrKiEb4824/VtR0z2lOItmuPsJK7pgR8SbJ2hYh49V0aw+K5RVdepoAlKBfXjs5jlPM5UOE7IoGbiCe5WrhMh7gnZMS4tTe9Uz+yHeI kal4UZEG plcwSPSFrmzM17XZKIjkLiCh5Ri1uM5Tt1OYJw4sdUznfsDiw3p/+eW7YC5vyByFgnb2nVkDBwrVqUhbX34lwwFpFVM9d7+ngiiWHirNoqnqGyk7LgBeRRdph37LDgwrTlFZTn0e/WJH0uB1KnS54hKlxloEMUkUUbrA6eP3R8CZw5rYYavNmNAxrsOhk5QaTgebtHdxdgF8/RaVSMmnCdNcVpyOVPHJCVgwDhPFQ3RkijWjkinJNp07/DUVYW9Lg/qk4FWK6a+NMtBD1fhKFqoHDD2FXQQNXqD/kCIHRk19cCFnN4PebKWyB9L4nN+WbVUiW9cHQf/zo/6KNZBT67aX2uFCb0r2Sg9CNmEghGUZjz/IVJUjV6sq2lhj/9e6phNlYMPLaRoBX5Wb8h9W9X7RMDU3sxsMlCC+CgUkaE4h0zVgzdpRm7PgqR7uQ//UpiOKejxG4iHyHn32Ahy02mgteCfuP4FmJ5g8XihJwiUg2Eoa+kSCiD/c+wWCEH5z1f3I19lBCjcfHv0zu8zIjh6RN8Wj5mZGftGp4buJ+yGp0URkkoyDPuxEVs5heV2Fu5ila 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: This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. ---1463770367-916831765-1744866215=:4537 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: QUOTED-PRINTABLE On Mon, 14 Apr 2025, Zi Yan wrote: > On 14 Apr 2025, at 3:27, Gavin Guo wrote: >=20 > > When migrating a THP, concurrent access to the PMD migration entry > > during a deferred split scan can lead to a page fault, as illustrated >=20 > It is an access violation, right? Because pmd_folio(*pmd_migration_entry) > does not return a folio address. Page fault made this sounded like not > a big issue. >=20 > > below. To prevent this page fault, it is necessary to check the PMD > > migration entry and return early. In this context, there is no need to > > use pmd_to_swp_entry and pfn_swap_entry_to_page to verify the equality > > of the target folio. Since the PMD migration entry is locked, it cannot > > be served as the target. >=20 > You mean split_huge_pmd_address() locks the PMD page table, so that > page migration cannot proceed, or the THP is locked by migration, > so that it cannot be split? The sentence is a little confusing to me. No, split_huge_pmd_address() locks nothing. But its caller holds the folio lock on this folio (as split_huge_pmd_locked() asserts with a=20 VM_WARN_ON_ONCE); and page migration holds folio lock on its folio (as various swapops.h functions assert with BUG_ON). So any PMD migration entry found here cannot be for the folio which split_huge_pmd_address() is passing down. (And even if the impossible did occur, what woud we want to do? Skip it as the patch does.) >=20 > > > > BUG: unable to handle page fault for address: ffffea60001db008 > > CPU: 0 UID: 0 PID: 2199114 Comm: tee Not tainted 6.14.0+ #4 NONE > > Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-= 1.16.3-2 04/01/2014 > > RIP: 0010:split_huge_pmd_locked+0x3b5/0x2b60 > > Call Trace: > > > > try_to_migrate_one+0x28c/0x3730 > > rmap_walk_anon+0x4f6/0x770 > > unmap_folio+0x196/0x1f0 > > split_huge_page_to_list_to_order+0x9f6/0x1560 > > deferred_split_scan+0xac5/0x12a0 > > shrinker_debugfs_scan_write+0x376/0x470 > > full_proxy_write+0x15c/0x220 > > vfs_write+0x2fc/0xcb0 > > ksys_write+0x146/0x250 > > do_syscall_64+0x6a/0x120 > > entry_SYSCALL_64_after_hwframe+0x76/0x7e > > > > The bug is found by syzkaller on an internal kernel, then confirmed on > > upstream. > > > > Fixes: 84c3fc4e9c56 ("mm: thp: check pmd migration entry in common path= ") > > Cc: stable@vger.kernel.org > > Signed-off-by: Gavin Guo > > --- > > mm/huge_memory.c | 18 ++++++++++++++---- > > 1 file changed, 14 insertions(+), 4 deletions(-) > > > > diff --git a/mm/huge_memory.c b/mm/huge_memory.c > > index 2a47682d1ab7..0cb9547dcff2 100644 > > --- a/mm/huge_memory.c > > +++ b/mm/huge_memory.c > > @@ -3075,6 +3075,8 @@ static void __split_huge_pmd_locked(struct vm_are= a_struct *vma, pmd_t *pmd, > > void split_huge_pmd_locked(struct vm_area_struct *vma, unsigned long a= ddress, > > =09=09=09 pmd_t *pmd, bool freeze, struct folio *folio) > > { > > +=09bool pmd_migration =3D is_pmd_migration_entry(*pmd); > > + > > =09VM_WARN_ON_ONCE(folio && !folio_test_pmd_mappable(folio)); > > =09VM_WARN_ON_ONCE(!IS_ALIGNED(address, HPAGE_PMD_SIZE)); > > =09VM_WARN_ON_ONCE(folio && !folio_test_locked(folio)); > > @@ -3085,10 +3087,18 @@ void split_huge_pmd_locked(struct vm_area_struc= t *vma, unsigned long address, > > =09 * require a folio to check the PMD against. Otherwise, there > > =09 * is a risk of replacing the wrong folio. > > =09 */ > > -=09if (pmd_trans_huge(*pmd) || pmd_devmap(*pmd) || > > -=09 is_pmd_migration_entry(*pmd)) { > > -=09=09if (folio && folio !=3D pmd_folio(*pmd)) > > -=09=09=09return; > > +=09if (pmd_trans_huge(*pmd) || pmd_devmap(*pmd) || pmd_migration) { > > +=09=09if (folio) { > > +=09=09=09/* > > +=09=09=09 * Do not apply pmd_folio() to a migration entry; and > > +=09=09=09 * folio lock guarantees that it must be of the wrong > > +=09=09=09 * folio anyway. >=20 > Why does the folio lock imply it is a wrong folio? Because you cannot have two tasks holding folio lock on the same folio at the same time. So therefore it is a different ("wrong") folio. >=20 > > +=09=09=09 */ > > +=09=09=09if (pmd_migration) > > +=09=09=09=09return; > > +=09=09=09if (folio !=3D pmd_folio(*pmd)) > > +=09=09=09=09return; > > +=09=09} >=20 > Why not just >=20 > if (folio && pmd_migration) > =09return; That looks nicer, less indentation, I agree. But Gavin's patch is keeping the relevant check next to the "pmd_folio(*pmd)" to be avoided: also good. I have no opinion which is the better. Hugh >=20 > if (pmd_trans_huge() =E2=80=A6) { > =09=E2=80=A6 > } > ? >=20 > Thanks. >=20 > Best Regards, > Yan, Zi >=20 ---1463770367-916831765-1744866215=:4537--