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 17E81C3DA6D for ; Tue, 20 May 2025 19:10:18 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 93B5C6B009C; Tue, 20 May 2025 15:10:18 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 912C56B009E; Tue, 20 May 2025 15:10:18 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 829A16B009F; Tue, 20 May 2025 15:10:18 -0400 (EDT) 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 60B786B009C for ; Tue, 20 May 2025 15:10:18 -0400 (EDT) Received: from smtpin01.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay09.hostedemail.com (Postfix) with ESMTP id DE3A380EEA for ; Tue, 20 May 2025 19:10:17 +0000 (UTC) X-FDA: 83464226874.01.44D11AE Received: from mail-lj1-f169.google.com (mail-lj1-f169.google.com [209.85.208.169]) by imf27.hostedemail.com (Postfix) with ESMTP id CED3040016 for ; Tue, 20 May 2025 19:10:15 +0000 (UTC) Authentication-Results: imf27.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=LzXHBp+E; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf27.hostedemail.com: domain of ryncsn@gmail.com designates 209.85.208.169 as permitted sender) smtp.mailfrom=ryncsn@gmail.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1747768215; a=rsa-sha256; cv=none; b=avVcsLu/Fmh8Kq582GmvUP8sIizHIziyz0xGXTk+fOmr/EIvM9grPs/WPn0tH3aFb6PeVt AxHRsESbC7A4y4YZOrANj0o+cr6F1cRBX+YfI3E2em24QqU6dRDWHDEYhAcKgtadt39Wau pI+nsDjVpzyXf7zWl+fhFq8TcdVKvhQ= ARC-Authentication-Results: i=1; imf27.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=LzXHBp+E; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf27.hostedemail.com: domain of ryncsn@gmail.com designates 209.85.208.169 as permitted sender) smtp.mailfrom=ryncsn@gmail.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1747768215; 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=DPsO0f2BWiwLoElcAZPyuEpqP8kWpMqtpBL6TS/Lmi8=; b=wgirG8+gflcrr2inDolLthjRx7iGuNzCgiW35HLFHpb6UNENiv/uC1S7eq3mC2RmCE0Men FRLoqr3/xWhlX6mqcXLAgv1CvR6kjOO27CUEzdEqH1I3C7QBgs2CFbfpdgeDwvGqWV/SRk +JXAB7vYXpVrDPMop3DDRDl/OPJL110= Received: by mail-lj1-f169.google.com with SMTP id 38308e7fff4ca-30c416cdcc0so57741671fa.2 for ; Tue, 20 May 2025 12:10:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1747768214; x=1748373014; 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=DPsO0f2BWiwLoElcAZPyuEpqP8kWpMqtpBL6TS/Lmi8=; b=LzXHBp+Ez7gwiVjP7GQa9bpZNLbUZ69VcXzTHdwOfjSPGwFUHMfpk0cJ8PumVSwxfA yIsgUzYSj+2bi0OtnQAfZb2vd3kVPm69P4LIiBaZyRobIwIdnCPYAlPBRrwno4B83RCO vgliW1C5vto448/RISN3V8dZDg3MDgk01YUHMbYDkgCcqEYBV2rV8nLJvyhRlzc4JkuQ hOA/VOUxE1ugHtbcl7rkSGFEIS+UTyTQ8/L9XAehT/FxG+dSSftq8G22Tmqup2mqluEs Tl12iVIigpq/eqcqHM4uLvPxPiIXd9mbzJtbkbEAcYkiJu9zO8KYKoxs0jXs45WAzq7N Qc1Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1747768214; x=1748373014; 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=DPsO0f2BWiwLoElcAZPyuEpqP8kWpMqtpBL6TS/Lmi8=; b=tuyZvjGMMbZwPV3nDYFeZ0wiURAuSR2pkNERtYtz6SdzmAryOe0HPP70KQ/xdTeFmR pivieLHA4/dns/ToaLjGTROnZHJNRvIJBAtutxHuAIgCK0Ge24ArU3PmWsYOFeoJbwX2 PSFvqKS2zXMACZTkGK81fWnMnJ4ddj3hMhIvvFJ+HySmzMfJ+gMhKNVMh3mfCuoVTLLI A7hXx/noIVonyj4tP+HBXMOG1uefF1n8IffkXRdFfFlT90XlHgzl86gC/d3z2vpucMx6 PA6jsyOeJA+E1Tob4QeJFCxtmwQgZuRMODDO3yrxcMUzn8CLUSolRUgy4AJ8UZgZFWCF ZUhw== X-Forwarded-Encrypted: i=1; AJvYcCUzIRHXKcDlebr+P2nK/Q2Gca407JCGVEpkji5Arqhp2plLbQOzsXfpmjjN3uQSAEyfLxUHNOU3Uw==@kvack.org X-Gm-Message-State: AOJu0YzZn02DAAFB37FzaBVDxrxsSHWizUkZsKUll1XNktJUXzBci33e CRagnP826EwUpjDdL9b/D2rgkKKLRbcd7Rq9rfIA4HUs7t4Ot4rW74TxUU2wTKT/koJ3lOfWZ8x aD6pjBch8MWKGmOOrndkyI/GjmmFRg7c= X-Gm-Gg: ASbGncuj1f11Wpv76j+uqCV9EvIQsoKfBVbAFXlX1FFzihAOj9pgUV2oze5gFDGmXzm 4VPSA5vCMHdy+oof5M9S3KsTbqaHWA/KzdrNb7dxoZx3KWgWXSGvy/7ho2HHaR4cdw74BKuxPHB CASWCr8fKtgFDSKJa73oueCNVKFW/UkyDMw6NbtIaoLzut X-Google-Smtp-Source: AGHT+IG16erSfQCKQUExc5Ec2MNVNDdswbVgxsFyD29WQGDrNQv9DL99soNojHJYgWzNFEr0dlvzKU09eWi759D2lkg= X-Received: by 2002:a05:651c:b25:b0:328:604:9da8 with SMTP id 38308e7fff4ca-328096986cdmr57652731fa.6.1747768213725; Tue, 20 May 2025 12:10:13 -0700 (PDT) MIME-Version: 1.0 References: <20250514201729.48420-6-ryncsn@gmail.com> <20250519043847.1806-1-21cnbao@gmail.com> In-Reply-To: From: Kairui Song Date: Wed, 21 May 2025 03:09:53 +0800 X-Gm-Features: AX0GCFvS0Qh8UlwFUeBGaeNobGkHIR_Uv-gx1q7Z8yZ-MxE_Jq4EzqIPqQcytn8 Message-ID: Subject: Re: [PATCH 05/28] mm, swap: sanitize swap cache lookup convention To: Barry Song <21cnbao@gmail.com> Cc: akpm@linux-foundation.org, baolin.wang@linux.alibaba.com, bhe@redhat.com, chrisl@kernel.org, david@redhat.com, hannes@cmpxchg.org, hughd@google.com, kaleshsingh@google.com, linux-kernel@vger.kernel.org, linux-mm@kvack.org, nphamcs@gmail.com, ryan.roberts@arm.com, shikemeng@huaweicloud.com, tim.c.chen@linux.intel.com, willy@infradead.org, ying.huang@linux.alibaba.com, yosryahmed@google.com Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Server: rspam12 X-Rspamd-Queue-Id: CED3040016 X-Rspam-User: X-Stat-Signature: aknfawfh47nwfmxpguy1yss6wdxk8ysb X-HE-Tag: 1747768215-810186 X-HE-Meta: U2FsdGVkX1/wzTmIUE63+mgLJ1JIGSj2qUUT3eQ1lSH32ivguWp6XTeD3ZVSMfsjtdXNQPKKQ4qiquxoC+WZBn0BQJpfovHRXoNGMiBuXDVK6zk15CpOxBAwxJiTg6VKY2GT3ORXlKNik+RxsxseZPFe+WXQg5d2u7qyAi+eU79L/zDmDkAO7Z6X5WF7+ZL/dmSs46yMjL99jsatTLxxgswI66Ameu/QMHa9JFn/ZU9FDfPMeBcliV7fNcXuqmuwA9azemR/o1RAEbD6HZik0PJRIQPOPiEjMMyqGZOhpRdmKkBqFVJtmvlfzldjmRB+y67L59DI1scPiE6PqgqUVbZckiOnHC70P2tMRhsqBozLBYGfjB3VDtgi/iEdSbNUKog/Q8XdA5cWIio6uNi09+N4ALkEa/siQY0vV2BEXXTQrGRLYB0YNPmlgyYV6kdUyPIX9Y6ofLgEdYinghj4TRxw4bgkP3goWQDBoD/7BH6TXvuuoC3PWy6HF8JHS37F67bjsOs1XDQI+WOkBfkLOzk7Yc6p6B5kRNhnWafniAIS1Z2YTUnK5AkirdGKUHDidNXPDmh3llkJT4l45jnUNpCEvJhQZI6rKRB1ZmrK+xodOUsMRxwyfzganxtdBgnSFA2RViZScT7XSMrKwsLxznrpZOcx9PZNxE9u7QL6dwKZrk90ck3wE1HHqQPivnjGeNPZZOHeV8dsY4HYldKNL4lms1YobSK7miQjMORJXnbMfptGqMAGb65fg4CaBDXEyFNWGYRe30IX+2wUFrKjAaYu2JiUNu9UOCt/YIQTripO93CRMHVbI2ug1/71A1Msic7Phj615fciRKlEUWC8WDo+1CAvDkwC4o4nsZ6tFCEVDIIxSqTRTAHWL2l375/XZiFIxZ7D8tuxP5bmEeBA8+OfbL6sN6x/mRACvm2B44ESlr2GMCl46qkZ19Blm4SLA38bTe5WSnraKt9zkyT TTh0m9zg qz6MTg8XlT2lRQepDa7VmxKwrRYbkcoiHtbTEtnz+OZCEu4+jtdJ9mJlg4H06aKLenjuUHPhQA39ZTnfnAM1VMS58E+cYU+3rXq1bHN0u3dj3wfmbr/q+VEY0Ete7bfMZ6KTJYstSH76VIB0ux/n61QxWo2C60vdX7Ya3PadDyvEonnDUYJflm6Zk+eEZOWUECUhYUMOUkCtlnGEeqh89jbz/KBb6YxL44TjWSNny2Oe4fPdKXPtit67RoPPHxdg62udkP+53ZN+jCiiuA+b+j7EfqU5o3bWbGdThm88RCq2gs4DA7t1jYSS72KNYZNTHrdCL6aa28Ci++KejYPaHHU3Mv8I9dKTMH40RnWjT+8WQtTwONC8mo0fnbQ== 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 Tue, May 20, 2025 at 12:41=E2=80=AFPM Barry Song <21cnbao@gmail.com> wro= te: > > On Tue, May 20, 2025 at 3:31=E2=80=AFPM Kairui Song wr= ote: > > > > On Mon, May 19, 2025 at 12:38=E2=80=AFPM Barry Song <21cnbao@gmail.com>= wrote: > > > > > > > From: Kairui Song > > > > > > > diff --git a/mm/userfaultfd.c b/mm/userfaultfd.c > > > > index e5a0db7f3331..5b4f01aecf35 100644 > > > > --- a/mm/userfaultfd.c > > > > +++ b/mm/userfaultfd.c > > > > @@ -1409,6 +1409,10 @@ static int move_pages_pte(struct mm_struct *= mm, pmd_t *dst_pmd, pmd_t *src_pmd, > > > > goto retry; > > > > } > > > > } > > > > + if (!folio_swap_contains(src_folio, entry)) { > > > > + err =3D -EBUSY; > > > > + goto out; > > > > + } > > > > > > It seems we don't need this. In move_swap_pte(), we have been checkin= g pte pages > > > are stable: > > > > > > if (!is_pte_pages_stable(dst_pte, src_pte, orig_dst_pte, orig= _src_pte, > > > dst_pmd, dst_pmdval)) { > > > double_pt_unlock(dst_ptl, src_ptl); > > > return -EAGAIN; > > > } > > > > The tricky part is when swap_cache_get_folio returns the folio, both > > folio and ptes are unlocked. So is it possible that someone else > > swapped in the entries, then swapped them out again using the same > > entries? > > > > The folio will be different here but PTEs are still the same value to > > they will pass the is_pte_pages_stable check, we previously saw > > similar races with anon fault or shmem. I think more strict checking > > won't hurt here. > > This doesn't seem to be the same case as the one you fixed in > do_swap_page(). Here, we're hitting the swap cache, whereas in that > case, there was no one hitting the swap cache, and you used > swap_prepare() to set up the cache to fix the issue. > > By the way, if we're not hitting the swap cache, src_folio will be > NULL. Also, it seems that folio_swap_contains(src_folio, entry) does > not guard against that case either. Ah, that's true, it should be moved inside the if (folio) {...} block above. Thanks for catching this! > But I suspect we won't have a problem, since we're not swapping in =E2=80= =94 > we didn't read any stale data, right? Swap-in will only occur after we > move the PTEs. My concern is that a parallel swapin / swapout could result in the folio to be a completely irrelevant or invalid folio. It's not about the dst, but in the move src side, something like: CPU1 CPU2 move_pages_pte folio =3D swap_cache_get_folio(...) | Got folio A here move_swap_pte | Now folio A is no longer valid. | It's very unlikely but here SWAP | could reuse the same entry as above. double_pt_lock is_pte_pages_stable | Passed because of entry reuse. folio_move_anon_rmap(...) | Moved invalid folio A. And could it be possible that the swap_cache_get_folio returns NULL here, but later right before the double_pt_lock, a folio is added to swap cache? Maybe we better check the swap cache after clear and releasing dst lock, but before releasing src lock? > > > > > > > > > Also, -EBUSY is somehow incorrect error code. > > > > Yes, thanks, I'll use EAGAIN here just like move_swap_pte. > > > > > > > > > > > err =3D 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); > > > > > > > > > Thanks > Barry