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 740D3C021BB for ; Wed, 26 Feb 2025 01:00:30 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 0F736280003; Tue, 25 Feb 2025 20:00:30 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 07FF8280002; Tue, 25 Feb 2025 20:00:29 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id DED7A280003; Tue, 25 Feb 2025 20:00:29 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0015.hostedemail.com [216.40.44.15]) by kanga.kvack.org (Postfix) with ESMTP id B0A6B280002 for ; Tue, 25 Feb 2025 20:00:29 -0500 (EST) Received: from smtpin17.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay10.hostedemail.com (Postfix) with ESMTP id 2EA87C0660 for ; Wed, 26 Feb 2025 01:00:29 +0000 (UTC) X-FDA: 83160290178.17.7A0D9C0 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by imf01.hostedemail.com (Postfix) with ESMTP id A1E5040016 for ; Wed, 26 Feb 2025 01:00:26 +0000 (UTC) Authentication-Results: imf01.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b=JMQVbLv7; dmarc=pass (policy=none) header.from=redhat.com; spf=pass (imf01.hostedemail.com: domain of peterx@redhat.com designates 170.10.133.124 as permitted sender) smtp.mailfrom=peterx@redhat.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1740531626; a=rsa-sha256; cv=none; b=kUx/+6AmjM2qCsnQdSMp8fTuHyBgQwgya33Ez7wz336z+3sTpxOsVvI8++BUXApGrow2sJ u0o6dPlJTWqvTj3DxMyxWCZBCPYLLyKyQgya3oyki0cSFMhVaXjUAzYOnYSz/l3AVqDfbT zVaUk2vdu/vqPvvb4u/k8PLeA6w0brw= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1740531626; 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=LlunlS80VHH5jVGoIKOsJ5HRL508+NZGIkDXyQZb5Ro=; b=P+xNhvxgZVR/9kaWwGm5jK6kigI2QXzV0tgq+Z5U1xuKVFiFbK9yBTjCOT5ndpTyg9K81W 6vyh1djSL7Z4h6twy3XbbmYHNOn9dBY5hP9/M0y2Vt4/sz2sY26+lS0eGIeoVwXU1VYRFl RMXGj/HB8/1htx0wT5YZ9uWhdoiZNRY= ARC-Authentication-Results: i=1; imf01.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b=JMQVbLv7; dmarc=pass (policy=none) header.from=redhat.com; spf=pass (imf01.hostedemail.com: domain of peterx@redhat.com designates 170.10.133.124 as permitted sender) smtp.mailfrom=peterx@redhat.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1740531625; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=LlunlS80VHH5jVGoIKOsJ5HRL508+NZGIkDXyQZb5Ro=; b=JMQVbLv7xXtRUQR8t6sgZB9E/kbO6rrznyNytOZLeeY2oiNmFO09x3AOq+2Zo7jE2/XCyZ fC7I8o5BykArIPhNyJ0NJHS3J9UU1623MkadQA9HZwCUGeNT5oDiHAyQunmjyC6HX1r37p mlmPqFafhnSvGOYNnIinlCQWuiYBLaE= Received: from mail-qv1-f70.google.com (mail-qv1-f70.google.com [209.85.219.70]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-690-kkhYs3amMOy2RNdONmBQ2w-1; Tue, 25 Feb 2025 20:00:24 -0500 X-MC-Unique: kkhYs3amMOy2RNdONmBQ2w-1 X-Mimecast-MFC-AGG-ID: kkhYs3amMOy2RNdONmBQ2w_1740531624 Received: by mail-qv1-f70.google.com with SMTP id 6a1803df08f44-6e66c406bb4so7990616d6.0 for ; Tue, 25 Feb 2025 17:00:24 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1740531624; x=1741136424; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=LlunlS80VHH5jVGoIKOsJ5HRL508+NZGIkDXyQZb5Ro=; b=pNL5R519GG9WvLUfSbGzMpThq4CR4vuV9yp4io3/IBFUQmawmSjK3eFWncb/EDERj2 WxfoOCMlp08LpAlkAGBlvVz8vEQ6MlSVUVzY39Aw4rSyzi9OgXuh8YXE3HODCag+8ss8 37o5tv2oZugoe+3N0GOazNLa6JDi7i+6dNEYsFfv4QChMYrVUZWHcsg5E7THkS+CgfWr 3rEqS2yhY/rmyvl5Kwxye2n31l/yzJvndNiIbd7YqiSZkT4PC44oznEFG4nuE82bIHQG xS2Nv0rNZNT+nzJoKdoZREFyUio6WeM2rz6GoXH7hZud0bichtQJJXpRJENRiZWTcttc e3Sw== X-Gm-Message-State: AOJu0YzxVlFX+XGgUOjTpiKZ29Ymj2cPL3WBmsjtJc6BAMb6GuZO3s8Z 0c7S6w/9QhRoL3UYFsn6A3U7Wg5GpOctenG0luGiZEXqNvP4czfQeqtvk77eD7idPeWmdUJP6Mt g7WZGuZgUiSY5Bkbd6sdE0OItFHIbF2tKauUngm4rvoFknqqh X-Gm-Gg: ASbGncsGm1yKNKtNngeaddK3mYNKQGnUytfpcoVnFUkbnfWW/0ZAhTZARHYRl92T07V mzEbEd8OymN3Mbp2KxxM6RX1c9H3G1ObntofMpMdJZG8YOeIV+DvcWXchK2EElam5ujpasw8EgB VLPfVUpraZH4O6r6fASujKrfQ+wAxROdGtj5IQyHaUm7slTpJ2OnvEdDpHnsNjkhZJ8WOU+sll6 cqbK7PncXrAS8SB6QQLAK/4dugRosBMdHxd+D5flxjv0fJv2isEAl44y+KLFGCw3zCP/Q== X-Received: by 2002:a05:6214:1c43:b0:6e6:646d:7550 with SMTP id 6a1803df08f44-6e6ae8b0dddmr294586616d6.19.1740531623549; Tue, 25 Feb 2025 17:00:23 -0800 (PST) X-Google-Smtp-Source: AGHT+IHU2P9sv6oy5pfSwZSHR05ikYvhpDFMlvn2SB/fC59WzmCk4kPsUvs4Qcp69VXxmPb+ISpcxA== X-Received: by 2002:a05:6214:1c43:b0:6e6:646d:7550 with SMTP id 6a1803df08f44-6e6ae8b0dddmr294585656d6.19.1740531622706; Tue, 25 Feb 2025 17:00:22 -0800 (PST) Received: from x1.local ([2604:7a40:2041:2b00::1000]) by smtp.gmail.com with ESMTPSA id 6a1803df08f44-6e87b06dc62sm16122516d6.1.2025.02.25.17.00.20 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 25 Feb 2025 17:00:22 -0800 (PST) Date: Tue, 25 Feb 2025 20:00:18 -0500 From: Peter Xu To: Barry Song <21cnbao@gmail.com> Cc: linux-mm@kvack.org, akpm@linux-foundation.org, linux-kernel@vger.kernel.org, Barry Song , Andrea Arcangeli , Suren Baghdasaryan , Al Viro , Axel Rasmussen , Brian Geffon , Christian Brauner , David Hildenbrand , Hugh Dickins , Jann Horn , Kalesh Singh , "Liam R . Howlett" , Lokesh Gidra , Matthew Wilcox , Michal Hocko , Mike Rapoport , Nicolas Geoffray , Ryan Roberts , Shuah Khan , ZhangPeng , Tangquan Zheng , stable@vger.kernel.org Subject: Re: [PATCH v2] mm: Fix kernel BUG when userfaultfd_move encounters swapcache Message-ID: References: <20250226001400.9129-1-21cnbao@gmail.com> MIME-Version: 1.0 In-Reply-To: <20250226001400.9129-1-21cnbao@gmail.com> X-Mimecast-Spam-Score: 0 X-Mimecast-MFC-PROC-ID: vb9yiI14vLxakpYKspR7Bjc1T77K3SkzL_778x6qlEw_1740531624 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=utf-8 Content-Disposition: inline X-Rspamd-Queue-Id: A1E5040016 X-Rspamd-Server: rspam08 X-Rspam-User: X-Stat-Signature: b3gbckn4z1keuyry97shuqoqye911pyf X-HE-Tag: 1740531626-793307 X-HE-Meta: U2FsdGVkX1/1Wjb/jgdcT+xyl+4JL/QWjtwEN2tOF6+4pWi4Q8kngN18t03YxhobABh1eeUwdIGx9fglx6cAAmPuBAchC9l98nq0QxzqvE1nWss9gsMMxNb+9QH8s1R52mTaCuMDj1wEAoXDmeKvrXvhM0+AAq+/tMqVnS7LdeGLQjEdQL3cDHvm257uLPBRTLougNvfAKuHiYfmbQ1dyTkq8TjZ22ZPWxjQsn2kL0IWnI9tk6BiVb4dzyCVyEFZcq/5kKCf8hbXrSWVNsaTkhgePAWs3Zkc1Wsc1XVHDBtJPK1nooZ7+Ms836Pmj6US7AsIXNtHvE2YzZbu7wDsJZFplnvLZaDuL9JXatDx+2PZGyrxJtdQ5yQbv1BWGV8/vItSqyoeH3gfbikaKKsyyDoKkHS8G9NorpUuVDk9gGyudBCJ4GzMIsTB2PHjgMaojDqYrCO9SmsnMS/nJyHnbrw31/+MN/EGyjDvk8CvFzF8YmGRfBnobgJidzBb1iWbNd+/mWqtKi+LfUGtlLBX9idUWm8iNh+jEhIAwec8HLK677KEgipFvWmLfCJ0Xhn+0he+HwMJTRR6+LM6wkgBRnIJBn1R7jmz0K8mjBEL9dfucRgbFCDWJeuqa3DaGMBSfgG0kH5K4S5CsFflW87+TWiUkIGMUEvDDf0XFNpjnMNq5X8il4MYDTPqE3mpRtvaWL9CTfo9PYFEl8a7Zu9OoqUyZE0OU2CGATxMQKf9iNG9bJN1U0ICoplmZGRsULW1HQe3UT8i15DU54oJok8V9S2BBqKh6BQqx5Ewvsr5U3gKxOmz177vOjxuJywr70VeN3JxAnDo/0LhT7duOKKaowZ5am34xJrePB01G+3xaSdFaFwTqkjk8T41Fp4VvgxWyGTikr0oXyvvfzcamreef2KpHiYXtyJ8eBIME98ZvZLWNVqtxyVbIERqum8x86KdG6BvFkkOyDe67SODmfa do7yFxz4 RK04UECRQTKBWXYH4QSeUFabwAfoqTAQFLa2jMqVDzPAHwzeLB0fdVQ+yLoS/TzMX6zqbWH8lckYHjEAqdCvj1QR7u1Hl6ODDJdDXBTfWd6iFvZgaQBdLrR5oP20E1QPmDJhOkIF4ZsUMigNNh89bNXhSsMPvghgp2zWMdjCgTe1CM5i8xa3RLdFYd+YB0GucdTtYCJZUMMOrn+hEbWykOiDpqQgUr6lBaacpbdPx91WX3ogdfxggjQEYlQuH7DquYITZMqmhk/mYYvWW65mtNiIcNmjgt1eeZgkJJCgHN0QBmqOOWyzyy+qkBq0q1ZqIZhGYoepn68ixmJMStCpLtZgYLz8KISWrrhs/EGKoJ69VqFPKZO1YHuskS9M5NhVHNUy4RpH+mo6ZJScL+HU2RW3E6Z/tNWFDd+UVopasDVzeninEHT4FL/iHn+14UBteeuQBTPyvCubLLazoW5O9iBNzw1PRRI9uBf7MDiMwI4a2XuCmBMYmmA6xb9DklGr9emDd6bPENYVZPLwIFU3QILQtqn/BdtfPdFDfyu4u+T0aQn7fhHAfupc/gMls7B624ltSuH2GV6DcJAtgWM4/pbiM9uu+Rs//hbSrwNE/GuSUlvNH+OUpe/VtfoP0w1DgwUOTQTLHN08E4eC8PIhYymnuNfYcw8WYj2+2OCeBDUchTUNwvBhq+21mEACC2Is++mY4ZaHKAz5P+SKWLbhMcnOInPz1NEaLaJ2aZTKlxstUL3UM0LCS5CA4GSOc5BquNwVZigB/FhoRbYMYse5cgHA0YBPtdvrBa5wjZ+ct52R5y7cjTtFF3cQwZT6OxqbKlZ6vf6BkP2TfbPl1/iJp6LEETAoVSz6WhuFXAoxYQ3D82HNEyUzGOtWHLuWx6aTEssMh 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 Wed, Feb 26, 2025 at 01:14:00PM +1300, Barry Song 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 = 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. > > This creates a race window between steps 2 and 4. > 1. add_to_swap: The folio is added to the swapcache. > 2. try_to_unmap: PTEs are converted to swap entries. > 3. pageout: The folio is written back. > 4. Swapcache is cleared. > If userfaultfd_move() occurs in the window between steps 2 and 4, > after the swap PTE has been moved to the destination, accessing the > destination triggers do_swap_page(), which may locate the folio in > the swapcache. However, since the folio's index has not been updated > to match the destination VMA, do_swap_page() will detect a mismatch. > > This can result in two critical issues depending on the system > configuration. > > If KSM is disabled, both small and large folios can trigger a BUG > during the add_rmap operation due to: > > page_pgoff(folio, page) != linear_page_index(vma, address) > > [ 13.336953] page: refcount:6 mapcount:1 mapping:00000000f43db19c index:0xffffaf150 pfn:0x4667c > [ 13.337520] head: order:2 mapcount:1 entire_mapcount:0 nr_pages_mapped:1 pincount:0 > [ 13.337716] memcg:ffff00000405f000 > [ 13.337849] anon flags: 0x3fffc0000020459(locked|uptodate|dirty|owner_priv_1|head|swapbacked|node=0|zone=0|lastcpupid=0xffff) > [ 13.338630] raw: 03fffc0000020459 ffff80008507b538 ffff80008507b538 ffff000006260361 > [ 13.338831] raw: 0000000ffffaf150 0000000000004000 0000000600000000 ffff00000405f000 > [ 13.339031] head: 03fffc0000020459 ffff80008507b538 ffff80008507b538 ffff000006260361 > [ 13.339204] head: 0000000ffffaf150 0000000000004000 0000000600000000 ffff00000405f000 > [ 13.339375] head: 03fffc0000000202 fffffdffc0199f01 ffffffff00000000 0000000000000001 > [ 13.339546] head: 0000000000000004 0000000000000000 00000000ffffffff 0000000000000000 > [ 13.339736] page dumped because: VM_BUG_ON_PAGE(page_pgoff(folio, page) != 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.14.0-rc3-gcf42737e247a-dirty #299 > [ 13.341470] Hardware name: linux,dummy-virt (DT) > [ 13.341671] pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) > [ 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: 0000000000000001 > [ 13.342404] x26: 0000000000000000 x25: 0000000000000001 x24: 0000000000000001 > [ 13.342575] x23: 0000ffffaf0d0000 x22: 0000ffffaf0d0000 x21: fffffdffc0199f00 > [ 13.342731] x20: fffffdffc0199f00 x19: ffff000006210700 x18: 00000000ffffffff > [ 13.342881] x17: 6c203d2120296567 x16: 6170202c6f696c6f x15: 662866666f67705f > [ 13.343033] x14: 6567617028454741 x13: 2929737365726464 x12: ffff800083728ab0 > [ 13.343183] x11: ffff800082996bf8 x10: 0000000000000fd7 x9 : ffff80008011bc40 > [ 13.343351] x8 : 0000000000017fe8 x7 : 00000000fffff000 x6 : ffff8000829eebf8 > [ 13.343498] x5 : c0000000fffff000 x4 : 0000000000000000 x3 : 0000000000000000 > [ 13.343645] x2 : 0000000000000000 x1 : ffff0000062db980 x0 : 000000000000005f > [ 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 (d4210000) > [ 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 > > If KSM is enabled, Peter Xu also discovered that do_swap_page() may > trigger an unexpected CoW operation for small folios because > ksm_might_need_to_copy() allocates a new folio when the folio index > does not match linear_page_index(vma, addr). > > This patch also checks the swapcache when handling swap entries. If a > match is found in the swapcache, it processes it similarly to a present > PTE. > However, there are some differences. For example, the folio is no longer > exclusive because folio_try_share_anon_rmap_pte() is performed during > unmapping. > Furthermore, in the case of swapcache, the folio has already been > unmapped, eliminating the risk of concurrent rmap walks and removing the > need to acquire src_folio's anon_vma or lock. > > Note that for large folios, in the swapcache handling path, we directly > return -EBUSY since split_folio() will return -EBUSY regardless if > the folio is under writeback or unmapped. This is not an urgent issue, > so a follow-up patch may address it separately. > > Fixes: adef440691bab ("userfaultfd: UFFDIO_MOVE uABI") > Cc: Andrea Arcangeli > Cc: Suren Baghdasaryan > Cc: Al Viro > Cc: Axel Rasmussen > Cc: Brian Geffon > Cc: Christian Brauner > Cc: David Hildenbrand > Cc: Hugh Dickins > Cc: Jann Horn > Cc: Kalesh Singh > Cc: Liam R. Howlett > Cc: Lokesh Gidra > Cc: Matthew Wilcox (Oracle) > Cc: Michal Hocko > Cc: Mike Rapoport (IBM) > Cc: Nicolas Geoffray > Cc: Peter Xu > Cc: Ryan Roberts > Cc: Shuah Khan > Cc: ZhangPeng > Cc: Tangquan Zheng > Cc: > Signed-off-by: Barry Song Acked-by: Peter Xu Some nitpicks below, maybe no worth for a repost.. > --- > mm/userfaultfd.c | 76 ++++++++++++++++++++++++++++++++++++++++++------ > 1 file changed, 67 insertions(+), 9 deletions(-) > > diff --git a/mm/userfaultfd.c b/mm/userfaultfd.c > index 867898c4e30b..2df5d100e76d 100644 > --- a/mm/userfaultfd.c > +++ b/mm/userfaultfd.c > @@ -18,6 +18,7 @@ > #include > #include > #include "internal.h" > +#include "swap.h" > > static __always_inline > bool validate_dst_vma(struct vm_area_struct *dst_vma, unsigned long dst_end) > @@ -1072,16 +1073,14 @@ static int move_present_pte(struct mm_struct *mm, > return err; > } > > -static int move_swap_pte(struct mm_struct *mm, > +static int move_swap_pte(struct mm_struct *mm, struct vm_area_struct *dst_vma, > unsigned long dst_addr, unsigned long src_addr, > pte_t *dst_pte, pte_t *src_pte, > pte_t orig_dst_pte, pte_t orig_src_pte, > pmd_t *dst_pmd, pmd_t dst_pmdval, > - spinlock_t *dst_ptl, spinlock_t *src_ptl) > + spinlock_t *dst_ptl, spinlock_t *src_ptl, > + struct folio *src_folio) > { > - if (!pte_swp_exclusive(orig_src_pte)) > - return -EBUSY; > - > double_pt_lock(dst_ptl, src_ptl); > > if (!is_pte_pages_stable(dst_pte, src_pte, orig_dst_pte, orig_src_pte, > @@ -1090,10 +1089,20 @@ static int move_swap_pte(struct mm_struct *mm, > return -EAGAIN; > } > > + /* > + * The src_folio resides in the swapcache, requiring an update to its > + * index and mapping to align with the dst_vma, where a swap-in may > + * occur and hit the swapcache after moving the PTE. > + */ > + if (src_folio) { > + folio_move_anon_rmap(src_folio, dst_vma); > + src_folio->index = linear_page_index(dst_vma, dst_addr); > + } > + > orig_src_pte = ptep_get_and_clear(mm, src_addr, src_pte); > set_pte_at(mm, dst_addr, dst_pte, orig_src_pte); > - double_pt_unlock(dst_ptl, src_ptl); > > + double_pt_unlock(dst_ptl, src_ptl); Unnecessary line move. > return 0; > } > > @@ -1137,6 +1146,7 @@ static int move_pages_pte(struct mm_struct *mm, pmd_t *dst_pmd, pmd_t *src_pmd, > __u64 mode) > { > swp_entry_t entry; > + struct swap_info_struct *si = NULL; > pte_t orig_src_pte, orig_dst_pte; > pte_t src_folio_pte; > spinlock_t *src_ptl, *dst_ptl; > @@ -1318,6 +1328,8 @@ static int move_pages_pte(struct mm_struct *mm, pmd_t *dst_pmd, pmd_t *src_pmd, > orig_dst_pte, orig_src_pte, dst_pmd, > dst_pmdval, dst_ptl, src_ptl, src_folio); > } else { > + struct folio *folio = NULL; > + > entry = pte_to_swp_entry(orig_src_pte); > if (non_swap_entry(entry)) { > if (is_migration_entry(entry)) { > @@ -1331,9 +1343,53 @@ static int move_pages_pte(struct mm_struct *mm, pmd_t *dst_pmd, pmd_t *src_pmd, > goto out; > } > > - err = move_swap_pte(mm, dst_addr, src_addr, dst_pte, src_pte, > - orig_dst_pte, orig_src_pte, dst_pmd, > - dst_pmdval, dst_ptl, src_ptl); > + if (!pte_swp_exclusive(orig_src_pte)) { > + err = -EBUSY; > + goto out; > + } > + > + si = get_swap_device(entry); > + if (unlikely(!si)) { > + err = -EAGAIN; > + goto out; > + } > + /* > + * Verify the existence of the swapcache. If present, the folio's > + * index and mapping must be updated even when the PTE is a swap > + * entry. The anon_vma lock is not taken during this process since > + * the folio has already been unmapped, and the swap entry is > + * exclusive, preventing rmap walks. > + * > + * For large folios, return -EBUSY immediately, as split_folio() > + * also returns -EBUSY when attempting to split unmapped large > + * folios in the swapcache. This issue needs to be resolved > + * separately to allow proper handling. > + */ > + if (!src_folio) > + folio = filemap_get_folio(swap_address_space(entry), > + swap_cache_index(entry)); > + if (!IS_ERR_OR_NULL(folio)) { > + if (folio && folio_test_large(folio)) { Can drop this folio check as it just did check "!IS_ERR_OR_NULL(folio)".. > + err = -EBUSY; > + folio_put(folio); > + goto out; > + } > + src_folio = folio; > + src_folio_pte = orig_src_pte; > + if (!folio_trylock(src_folio)) { > + pte_unmap(&orig_src_pte); > + pte_unmap(&orig_dst_pte); > + src_pte = dst_pte = NULL; > + /* now we can block and wait */ > + folio_lock(src_folio); > + put_swap_device(si); > + si = NULL; Not sure if it can do any harm, but maybe still nicer to put swap before locking folio. Thanks, > + goto retry; > + } > + } > + err = move_swap_pte(mm, dst_vma, dst_addr, src_addr, dst_pte, src_pte, > + orig_dst_pte, orig_src_pte, dst_pmd, dst_pmdval, > + dst_ptl, src_ptl, src_folio); > } > > out: > @@ -1350,6 +1406,8 @@ static int move_pages_pte(struct mm_struct *mm, pmd_t *dst_pmd, pmd_t *src_pmd, > if (src_pte) > pte_unmap(src_pte); > mmu_notifier_invalidate_range_end(&range); > + if (si) > + put_swap_device(si); > > return err; > } > -- > 2.39.3 (Apple Git-146) > -- Peter Xu