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 1241AC48297 for ; Tue, 6 Feb 2024 17:31:19 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 4E4206B0078; Tue, 6 Feb 2024 12:31:19 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 4945E6B007B; Tue, 6 Feb 2024 12:31:19 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 35BDA6B007D; Tue, 6 Feb 2024 12:31:19 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0013.hostedemail.com [216.40.44.13]) by kanga.kvack.org (Postfix) with ESMTP id 224A46B0078 for ; Tue, 6 Feb 2024 12:31:19 -0500 (EST) Received: from smtpin21.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay04.hostedemail.com (Postfix) with ESMTP id E3E381A04CB for ; Tue, 6 Feb 2024 17:31:18 +0000 (UTC) X-FDA: 81762070236.21.72D5E62 Received: from mail-io1-f43.google.com (mail-io1-f43.google.com [209.85.166.43]) by imf16.hostedemail.com (Postfix) with ESMTP id 12CAD180018 for ; Tue, 6 Feb 2024 17:31:16 +0000 (UTC) Authentication-Results: imf16.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=NhrdvkJL; spf=pass (imf16.hostedemail.com: domain of nphamcs@gmail.com designates 209.85.166.43 as permitted sender) smtp.mailfrom=nphamcs@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=1707240677; 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=oPcqdTOG7hsb6OetsSk6gwLuDAB08ptM/Ebrl9LX+uc=; b=Y83E2VItlPIF1UykaZIj4v6ShKqGtek9Fh0pfgVqCScSRSHY8nFiK7uWtH+BAFiLY029VY oFCQKPl/xOL/Ykiy/EHZ4dbDWKbBHd4ZeQi7Qg00kCtiNhDVRxqhviPcmm05AGM/t8LLnT /QV9tWSGZyz4w1cbofj6ZROFqBsaHrc= ARC-Authentication-Results: i=1; imf16.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=NhrdvkJL; spf=pass (imf16.hostedemail.com: domain of nphamcs@gmail.com designates 209.85.166.43 as permitted sender) smtp.mailfrom=nphamcs@gmail.com; dmarc=pass (policy=none) header.from=gmail.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1707240677; a=rsa-sha256; cv=none; b=mxJwjPEkbHribve+/Eug4+hW6gYNfZGgyGy9+w5+sjYFEZNXJJUeH8Sbd5zIvp0P6bnebe LovP6rnQ85M5E+zGSUu9Ccz+SiQNCJXGtVpRkXP1MRu7xDEODBAWBGeww0PGIjKD3d269h 2eXL6UOUGC64TMRX6b3tX1EZoK/mYLY= Received: by mail-io1-f43.google.com with SMTP id ca18e2360f4ac-7c3f68886b4so18835039f.3 for ; Tue, 06 Feb 2024 09:31:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1707240676; x=1707845476; 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=oPcqdTOG7hsb6OetsSk6gwLuDAB08ptM/Ebrl9LX+uc=; b=NhrdvkJLHn9LLQDeFKTHyzidr87dBBXAesWLkQTEPEqAG847R0k3wlKtr5fhWSuKJs duNUq2gz2RSfBtMRyhqFW3HUwIie/EYCseHSElPyWQUWIFAuZ5MaNWt8TdsqVZckF5oe 3yd90K+cDtdInTc7MOdcLI1M19bwGtBbR0QHGUdVO5Mw9JFC5Cc1J0xZxUE/JVk/mg/l KOUfOfFKESog9gAO6RUMuxHEbfw9TZrQXJsYsqAmAsRBHTYZteKWvY28r1AG1shOnEHl W57D8xEgdeNlE3BTZZWJKw0PpQEcOWyviVyiUvjV/qDtHsiBm5YdAaETDzy2ua7vLhm9 MqqA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1707240676; x=1707845476; 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=oPcqdTOG7hsb6OetsSk6gwLuDAB08ptM/Ebrl9LX+uc=; b=dmP/GcsF/lxUskdhPEg8zyEcAJxoH1ITXkR7/Lo8gmQeKpAa6RAhWZHkuKuHQrCoas PsAvC0txZ//PCkFKyiAlJbe2p2PUIsznxbMMpSNmuJ66AUZfuQ30HdvfoL7Yp9FOCKk3 EvOozkLj2e9KOBshzyG9q2njYCrwEO0qmI7rP2oo6ApUAaRVCAgX5icM367V2KxBSNN1 /o95k8t5jK4oExfuPmovXfFnwX4RTqqSroJiVJ+9ldUV2wxaHUCFzZ3N+aAm6mblohHZ mhl6XkvuUr9Gu1Mw3Vc3PXOYlZkQGt/OIBTyyXlSTzOdnpG4yrCFdpFayEe8k5Eogbjb Wd3A== X-Gm-Message-State: AOJu0YwJuQaw1KenlUugBL+COyhXwpa19Oxyvjtno3WIkDW2T3P+UqXO pjaXS4rZw6x9kNcyC69bFdQ4A/hh5qAYac3sw+SNixtyli4XJMvXN1SP+bPf8ef1cmhYOWOo3SN TNYnnjY91wS7mQzFDrTca6hIyZRi1JPnf09f9vA== X-Google-Smtp-Source: AGHT+IHwZvUC74P4q/l1EaSnsg7ta7gOlVu/FmAfqhuEXq0gxrEH6mxcei45FQXey0KBh+cOaM345ptlFi+YwfS3W3Q= X-Received: by 2002:a05:6602:17c6:b0:7c3:f303:e274 with SMTP id z6-20020a05660217c600b007c3f303e274mr2201238iox.8.1707240676003; Tue, 06 Feb 2024 09:31:16 -0800 (PST) MIME-Version: 1.0 References: <20240205232442.3240571-1-nphamcs@gmail.com> <20240206151523.GB54958@cmpxchg.org> In-Reply-To: <20240206151523.GB54958@cmpxchg.org> From: Nhat Pham Date: Tue, 6 Feb 2024 09:31:04 -0800 Message-ID: Subject: Re: [PATCH] mm/swap_state: update zswap LRU's protection range with the folio locked To: Johannes Weiner Cc: akpm@linux-foundation.org, chengming.zhou@linux.dev, yosryahmed@google.com, linux-mm@kvack.org, kernel-team@meta.com, linux-kernel@vger.kernel.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Queue-Id: 12CAD180018 X-Rspam-User: X-Stat-Signature: k6rbnd3srrf63nkaaae54w5gmket9wqf X-Rspamd-Server: rspam01 X-HE-Tag: 1707240676-935444 X-HE-Meta: U2FsdGVkX19a8Gx7VTVOFHvxLEJXyZRUnRg5QixzC0tWF4uRSFcM8Ub1WHR/PYqb92+zfyT4S00+M9pjCHY9uj/mKZ0jYvNnNbcxuooYEzMSzJINbXofYip2iMCy8fXp/RAaWTu5u8BAvcde6jmt/UxaS0JFexJMjLznjrQ9P47wMhpPmRyJHG0gkVsdk4RXOyPkoRq+DWqrnuDZgLk6uscG+SfsTt3wc8JPcIG74DEAXxsGAyW//noLBBLTyR1TTSEy+kIDPBJUB7MPCVra0gd0KpMEGHDklhjsG155DwxMNsRjCk0LqT+qXZQQOV4W3mnq25UbRA/cOBrQ4ZyLJpsKWQfUmeRFIehAvU3jrJ/lWQOC9BHlkIwqURz9neisfLcG9dCTpdQ0U9hsj6p4GpS62b+XOuJI/x7Yf6QTLzHZFj+N5/mB2mG5D3akkjarzqkvzRV0J6TVv0IFGRIARBeR9s7ks4hgEarinKAeKzLx8XN+dlk4Bl73G4gCosk+KjGieR2tvxb/9epXZLc/waMImRT9ed+qL6s5RuqThtsAAIAMEYt8Uws1HPHmrCclCXYPGaHPMGSg93Zf9nVqKCI6szmeg4xLKsyE94vCnyvyE49uVIlhny9DoEYImufdidIXhIFsveVgNqrKm3TSiTIkCcFgU9iCRX893GSH2gFm9Nv918lS1EnhuwfyMdXl5rrUH4rakce2TpjLN3UKbnNgJClqsH0Jb7IO9gdqI6rvpKsmprVFiRcte7+vvVLrSit5akG486cETdlHMz831t9cWwZ9dYM9l9I+fkz3pPeVEybPMDCthUW0LESiP3vmEUEOlaN6/Eamz59Y4LPrZCdMthE2lzUk9J8+YA4Z0aG3uvTTo9clj6Kchm9B8kB/Whsd/g8UlklAdk8DZZUK1uqnRZ5eYUgHsr6yrac+YDbLyT9GYB2EwCeIYvHYJ3lzINPs9FFxLDnaywPc6dv wGnS29ZP woKYE2MdRtdFAGt3ym64RKzr3luYuLM+oUBoQ5gZLpJubKStGSQq5SIQZ428oc2+wZXG64tuCn77hG31NKoEUsLVzzTgtKpxHQjf5Y36qYiZbxvspwjDhs7nYi8+IfBiwp4a7udNoNmBgiuBUFEfAgKvKyvDpIEhz5yUmBe5Eugv4Eth2tjj503rJhYZqEMELCkQkhLUw9ZqahAOYS/RUPhgN5IenGd1CfNMEA6JFuo7g+zY3qpIF4Tl5BwHlu7M9Z/i0rmvbuQ7Q1IMheKAh6C67rYgFG69mKlZuyjYE68oLM0XwmNAJW+r5BW2z7cqFXltUQ3anumSZsGyyQVs7gGVeEPYcnvMHsNR1gxPMDxtMxXbgDKTL5vbAQT7D59gpioAMfj19xe865k7tfdPH88w594276J8eWnQ9ZhDrHxwHBtv5lMMZ2UmvFr0GRBwLxrWtY+qH8tY+DC10HBk75sJxUikIPg9fIX3eI86iuqSVLbJGd7kDNwqcsPAy7+Lc1/aaQIvglgrFql50GEBeAVql2RrulyhN/zisvNi2D8nOLgW21Fk7+x8BjfNKw8NKf9a94VgJMdRRMbJjwe84iKY4I3PVlUkXPnZn25nqkrmHPOw= X-Bogosity: Ham, tests=bogofilter, spamicity=0.000777, 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, Feb 6, 2024 at 7:15=E2=80=AFAM Johannes Weiner = wrote: > > On Mon, Feb 05, 2024 at 03:24:42PM -0800, Nhat Pham wrote: > > Move the zswap LRU protection range update above the swap_read_folio() > > call, and only when a new page is allocated. This is the case where > > (z)swapin could happen, which is a signal that the zswap shrinker shoul= d > > be more conservative with its reclaiming action. > > > > It also prevents a race, in which folio migration can clear the > > memcg_data of the now unlocked folio, resulting in a warning in the > > inlined folio_lruvec() call. > > The warning is the most probable outcome, and it will cause the update > to go against the root cgroup which is safe at least. > > But AFAICS there is no ordering guarantee to rule out a UAF if the > lookup succeeds but the memcg and lruvec get freed before the update. Ah nice. I didn't consider that. IIUC, having the folio locked should prevent this too. Based on the documentation: * For a non-kmem folio any of the following ensures folio and memcg bindin= g * stability: * * - the folio lock I'll rework the commit log to include this, and make this more prominent :) > > I think that part should be more prominent in the changelog. It's more > important than the first paragraph. Consider somebody scrolling > through the git log and trying to decide whether to backport or not; > it's helpful to describe the bug and its impact first thing, then put > the explanation of the fix after. > > > Reported-by: syzbot+17a611d10af7d18a7092@syzkaller.appspotmail.com > > Closes: https://lore.kernel.org/all/000000000000ae47f90610803260@google= .com/ > > Fixes: b5ba474f3f51 ("zswap: shrink zswap pool based on memory pressure= ") > > Signed-off-by: Nhat Pham > > Would it make sense to add > > VM_WARN_ON_ONCE(!folio_test_locked(folio)); > > to zswap_folio_swapin() as well?