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 7DD4AC77B75 for ; Wed, 10 May 2023 00:39:33 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 8D4CE6B0071; Tue, 9 May 2023 20:39:32 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 85DD16B0072; Tue, 9 May 2023 20:39:32 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 6D76C6B0074; Tue, 9 May 2023 20:39:32 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0011.hostedemail.com [216.40.44.11]) by kanga.kvack.org (Postfix) with ESMTP id 5A4936B0071 for ; Tue, 9 May 2023 20:39:32 -0400 (EDT) Received: from smtpin11.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay07.hostedemail.com (Postfix) with ESMTP id 24F0016039B for ; Wed, 10 May 2023 00:39:32 +0000 (UTC) X-FDA: 80772486984.11.5C44943 Received: from mail-pl1-f169.google.com (mail-pl1-f169.google.com [209.85.214.169]) by imf08.hostedemail.com (Postfix) with ESMTP id 47B4116000B for ; Wed, 10 May 2023 00:39:30 +0000 (UTC) Authentication-Results: imf08.hostedemail.com; dkim=pass header.d=chromium.org header.s=google header.b=nXY2qvmG; spf=pass (imf08.hostedemail.com: domain of senozhatsky@chromium.org designates 209.85.214.169 as permitted sender) smtp.mailfrom=senozhatsky@chromium.org; dmarc=pass (policy=none) header.from=chromium.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1683679170; 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=ZcViK9IobKDKWPhV8NMoXtvaRoAckuBG9q8Pc6JSThg=; b=yse/uccjpaYSZJ4TgPR+VIJCaKnVbuyieZfMLpCsOsDodwCHbmgEYTIHy5CYl4CCCArrwA hFHYd6CS8a/1BvhCOkvFTKGDCboN3/J2e61azQs2nHWeB4/jJ09/LdreK5rjmagxzrw454 1x87xUiNSXKrpmghuMexX8HslIxa/zQ= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1683679170; a=rsa-sha256; cv=none; b=ti8wV0xtsotiWw2tzXyFCVnBBkD9PLzqJHeFE//BtxSh8QX898pGf+BewcqwG5J79oiiXh 4VuXaDeDu8E1aQ7gyMW7R3xCjox9dI4Ei1n0HqMtocUllizuUmNcdILBj7ay2g7bJdzzgg lYXlixNEU5HjMlW0ZDdWepBKnFqd4lg= ARC-Authentication-Results: i=1; imf08.hostedemail.com; dkim=pass header.d=chromium.org header.s=google header.b=nXY2qvmG; spf=pass (imf08.hostedemail.com: domain of senozhatsky@chromium.org designates 209.85.214.169 as permitted sender) smtp.mailfrom=senozhatsky@chromium.org; dmarc=pass (policy=none) header.from=chromium.org Received: by mail-pl1-f169.google.com with SMTP id d9443c01a7336-1aaea43def7so45490045ad.2 for ; Tue, 09 May 2023 17:39:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; t=1683679169; x=1686271169; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=ZcViK9IobKDKWPhV8NMoXtvaRoAckuBG9q8Pc6JSThg=; b=nXY2qvmGJh7n28CT9igHKbqJhLwZbxCmkmJruRksz7lOOJuVke+sKIur9g8YYh/aOt jPCSVSvLW8jbZfXorsMloqZYr0kCzmHAZxlbUDDYNINlHwjKpBqDQisRLHmoiuoXmPwH 0aHMsLMekAm1ZNNCi5dUMtMEP8cQqiXJzLzbQ= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1683679169; x=1686271169; 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=ZcViK9IobKDKWPhV8NMoXtvaRoAckuBG9q8Pc6JSThg=; b=VEZhpnqixQCDKXswlLj4MzZDjy7gxFXuMNCqEenk4vX5g1zoAT5L0iC1tAXt90clnl 08Fb1CyobZUlt4fhLhZ2JPEFCLDKqeZtrPPNmIEcRWZKoaAKLE/Pqatm4pl11N2CkmGb Q8YkMeuMAS2VOHnXIUNWTFgYXIvtLlsAzQJ9fQFxrO3i8z/ljrebAmSYLyrmbWdT0Hlu 2CFXQgVJB4oAfq2/OimnrJh/Dpa1YGhaZEOLGWszBKAMClZyIL34NGHeBp4pGPaAidPx sOlcuTdyp+X+GYo/LJY+lW2KuqpdtiLTkDoM1bw/Ni/OBwp7ISyPxEHpgZclyIbl5mEn UMWA== X-Gm-Message-State: AC+VfDwDDICcrTk5g2NoMK73Fku9Q2Npn5Hu36RgXB7ky7X52UScxLOo YGy5Bql/hu8zw/Xik9uw4Mk4Sw== X-Google-Smtp-Source: ACHHUZ7VeUOPvO8vvgYTw9Zp2bTuVqG5xU+a1K/++6VYrIoBAxq1tEqbeBiwSSts7jOHtj9FuOI3cw== X-Received: by 2002:a17:902:a50b:b0:19a:9880:175f with SMTP id s11-20020a170902a50b00b0019a9880175fmr14549353plq.51.1683679169061; Tue, 09 May 2023 17:39:29 -0700 (PDT) Received: from google.com (KD124209188001.ppp-bb.dion.ne.jp. [124.209.188.1]) by smtp.gmail.com with ESMTPSA id p16-20020a170902e75000b001aadd0d7364sm2277606plf.83.2023.05.09.17.39.25 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 09 May 2023 17:39:28 -0700 (PDT) Date: Wed, 10 May 2023 09:39:22 +0900 From: Sergey Senozhatsky To: Nhat Pham Cc: akpm@linux-foundation.org, hannes@cmpxchg.org, linux-mm@kvack.org, linux-kernel@vger.kernel.org, minchan@kernel.org, ngupta@vflare.org, senozhatsky@chromium.org, sjenning@redhat.com, ddstreet@ieee.org, vitaly.wool@konsulko.com, kernel-team@meta.com Subject: Re: [PATCH] zsmalloc: move LRU update from zs_map_object() to zs_malloc() Message-ID: <20230510003922.GF11511@google.com> References: <20230505185054.2417128-1-nphamcs@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20230505185054.2417128-1-nphamcs@gmail.com> X-Rspamd-Queue-Id: 47B4116000B X-Rspam-User: X-Rspamd-Server: rspam06 X-Stat-Signature: 6d6iftf3hbcq9yzmruer4u68d9rkfztt X-HE-Tag: 1683679170-956744 X-HE-Meta: U2FsdGVkX1+D28b5skCa0XN3zt4UsBBPr94l68LrM+lg/OHByddxLe1zRS5NM4bG8i7YfNq14Rmwkmv+LJMuxlj048uJlFsQa2fs8o0ts2FyDFX6MDd4uPFm0rIsjizB1CI8WkdvXBpbEBDwSCaTFmsUm5N2xY5Eq81Op56OAZlfP7rMpjt7raY+CvKHfMdWVVWH7V2VNWXCC915kiE5JHmzjv4UjR6IbMOwawaxuEjSTvMV/58y6Jjo2dtJfapcD6wY2QnIZdP0Kdp8SiU19LcT0c/IkBC8JxxYmN+jWoVvIrg8gc492ch2091XDj1TjVLmgXP+dpdNxJtiFy5qs1cP2dqIFd9Kj1nJQYZkjpkoHCmPRtLHhm1sv9iBpSaOC/QzoV3BcOgjw8KA7uAtznbIxvN+AXdRkjJVDLuqRok6DTmRmzdMX5qjQWJ5mTI/NAswsJJhn5nW5X2Kzq6j8AV6/TZyg0uG74/kFk4j0wj+iXcXog3P2jQ9iA0n35T4NXoHTA4Wo+iFUltLLDPk0WofamEZdQ08/o6CUhzEc7jGEYLGDajsOagl/EE5zjL4oC5v16JCLGO66XmT9LEuzd+HjOS/KaoQ0dTQPrGw1k5xOUhMjEnjZKFUOAHBGFIjCuqGCl/WFNimZzFB9yNrJnrP4jsbJsT4ti9Uu39zkf0AyEy2/tiVGZAogAMDzJlrpUAwka54OGOxhDCgO/yyNXSecG7W63MOooKzDchNSwmbMBzbDnP2Bkjo2AMy3R8JLGqpX9/5GSHn2OUc87lQt/PC/1mLfapdzfHLTiqWq9f0jNEXsRwCBs/FdhCdyBDWJ77GRZrbHWdijkLD47KruCSI1BkkiVyFAh7tPSzoey4tqkL0WosSOmDsEz7yqCaI2LJMzje3wctANp3qDcuoDQwi+uG2/mrFcnrgYfD0RuQ9WXoFqBIsDQc6ZWI6npv2Ecs/TJ70XIBzbEUg07c EpGvJMn/ pZ6EzUVauP14zmg5jMGM+M/owV9fvyP1dUiBJyRW43I7ZukXTOLr3sV7rebkbZ7M2hDYcY/2P3E/GHcJ/YfBzE8qrX+MjgN+LhXKXQXW67djANLu96q8cxaINRSIGySMcbWtzkhP+ZQrTBGUd5wmc5hQwHXSlZ7hNjVceYYUVyrfnjOWAc/OgdS8K84RNJricG64LNJO3rzrCf5+NlEQU3uPrzsQyV8RU9IPlo4Vza+VloWE94ZFdP4IJimKUmu14M19NYOU7Pnu4bt7w+SFcHLAFZFplC9gHqAcaqeGRD1+xc8cbO6AXAIM8k/OqAiz/BJ9Gcqcp2X5BFAzhYnu4RGapI/7yFyA9UCxpEopyaQgU7pyTOffbvwGRMb3GxrFHhT7KHEBdyF1yCwm4t/U7SydKts/srAAVxqcyWl5Usd2c3TG2XKHUmrsKYkjJen8bbDCKwZgXv4UUtkaidCddONxBLJS6UJOKm6XzJVeCBT/Pt6lt1RKRqc7gRw== 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: On (23/05/05 11:50), Nhat Pham wrote: [..] > zswap_frontswap_store() shrink_worker() > zs_malloc() zs_zpool_shrink() > spin_lock(&pool->lock) zs_reclaim_page() > zspage = find_get_zspage() > spin_unlock(&pool->lock) > spin_lock(&pool->lock) > zspage = list_first_entry(&pool->lru) > list_del(&zspage->lru) > zspage->lru.next = LIST_POISON1 > zspage->lru.prev = LIST_POISON2 > spin_unlock(&pool->lock) > zs_map_object() > spin_lock(&pool->lock) > if (!list_empty(&zspage->lru)) > list_del(&zspage->lru) > CHECK_DATA_CORRUPTION(next == LIST_POISON1) /* BOOM */ > > With the current upstream code, this issue rarely happens. zswap only > triggers writeback when the pool is already full, at which point all > further store attempts are short-circuited. This creates an implicit > pseudo-serialization between reclaim and store. I am working on a new > zswap shrinking mechanism, which makes interleaving reclaim and store > more likely, exposing this bug. > > zbud and z3fold do not have this problem, because they perform the LRU > list update in the alloc function, while still holding the pool's lock. > This patch fixes the aforementioned bug by moving the LRU update back to > zs_malloc(), analogous to zbud and z3fold. > > Suggested-by: Johannes Weiner > Acked-by: Johannes Weiner > Signed-off-by: Nhat Pham Reviewed-by: Sergey Senozhatsky