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 4231CC021B2 for ; Thu, 20 Feb 2025 22:20:06 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 9CF00280003; Thu, 20 Feb 2025 17:20:05 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 95823280002; Thu, 20 Feb 2025 17:20:05 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 7B468280003; Thu, 20 Feb 2025 17:20:05 -0500 (EST) 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 54D69280002 for ; Thu, 20 Feb 2025 17:20:05 -0500 (EST) Received: from smtpin19.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay01.hostedemail.com (Postfix) with ESMTP id BABD11C905A for ; Thu, 20 Feb 2025 22:20:04 +0000 (UTC) X-FDA: 83141741928.19.755C2D6 Received: from mail-qt1-f169.google.com (mail-qt1-f169.google.com [209.85.160.169]) by imf16.hostedemail.com (Postfix) with ESMTP id C350418000B for ; Thu, 20 Feb 2025 22:20:02 +0000 (UTC) Authentication-Results: imf16.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=DqMiSYvh; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf16.hostedemail.com: domain of lokeshgidra@google.com designates 209.85.160.169 as permitted sender) smtp.mailfrom=lokeshgidra@google.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1740090002; a=rsa-sha256; cv=none; b=j4DaIG9w7qBRkZP807tKMeBgy/lauLHchfNgNl+OazhOeDM/Wqo8DikojKNK6OawBQEgzm AaVizJEMa1P7G9CmwZzx/A1lOx6RcwjkqF2r9TtoxLa7TBse7ecbcKeNwhC6igjV+I6JG0 GBh3AfrQOOsD/yn4p6ugTyN8UKlmu4E= ARC-Authentication-Results: i=1; imf16.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=DqMiSYvh; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf16.hostedemail.com: domain of lokeshgidra@google.com designates 209.85.160.169 as permitted sender) smtp.mailfrom=lokeshgidra@google.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1740090002; 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:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=Ws1mxNCaqudQYGOTCFpMc5aJcgQ6tHaTFSk5mK5zkQ0=; b=p6lVY/kMJvC5pXx/y/ND3DmVOqeLNzL7iKSnvEP+QnsvMLqlB9ygKCA9e/gwRZeKvQriAS jIetVAzdiw80sRy8Aphub7ZO/vpcrjVmIAKPQLA8OEA4DaUBjlU6Gn+/U9dNVL4TMx6MVi M2to9V54dng4Pcd6NzCgpx/xX6/XYgI= Received: by mail-qt1-f169.google.com with SMTP id d75a77b69052e-471fbfe8b89so126671cf.0 for ; Thu, 20 Feb 2025 14:20:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1740090002; x=1740694802; darn=kvack.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=Ws1mxNCaqudQYGOTCFpMc5aJcgQ6tHaTFSk5mK5zkQ0=; b=DqMiSYvhvNpdQZ2EBoVG1dWZwwE9t8FxmJDouPCf7Y0lV8CumgVuISqrBTYA+9zXSf wVOmRDskChevp/EvHLEZmli5KSb2dLyIz45KFdhzoDF7sIT7tdFprzSYKdtHUnqGmilh m37s6AdF92my9cXJ9f5jPkojDyuETJILgPyh1NqwY4OrQKuUCc220FBuhK15cMEMOt2K 3PQIbGGZeHIL7lc7pJ8gSpIV00DN3OhtP2PZCAEt53jMlG50G0gzQM4QQF5lh6s9ZwUx 2kJ3ddgGzQY/RRoNsv8kF0bAZcBxnHxYiW2bFIy2AL8YD+E8FlC6Cx0EgHLl+4ni9vSR tNMA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1740090002; x=1740694802; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=Ws1mxNCaqudQYGOTCFpMc5aJcgQ6tHaTFSk5mK5zkQ0=; b=hMcRaSzxXoKfguKjxZ9IqZQed4VeJWgQeOUZNmfBJoKwfecf7vCkWeOWdsxTVtcLfr jyUSYG/+gYYoeqGBmtT06cAicEKSiYmWHtUSDJXAUXLYOPQGe3uFge80JXifb2WRnRlP T3TXWTk9gwa6I19J44JIW/+CTnOOy5X8psvcjRhPlwGxAV64mTT/PzAIDVFRySZjDjPv c5u0MeSk7SCZ43ViBDOCV6gYc5eAyC0tBYl/UkAJPYw0D3rxRaVvWm5W+TrbGKxa2QW3 9/AmRMzqV4ny29w5752U/fITpWLn2UUcZP46PSmJduMO97B0th34HtnjsqWZW3jlgoqz ylww== X-Forwarded-Encrypted: i=1; AJvYcCVDqTVa0NkjmWNixTpBLCVNT5Jv7efROEK38JYpdgcMHFkLZCSU6DQNjSJOwL94ovhqrKmx53YABg==@kvack.org X-Gm-Message-State: AOJu0YxAVODIjcE8H2N6eCrHsbO1zx8HsbP234y2mz3tquXfIq7lcP9L 8M+Mp71uoDnJNCVAajQyjH9fUw02/7TlJ6drmxyKX5KYsqZWvEDnEL87G/bjpltS7JPF+0j6g4E HKuNrGBS7YqBsrwat9CZAg0mWC13GwJqTAX7T X-Gm-Gg: ASbGncuKlBhzQzPIeCZ10VtiH9WK8NOaOz+PjOvMF/74Z0oBU/XtqGTYs7FwhGTfIGX XFE6UWtoNIsOzWwAJCTXPp9FV2qnz0xFAXI0K7xEzFmh38hslBxhqVjJz/CWGFyuWUiYyFPq3Ke ZUzv3hNB+slnGQVrNpUQS/M0RzH5qm2A== X-Google-Smtp-Source: AGHT+IG3hNz1+k6EELhlv29FwxqaYLlC1zT6N4BqFkX6kbPz2waKlQXuShmiNO9w2CHirf8JFmkVXWqfykkcA4phMiE= X-Received: by 2002:a05:622a:6094:b0:466:8c23:823a with SMTP id d75a77b69052e-472250e8f04mr133001cf.17.1740090001575; Thu, 20 Feb 2025 14:20:01 -0800 (PST) MIME-Version: 1.0 References: <20250219112519.92853-1-21cnbao@gmail.com> <50566d42-7754-4017-b290-f29d92e69231@redhat.com> In-Reply-To: From: Lokesh Gidra Date: Thu, 20 Feb 2025 14:19:50 -0800 X-Gm-Features: AWEUYZkP0ytyZraQfhTJR-GbWECW1nnABA9ah3IKOei0AmLqTmYtA-lIHvymfiI Message-ID: Subject: Re: [PATCH RFC] mm: Fix kernel BUG when userfaultfd_move encounters swapcache To: Barry Song <21cnbao@gmail.com> Cc: David Hildenbrand , Suren Baghdasaryan , linux-mm@kvack.org, akpm@linux-foundation.org, linux-kernel@vger.kernel.org, zhengtangquan@oppo.com, Barry Song , Andrea Arcangeli , Al Viro , Axel Rasmussen , Brian Geffon , Christian Brauner , Hugh Dickins , Jann Horn , Kalesh Singh , "Liam R . Howlett" , Matthew Wilcox , Michal Hocko , Mike Rapoport , Nicolas Geoffray , Peter Xu , Ryan Roberts , Shuah Khan , ZhangPeng , Yu Zhao Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspam-User: X-Rspamd-Queue-Id: C350418000B X-Rspamd-Server: rspam12 X-Stat-Signature: 6mffct84p7yo8jzidsyyhqbqz6ob6ghc X-HE-Tag: 1740090002-402017 X-HE-Meta: U2FsdGVkX1++FECeYsw0aX02pCegMcXpV4S5t4OyoYRveyjPavnwAjYiIE4njXSDtsAJoqC0ytEz5J9mhx5s4QyWvfjOLVBFcLRWzal94983pRhwbRv1NmUwXwT614Xr7dqb94N6fHN/GhtAB+4T21hg3gc+TtIVtbBVrU3I3K3F6k6KF1WaM7G4FBoaEkKGD6+M3S0xat+ib/B0WZwgWz869XQ/hCBRHvQ44/fM2sgJEjr8HN7a8LA2AWTdYJuW6ZpsR9/NY4VV0nwLuQdzA3oyoN5z8g+ZSj55Mn5neO29asIUePiIEA6R4lUlMeNWS+ghGt38ytp7UzoBz74fgTjGB02E7uS9zB6tIeDJn93DegYQIwkgMLNNv1Adij2juVbjC2lW4qPgnMNYAxZ/5gSwkzBD/wr3ZWAlMcgqgNjtwbymY6e+a0PvkA5CsN/a0oT/Ky2NlYWcw/sfkOoenk1oNsUO+TDbhgbI5hUnVDGt7cit0kowJCoJIAvozrfwkXklhAKnTF2AHhAc+vPUjud2eBzxcG4xmF/aZbmaKODzTo1RerzdbNy5kGysZy53Mo6XUA0PlOTkEKLLSYH5xcpLcJq5DtGH2sZSRXkFj6oxrPVpBpweRRDhfzkqxLzFe+aKgpa2kauEItKDeDA2tvwHYUMLqa2oVjftH53gBlwlk6Par5jRgeGjj1IY949RVA/+ZwS/ZXWehBt2MqgmXVuuw4agjj1RIC5vhVk/kCVgIuZMSYABLrphJPiJc0gw4JcYYFyQbLJuvNOuS1QNKZZwYo7vM4Ysrlx2oX85KyCOUbvoy3RU1+/gmb9tXAQOrf7cIe0T5eiPEij7q7ZKmt3VpeRBW3KT0gkwiEgvGch0CyW4VHBYKkN2ZEp83MJAQSirID3yUhMkmydUhYwSs8xzCU3LzG87OvaG8MVeRy1U+rirX+gymjt1osuZY5KY/1fyEzGgoSGq3JJFdoC ejeNr+HW w2xQv+yl+Fu446j3pxC+DUZACLGL1mKqHWLijdweRQvIDNW53vZgHoGc5/8icyj22QK2WjUjUKMYMhbtYIPU2u7P98yrh7Z/AV1j8m1u/KynbdGkyLqsr5lFmTEfh3raj4IrSZ23k5jACYpEkgMHHxb+A6u6JzUU6KZeMflP48J3Vab1rmHUvEKIFblK34lD4TjK7yuBU/b/pJSxtcSIo/H3YGmCUXztL8AsNhrBEs5O/tZxVpIxwmnfKdCIg2l32Z8nDvRjtEFcOcIGAsDUTqyM5aL3vWQoBxETfcmqMBBOTNnK+grRjYwk0L1cFSSlCI8lEizeTMGRU9pp6RaxW8x9/dnoWxY+YBBAKeTTTyW/SqUI= 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: On Thu, Feb 20, 2025 at 1:45=E2=80=AFPM Barry Song <21cnbao@gmail.com> wrot= e: > > On Thu, Feb 20, 2025 at 10:36=E2=80=AFPM David Hildenbrand wrote: > > > > On 20.02.25 10:31, Barry Song wrote: > > > On Thu, Feb 20, 2025 at 9:51=E2=80=AFPM David Hildenbrand wrote: > > >> > > >> On 19.02.25 21:37, Barry Song wrote: > > >>> On Thu, Feb 20, 2025 at 7:27=E2=80=AFAM Suren Baghdasaryan wrote: > > >>>> > > >>>> On Wed, Feb 19, 2025 at 3:25=E2=80=AFAM Barry Song <21cnbao@gmail.= com> wrote: > > >>>>> > > >>>>> From: Barry Song > > >>>>> > > >>>>> userfaultfd_move() checks whether the PTE entry is present or a > > >>>>> swap entry. > > >>>>> > > >>>>> - If the PTE entry is present, move_present_pte() handles folio > > >>>>> migration by setting: > > >>>>> > > >>>>> src_folio->index =3D linear_page_index(dst_vma, dst_addr); > > >>>>> > > >>>>> - If the PTE entry is a swap entry, move_swap_pte() simply copies > > >>>>> the PTE to the new dst_addr. > > >>>>> > > >>>>> This approach is incorrect because even if the PTE is a swap > > >>>>> entry, it can still reference a folio that remains in the swap > > >>>>> cache. > > >>>>> > > >>>>> If do_swap_page() is triggered, it may locate the folio in the > > >>>>> swap cache. However, during add_rmap operations, a kernel panic > > >>>>> can occur due to: > > >>>>> page_pgoff(folio, page) !=3D linear_page_index(vma, address) > > >>>> > > >>>> Thanks for the report and reproducer! > > >>>> > > >>>>> > > >>>>> $./a.out > /dev/null > > >>>>> [ 13.336953] page: refcount:6 mapcount:1 mapping:00000000f43db1= 9c index:0xffffaf150 pfn:0x4667c > > >>>>> [ 13.337520] head: order:2 mapcount:1 entire_mapcount:0 nr_page= s_mapped:1 pincount:0 > > >>>>> [ 13.337716] memcg:ffff00000405f000 > > >>>>> [ 13.337849] anon flags: 0x3fffc0000020459(locked|uptodate|dirt= y|owner_priv_1|head|swapbacked|node=3D0|zone=3D0|lastcpupid=3D0xffff) > > >>>>> [ 13.338630] raw: 03fffc0000020459 ffff80008507b538 ffff8000850= 7b538 ffff000006260361 > > >>>>> [ 13.338831] raw: 0000000ffffaf150 0000000000004000 00000006000= 00000 ffff00000405f000 > > >>>>> [ 13.339031] head: 03fffc0000020459 ffff80008507b538 ffff800085= 07b538 ffff000006260361 > > >>>>> [ 13.339204] head: 0000000ffffaf150 0000000000004000 0000000600= 000000 ffff00000405f000 > > >>>>> [ 13.339375] head: 03fffc0000000202 fffffdffc0199f01 ffffffff00= 000000 0000000000000001 > > >>>>> [ 13.339546] head: 0000000000000004 0000000000000000 00000000ff= ffffff 0000000000000000 > > >>>>> [ 13.339736] page dumped because: VM_BUG_ON_PAGE(page_pgoff(fol= io, page) !=3D linear_page_index(vma, address)) > > >>>>> [ 13.340190] ------------[ cut here ]------------ > > >>>>> [ 13.340316] kernel BUG at mm/rmap.c:1380! > > >>>>> [ 13.340683] Internal error: Oops - BUG: 00000000f2000800 [#1] = PREEMPT SMP > > >>>>> [ 13.340969] Modules linked in: > > >>>>> [ 13.341257] CPU: 1 UID: 0 PID: 107 Comm: a.out Not tainted 6.1= 4.0-rc3-gcf42737e247a-dirty #299 > > >>>>> [ 13.341470] Hardware name: linux,dummy-virt (DT) > > >>>>> [ 13.341671] pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -S= SBS BTYPE=3D--) > > >>>>> [ 13.341815] pc : __page_check_anon_rmap+0xa0/0xb0 > > >>>>> [ 13.341920] lr : __page_check_anon_rmap+0xa0/0xb0 > > >>>>> [ 13.342018] sp : ffff80008752bb20 > > >>>>> [ 13.342093] x29: ffff80008752bb20 x28: fffffdffc0199f00 x27: 0= 000000000000001 > > >>>>> [ 13.342404] x26: 0000000000000000 x25: 0000000000000001 x24: 0= 000000000000001 > > >>>>> [ 13.342575] x23: 0000ffffaf0d0000 x22: 0000ffffaf0d0000 x21: f= ffffdffc0199f00 > > >>>>> [ 13.342731] x20: fffffdffc0199f00 x19: ffff000006210700 x18: 0= 0000000ffffffff > > >>>>> [ 13.342881] x17: 6c203d2120296567 x16: 6170202c6f696c6f x15: 6= 62866666f67705f > > >>>>> [ 13.343033] x14: 6567617028454741 x13: 2929737365726464 x12: f= fff800083728ab0 > > >>>>> [ 13.343183] x11: ffff800082996bf8 x10: 0000000000000fd7 x9 : f= fff80008011bc40 > > >>>>> [ 13.343351] x8 : 0000000000017fe8 x7 : 00000000fffff000 x6 : f= fff8000829eebf8 > > >>>>> [ 13.343498] x5 : c0000000fffff000 x4 : 0000000000000000 x3 : 0= 000000000000000 > > >>>>> [ 13.343645] x2 : 0000000000000000 x1 : ffff0000062db980 x0 : 0= 00000000000005f > > >>>>> [ 13.343876] Call trace: > > >>>>> [ 13.344045] __page_check_anon_rmap+0xa0/0xb0 (P) > > >>>>> [ 13.344234] folio_add_anon_rmap_ptes+0x22c/0x320 > > >>>>> [ 13.344333] do_swap_page+0x1060/0x1400 > > >>>>> [ 13.344417] __handle_mm_fault+0x61c/0xbc8 > > >>>>> [ 13.344504] handle_mm_fault+0xd8/0x2e8 > > >>>>> [ 13.344586] do_page_fault+0x20c/0x770 > > >>>>> [ 13.344673] do_translation_fault+0xb4/0xf0 > > >>>>> [ 13.344759] do_mem_abort+0x48/0xa0 > > >>>>> [ 13.344842] el0_da+0x58/0x130 > > >>>>> [ 13.344914] el0t_64_sync_handler+0xc4/0x138 > > >>>>> [ 13.345002] el0t_64_sync+0x1ac/0x1b0 > > >>>>> [ 13.345208] Code: aa1503e0 f000f801 910f6021 97ff5779 (d421000= 0) > > >>>>> [ 13.345504] ---[ end trace 0000000000000000 ]--- > > >>>>> [ 13.345715] note: a.out[107] exited with irqs disabled > > >>>>> [ 13.345954] note: a.out[107] exited with preempt_count 2 > > >>>>> > > >>>>> Fully fixing it would be quite complex, requiring similar handlin= g > > >>>>> of folios as done in move_present_pte. > > >>>> > > >>>> How complex would that be? Is it a matter of adding > > >>>> folio_maybe_dma_pinned() checks, doing folio_move_anon_rmap() and > > >>>> folio->index =3D linear_page_index like in move_present_pte() or > > >>>> something more? > > >>> > > >>> My main concern is still with large folios that require a split_fol= io() > > >>> during move_pages(), as the entire folio shares the same index and > > >>> anon_vma. However, userfaultfd_move() moves pages individually, > > >>> making a split necessary. > > >>> > > >>> However, in split_huge_page_to_list_to_order(), there is a: > > >>> > > >>> if (folio_test_writeback(folio)) > > >>> return -EBUSY; > > >>> > > >>> This is likely true for swapcache, right? However, even for move_pr= esent_pte(), > > >>> it simply returns -EBUSY: > > >>> > > >>> move_pages_pte() > > >>> { > > >>> /* at this point we have src_folio locked */ > > >>> if (folio_test_large(src_folio)) { > > >>> /* split_folio() can block */ > > >>> pte_unmap(&orig_src_pte); > > >>> pte_unmap(&orig_dst_pte); > > >>> src_pte =3D dst_pte =3D NULL; > > >>> err =3D split_folio(src_folio); > > >>> if (err) > > >>> goto out; > > >>> > > >>> /* have to reacquire the folio after it g= ot split */ > > >>> folio_unlock(src_folio); > > >>> folio_put(src_folio); > > >>> src_folio =3D NULL; > > >>> goto retry; > > >>> } > > >>> } > > >>> > > >>> Do we need a folio_wait_writeback() before calling split_folio()? > > >>> > > >>> By the way, I have also reported that userfaultfd_move() has a fund= amental > > >>> conflict with TAO (Cc'ed Yu Zhao), which has been part of the Andro= id common > > >>> kernel. In this scenario, folios in the virtual zone won=E2=80=99t = be split in > > >>> split_folio(). Instead, the large folio migrates into nr_pages smal= l folios. > > >> > > Thus, the best-case scenario would be: > > >>> > > >>> mTHP -> migrate to small folios in split_folio() -> move small foli= os to > > >>> dst_addr > > >>> > > >>> While this works, it negates the performance benefits of > > >>> userfaultfd_move(), as it introduces two PTE operations (migration = in > > >>> split_folio() and move in userfaultfd_move() while retry), nr_pages= memory > > >>> allocations, and still requires one memcpy(). This could end up > > >>> performing even worse than userfaultfd_copy(), I guess. > > >> > > The worst-case scenario would be failing to allocate small fol= ios in > > >>> split_folio(), then userfaultfd_move() might return -ENOMEM? > > >> > > >> Although that's an Android problem and not an upstream problem, I'll > > >> note that there are other reasons why the split / move might fail, a= nd > > >> user space either must retry or fallback to a COPY. > > >> > > >> Regarding mTHP, we could move the whole folio if the user space-prov= ided > > >> range allows for batching over multiple PTEs (nr_ptes), they are in = a > > >> single VMA, and folio_mapcount() =3D=3D nr_ptes. > > >> > > >> There are corner cases to handle, such as moving mTHPs such that the= y > > >> suddenly cross two page tables I assume, that are harder to handle w= hen > > >> not moving individual PTEs where that cannot happen. > > > > > > This is a useful suggestion. I=E2=80=99ve heard that Lokesh is also i= nterested in > > > modifying ART to perform moves at the mTHP granularity, which would r= equire > > > kernel modifications as well. It=E2=80=99s likely the direction we=E2= =80=99ll take after > > > fixing the current urgent bugs. The current split_folio() really isn= =E2=80=99t ideal. > > > > > > The corner cases you mentioned are definitely worth considering. Howe= ver, > > > once we can perform batch UFFDIO_MOVE, I believe that in most cases, > > > the conflict between userfaultfd_move() and TAO will be resolved ? > > > > Well, as soon as you would have varying mTHP sizes, you'd still run int= o > > the split with TAO. Maybe that doesn't apply with Android today, but I > > can just guess that performing sub-mTHP moving would still be required > > for GC at some point. > > With patch v2[1], as discussed in my previous email, I have observed that > small folios consistently succeed without crashing. Similarly, mTHP no > longer crashes; however, it still returns -EBUSY during the raced time > window, even after adding folio_wait_writeback. While I previously > mentioned that folio_writeback prevents mTHP from splitting, this is not > the only factor. The split_folio() function still returns -EBUSY because > folio_get_anon_vma(folio) returns NULL when the folio is not mapped. > > int split_huge_page_to_list_to_order(struct page *page, struct list_head = *list, > unsigned int new_order) > { > anon_vma =3D folio_get_anon_vma(folio); > if (!anon_vma) { > ret =3D -EBUSY; > goto out; > } > > end =3D -1; > mapping =3D NULL; > anon_vma_lock_write(anon_vma); > } > > Even if mTHP is not from TAO's virtual zone, userfaultfd_move() will stil= l > fail when performing sub-mTHP moving in the swap cache case due to: Just to clarify my doubt. What do you mean by sub-mTHP? Also when you say 'small folio' above, do you mean single-page folios? Am I understanding correctly that your patch correctly handles moving single swap-cache page case? > > struct anon_vma *folio_get_anon_vma(const struct folio *folio) > { > ... > if (!folio_mapped(folio)) > goto out; > ... > } > > We likely need to modify split_folio() to support splitting unmapped anon > folios within the swap cache or introduce a new function like > split_unmapped_anon_folio()? Otherwise, userspace will have to fall back > to UFFDIO_COPY or retry. > > As it stands, I see no way for sub-mTHP to survive moving with the curren= t > code and within the existing raced window. For mTHP, there is essentially > no difference between returning -EBUSY immediately upon detecting that it > is within the swap cache, as proposed in v1. > > [1] https://lore.kernel.org/linux-mm/20250220092101.71966-1-21cnbao@gmail= .com/ > > > > > -- > > Cheers, > > > > David / dhildenb > > > > Thanks > Barry