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 01D0FC021B2 for ; Fri, 21 Feb 2025 00:07:40 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 202A66B009E; Thu, 20 Feb 2025 19:07:40 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 1D8AF6B00A0; Thu, 20 Feb 2025 19:07:40 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 079C16B00A1; Thu, 20 Feb 2025 19:07:40 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0010.hostedemail.com [216.40.44.10]) by kanga.kvack.org (Postfix) with ESMTP id DE10A6B009E for ; Thu, 20 Feb 2025 19:07:39 -0500 (EST) Received: from smtpin02.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay04.hostedemail.com (Postfix) with ESMTP id 8C1FA1A3176 for ; Fri, 21 Feb 2025 00:07:39 +0000 (UTC) X-FDA: 83142013038.02.6A467FD Received: from mail-vs1-f42.google.com (mail-vs1-f42.google.com [209.85.217.42]) by imf28.hostedemail.com (Postfix) with ESMTP id A1C6DC0010 for ; Fri, 21 Feb 2025 00:07:37 +0000 (UTC) Authentication-Results: imf28.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=ktpbOp+r; spf=pass (imf28.hostedemail.com: domain of 21cnbao@gmail.com designates 209.85.217.42 as permitted sender) smtp.mailfrom=21cnbao@gmail.com; dmarc=pass (policy=none) header.from=gmail.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1740096457; a=rsa-sha256; cv=none; b=qU4BpejvmAubaNxa0DI3c/uLdfPJXgdAEd0+CtdtReXxnsjByPzJpMXvC9Hkj35qnUDmh7 0nwPgAmdkIrhBC9AAOplqzjjomqn6WgaF8XAxxSgQvrapK1cHcRrQkY1FEkHAT2oYiA4mi 9IbuLEFKFirua9pYK2wxX3ekVP1ZcN8= ARC-Authentication-Results: i=1; imf28.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=ktpbOp+r; spf=pass (imf28.hostedemail.com: domain of 21cnbao@gmail.com designates 209.85.217.42 as permitted sender) smtp.mailfrom=21cnbao@gmail.com; dmarc=pass (policy=none) header.from=gmail.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1740096457; 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=yNjxgVeVeHgcdYvbJZlSUczEpc3RlMwxUrdKBdaJztk=; b=tvfvyNwogEZVtoaR+V3gAnoJTkZ7OQcIVgPwraEouj9Y9mmc0uko8VCOGDEM0RbSznUkMf jRnEofgIhKtIWbJ2V/vG98+bWGjrebeHtNS2Vaii3nRmaxk9sADp7Fl/hxfX12fKdlx3QY J5SFluKnCmdq59l1Oj4kRTMb6QuVGtI= Received: by mail-vs1-f42.google.com with SMTP id ada2fe7eead31-4bd35d4407aso502388137.0 for ; Thu, 20 Feb 2025 16:07:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1740096457; x=1740701257; 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=yNjxgVeVeHgcdYvbJZlSUczEpc3RlMwxUrdKBdaJztk=; b=ktpbOp+rvRcaaQWj+IuaCfuAs80aBoJ4mYoLeK7+E7JSgPR7mdXapg8SEEjM7rnygu 3PCsUGqMXofYsINKemhbbxU/RXsMoE3yl5XREU/KpE+U/v0pJA2HF/C1lGli6AKURTQ/ gno6a/EbXVC8EoTbSKXSkG346yaAj9Tn3CNKRrRyjEVMZ+8otc2Gv6Mg/Z3wmt+oNXkF ECCKXCR5xnsbPUE46OpsWPcte6WVDm4eFGK90W9u3m4Uv37ZXQX4bpQlQCxmaCI6jU8L usx6vc6IKHOXaZSvAvVcxn+Cktb3PSnhrsN/c8TsDnA6ztuVoVNYDBZlPx7X3rDQRiiD Fnlw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1740096457; x=1740701257; 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=yNjxgVeVeHgcdYvbJZlSUczEpc3RlMwxUrdKBdaJztk=; b=i4tkYeZbtuRF9lxVIW7UEMTETO4RGW81Tr8ZGTIYCuq4Qju6P1iBUzs3TpCF1l7Ue7 UjGyRIDzAPQfmE9Y413xeM6wJQXSs1BYaBERrb87V1y6Ogy0G4ZfvKAXeZ8ysXqEVteJ scwXO5zBiQsgjsFXypMeGugl6wnKXH1GlOzrGWO3vTbUnc80pbehDBBSGLC3zQS5hUoS erqkvZkgBCYLVVESuRj8CCOTzs9if9G1c0xc6fBHvksWOGaZARCOslIA56Xr3H2mpDOO No9QZoz+hHQAXo6VKRC+lchLW3aRJnVXJ2KMgzfyIOgectQlqNkVZe2PB2cOxmJ1tneG PW1g== X-Forwarded-Encrypted: i=1; AJvYcCXpAqEMH//KEFU+QHUPuF7q+OjObKisrWuwgU3AYoG0HS4fnKROefLVCYmFRsGyAsY/BW2oXgCCfA==@kvack.org X-Gm-Message-State: AOJu0YysweC2GlNrfvasrXhsPrBe46yNX/5IRFTYvYDda0yc60Q6SnDa vvStJZad7zckPJADX8+Hqzc0D0YfTaEGDvtVqViw6z9jgK4D27XSCAkq0kBv5loOsBLelc9mzl+ CzhcWmCFsKWCUHY75GtAq/NOJJpw= X-Gm-Gg: ASbGncvDCfOljnxIlMygBx456bSpSCyOqGuZKuIUNH4ivWUHr4to55vXu15sa/ONqwe k/QBprkz8unB7wR59/qnrcgSoyWXQrcE+yUpQWRZsrZnra99rJ/87nz6j/7L1cE4r1MwZXmNE X-Google-Smtp-Source: AGHT+IHSi4HiluB+91pGBYRnFv0s7RilYgXxztGrydm4XkVVegmkknDiPOeVM3lAYDVKBlM1KqAXHwzwMmKUUBEUV/8= X-Received: by 2002:a05:6102:41a5:b0:4bd:3c41:7f6c with SMTP id ada2fe7eead31-4bfc009c888mr1027889137.10.1740096456724; Thu, 20 Feb 2025 16:07:36 -0800 (PST) MIME-Version: 1.0 References: <69dbca2b-cf67-4fd8-ba22-7e6211b3e7c4@redhat.com> <20250220092101.71966-1-21cnbao@gmail.com> In-Reply-To: From: Barry Song <21cnbao@gmail.com> Date: Fri, 21 Feb 2025 13:07:24 +1300 X-Gm-Features: AWEUYZkGBaS0O8lQ1W43gky4VX6JpyFPxRw29m5phtbNiHuJDt6ylGK9DhTerNk Message-ID: Subject: Re: [PATCH RFC] mm: Fix kernel BUG when userfaultfd_move encounters swapcache To: Peter Xu Cc: david@redhat.com, Liam.Howlett@oracle.com, aarcange@redhat.com, akpm@linux-foundation.org, axelrasmussen@google.com, bgeffon@google.com, brauner@kernel.org, hughd@google.com, jannh@google.com, kaleshsingh@google.com, linux-kernel@vger.kernel.org, linux-mm@kvack.org, lokeshgidra@google.com, mhocko@suse.com, ngeoffray@google.com, rppt@kernel.org, ryan.roberts@arm.com, shuah@kernel.org, surenb@google.com, v-songbaohua@oppo.com, viro@zeniv.linux.org.uk, willy@infradead.org, zhangpeng362@huawei.com, zhengtangquan@oppo.com, yuzhao@google.com, stable@vger.kernel.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Queue-Id: A1C6DC0010 X-Stat-Signature: ikhr6q6s5b8nhffcyzt3gk3tq1wfhaau X-Rspam-User: X-Rspamd-Server: rspam10 X-HE-Tag: 1740096457-341111 X-HE-Meta: U2FsdGVkX1+XKHHXM24ke2cgH0/sk5H1WJtTQCHiBtrtocX0Dq923kHX/dTYr63Ah1MKtacuT/gmcDEhx/imjrOihXjZ7Gxsl0dm/P4MVFvhsN7mP1PbfeHMxKg17twRLcKC/tfoBTeCyr2q5cavuEi+2E9ejELTowcsrhWf7biibZKrrMt5T7Uvj6sQewAmwt3yf1e794I+Nps7ZSgI1Aiy0Rid/Y+9A6J2wNGVzm9IDCgFTvEsgVmqnPbrrKKKVQlqT3+i/b2ajcQcn6G5Z/fyDtNNEheDwToGCijrhzHREdRWQheh2+L4T599/KeVlY7iktFnuprcuyVcUR1LHH3jYXMpclRNAAYKOiks1Zt6kyK/6QqhVP4s80DRP5uXPWkfIqjMitC1L9416cARfTThV5Zbl6y1TlcRw4h+irnjjdfSEb8ONSbNt6z5ZtO4Q9tQG3PucsMuxMDu974Kr9GbFMGQglxh3yoOetfYsv/t8XTEpd1oQUak41/bD6dMUbr3l0i51Lgo9hy5jSwgh0tL2lgQAR/8YT94fs7TP628VHAOqwS2xrW2X06vWTyciRzWDkU58koTULLYdAi+MdgyPTxlEg2XJBwhCFOm96Qh36PrtFgekV0GOb0pey9LYtJHnF3TwxWnGYCKCcFy7FdwdG4en7FkKOStV1E6/jqrbMb0srv8kLUAJVXOFlzgq+2wONshHAa9jRUOwx4AqgkC1TY9PuSI4ZXIuxpMSLIG6RIYmspkrQZmCcI0OYCL5S0rFBl3AsTARE3PheMi3M/kZo+T24Q/AHO9jsrrrH4qrvcZWC+F7UVankxup2gCuSbzqP3b1ZTxQhx0Q4ZFmRg7KBL0bZYMTYpk4K4MBpgNGAktzkv2hcRpIxEtVCvTV3uywyKLdX8iLxurzMWEFziYnFQcw6X97jaIXAdcAU87K5FhsoL/3BxtMMRTgpQk8HI+uCa8He2fhVvv/u2 cDE09D+o lcrzYp6I3LvjNY7FMkG8B4CnwsyUYEtbIh553J5hOUuY0J/GtA5PUNhLBTJfrCeKkebmqbp+nioT/ESNjU7nth5kChtdhdcZNdPXy2sea8MxKsadFu8K64XpGM1nT4pNMH1TkN/CPE9kF8L/sYIEgGZHz4I8G0zoDf8UxzHjKNRPLRWDXFn9oBSRjOfp6BpxeDm72f8JwAfqipebK4FF5UuJ3C/vSyfNdT+IqhkE7jpM0oakbDU8l0WUDW13LuI1BUemMKQTdNEr3nIz7LfdP85PruDy76Pbmh17v23C9ERJ+MQXKLruxZA4W45OwWlNvepxOBZBlbBau2BY/Zz2zQjqWIhG4haHllVCXbpgWTKjsAM4Huj1bNKHuOHvPOoOATPEeP88MXGtZCGg= X-Bogosity: Ham, tests=bogofilter, spamicity=0.000581, 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 Fri, Feb 21, 2025 at 12:32=E2=80=AFPM Peter Xu wrote= : > > On Thu, Feb 20, 2025 at 10:21:01PM +1300, Barry Song wrote: > > 2. src_anon_vma and its lock =E2=80=93 swapcache doesn=E2=80=99t requir= e it=EF=BC=88folio is not mapped=EF=BC=89 > > Could you help explain what guarantees the rmap walk not happen on a > swapcache page? > > I'm not familiar with this path, though at least I see damon can start a > rmap walk on PageAnon almost with no locking.. some explanations would b= e > appreciated. I am observing the following in folio_referenced(), which the anon_vma lock was originally intended to protect. if (!pra.mapcount) return 0; I assume all other rmap walks should do the same? int folio_referenced(struct folio *folio, int is_locked, struct mem_cgroup *memcg, unsigned long *vm_flags) { bool we_locked =3D false; struct folio_referenced_arg pra =3D { .mapcount =3D folio_mapcount(folio), .memcg =3D memcg, }; struct rmap_walk_control rwc =3D { .rmap_one =3D folio_referenced_one, .arg =3D (void *)&pra, .anon_lock =3D folio_lock_anon_vma_read, .try_lock =3D true, .invalid_vma =3D invalid_folio_referenced_vma, }; *vm_flags =3D 0; if (!pra.mapcount) return 0; ... } By the way, since the folio has been under reclamation in this case and isn't in the lru, this should also prevent the rmap walk, right? > > -- > Peter Xu > Thanks Barry