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 0BE2EE77198 for ; Tue, 7 Jan 2025 23:39:54 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 94BF76B008A; Tue, 7 Jan 2025 18:39:53 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 8FC526B008C; Tue, 7 Jan 2025 18:39:53 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 79D456B0093; Tue, 7 Jan 2025 18:39:53 -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 587CA6B008A for ; Tue, 7 Jan 2025 18:39:53 -0500 (EST) Received: from smtpin29.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay02.hostedemail.com (Postfix) with ESMTP id 1E3C712048B for ; Tue, 7 Jan 2025 23:39:53 +0000 (UTC) X-FDA: 82982275866.29.1F17186 Received: from mail-qv1-f48.google.com (mail-qv1-f48.google.com [209.85.219.48]) by imf28.hostedemail.com (Postfix) with ESMTP id 4774CC0011 for ; Tue, 7 Jan 2025 23:39:51 +0000 (UTC) Authentication-Results: imf28.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=uBpvjON0; spf=pass (imf28.hostedemail.com: domain of yosryahmed@google.com designates 209.85.219.48 as permitted sender) smtp.mailfrom=yosryahmed@google.com; dmarc=pass (policy=reject) header.from=google.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1736293191; 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=NIB1dqYl83pKesAErEf0rcfNaYSmP01hRpFHR6K/Is4=; b=QFBro07k3YNqKepQHqIjl+ZUxZukumUJyDbn7I1Zp+HEJJtchEV6OZ2R7yiL0DUUiLiVTF SxkRNBeGsXdI/rvJFTyXX7WRgPu1r6UMy08nv5xYtMB4SVEi7e9UGxepVPdsdLVAw8ssBH EpZwKZRQNMpEw5pfpDWvie6ohTAsC/w= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1736293191; a=rsa-sha256; cv=none; b=35HAOJmCpoF1a3M4Ze9TPYOJvDTi3lbe5pIQVIuDWMwQH7L0cFtD3dzefHzXZIxQoo++Ui SP5maKDs2Ok3fdY1JUXBySytSeK8aJTAvKRdXQrEwpNP2RdeBZ85jtBvJ5XMko43WSb3Jg t2px7wl9BlwtH/A+h+KwGz9ONv/jjY8= ARC-Authentication-Results: i=1; imf28.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=uBpvjON0; spf=pass (imf28.hostedemail.com: domain of yosryahmed@google.com designates 209.85.219.48 as permitted sender) smtp.mailfrom=yosryahmed@google.com; dmarc=pass (policy=reject) header.from=google.com Received: by mail-qv1-f48.google.com with SMTP id 6a1803df08f44-6dd420f82e2so115986746d6.1 for ; Tue, 07 Jan 2025 15:39:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1736293190; x=1736897990; 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=NIB1dqYl83pKesAErEf0rcfNaYSmP01hRpFHR6K/Is4=; b=uBpvjON00OvvbaCnBl611H8+i/GNLroNtQSyhCV4szxF0NNFQgv7j9YW4DaSsqLIQ9 C770e+RcYTO4L6EBBKUUyVWd7LBnsf+775qxHXND+C0csPIK6ehJjg7uGkmaVwF9qOHS A9Yg5cuE86MWwPpzczyYjlCInt8EGDtB2DUhSRpThqAPf6TawWRp/qqOGHsHpVjjQ3Q8 KXoa+Y/XvP0I6Y8yn2OMQ5ME6S0lorJsGn7KETumMqJ9uQWJeRuQGWkwqMfaInXMbozT 2xp5sYoUke+UN/39MNyNXbtXtjsV1RjXegTmHfMNuUEbY+Fab75rELxQpn0Nd0WLSFN0 5BMw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1736293190; x=1736897990; 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=NIB1dqYl83pKesAErEf0rcfNaYSmP01hRpFHR6K/Is4=; b=HKhr0rpfdy6xN3n+jJReHinEkRMcwtT2KdfBSGguVpqrpE6eYBYuuz5f3SxNKR4OVP jhWnYsO0DsbUzr9AQUsnCJOuYlIDaoR5cIMwfkTyh6ixoIkKUuS7oqXc3Xd0tEj/bQsr KVADHwbMMy/biA2u7KVeLCJkeJ1CKcO1OAweT96jVcZ4iuOYIU4JkLTC5/ujcR777eBC QndBAWxIOZbakRAFS8FY8oVgqn4F2ip8F2QdGU7OxGWg9lDFsOls9IlNmezm82lseEJ+ DZUef9k2pUhLsxvG/qYt/blsbzLKwQ7MZDYJQWETs7LSqZl9xp5VZ8C8TtDg5jCMJeMz rZzw== X-Forwarded-Encrypted: i=1; AJvYcCX+HlpNga+9W8fd/8tSezz2+ouVl/+VziDV30Wxl8DUTHb0omNFzF8zQTxWNRn65TazZYBi3bLn2w==@kvack.org X-Gm-Message-State: AOJu0Yyyw9TPI26BzQtRLpXtJeRNgbCe9L3PEX6W5X0Ex+S8N+OJoVQu J32NzQHOvZG2+JiagZpmcRUIe4jBs2YsD1qAyUulHwrEphbOuWz22a9SlPqqq8Ec6SJk36WowUy zpRX+LCxB/6E/AbMCKglkgAUroGj6nfSpveb9 X-Gm-Gg: ASbGncsUV95jeyaCejFgcz856bYlJtK/DIGXgkHLsUAusUP53kZSj/iF8LVVBcozzfd 7iqztYfYA9UHSVpgzvONsmZhRPet0T9zfNZHEu40k8iWRWhDAnQ6OiwOQ40rG3/8twRnW X-Google-Smtp-Source: AGHT+IHxRmICDde8WKDaHO45UQ2BcbByH7YG+i+jPMME1HSzI/W8axzD4Bhx1D+A6cjrfNzy97MMQOeA/hFmoRGWkfY= X-Received: by 2002:a05:6214:1c0d:b0:6d8:8d16:7cf3 with SMTP id 6a1803df08f44-6df9b2cc551mr14893986d6.40.1736293190326; Tue, 07 Jan 2025 15:39:50 -0800 (PST) MIME-Version: 1.0 References: <20250107222236.2715883-1-yosryahmed@google.com> In-Reply-To: From: Yosry Ahmed Date: Tue, 7 Jan 2025 15:39:13 -0800 X-Gm-Features: AbW1kvY9BpAnjlFRwB61Dm-kWZ4-9nFyf8HW0UKOlASfhLYZQkr1H3HxRtKjjMg Message-ID: Subject: Re: [PATCH v2 1/2] Revert "mm: zswap: fix race between [de]compression and CPU hotunplug" To: Barry Song Cc: Andrew Morton , Johannes Weiner , Nhat Pham , Chengming Zhou , Vitaly Wool , Sam Sun , Kanchana P Sridhar , linux-mm@kvack.org, linux-kernel@vger.kernel.org, syzbot Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Queue-Id: 4774CC0011 X-Rspam-User: X-Rspamd-Server: rspam07 X-Stat-Signature: cmc7qayfmb3x5ormzrks9j3cuh4x1nhz X-HE-Tag: 1736293191-411854 X-HE-Meta: U2FsdGVkX188k7ZSJJA7sBpOrEdZT053KQwPDKlaOlg7Ig11O5PTny8miCTDndZWcBJg0EUjuVcrz13hvNsDakg9KYyanvCFx1OYa2ZYk+6HBnZbYhCTfzzTp8Ocyu9WjNsT/BuETpv2Y0KAQ8ULhTLrKTVwoWdjGqKC26eH1MtpCNbayQhMU0/DLdxTshvEEPdw+/+GWqtScHFIdLBWAWqqlkItycEvuQAqkeVbHkNgLW0jnh+ESi2iIRljOPoOwWnmxwpr9zaEzyxbKSVcnSSUxeqETmnlqv4DRriIHn8KPFI4mbhK8GV/c4KWDLCA/dpS5e3UBIZ2AOhzlHh1GoKFLQvm3oiTXkZDq0jkA1XO9YaId8cnnOnaSvU60DmLI6PBqgicq+IGvI7lamJCplBwXFIsaZcE+Lwd+1NTB5sQFtmF+iQ0mxFlASIXGecNcil9/jjO49eERklIUU1Oq6Qpz47G1ThdAtsTyLmau6qoOczGlQU5ecd84UQrWsp7SuJp0UuAWlpFWuVXXAtvXsDriSL2PYJ0Zs1ZyqM7GsOWHLo18Xl4SAxF+C21V1D4RI3j9NctUz7n4Ub9v40thcidNgeDKF+m4IIU/AdLdpB6whfDsant2Y0d+ODTLaMG26Oww7IBvbbXue5SKqAD+jZtxaAAgp0EeJX8Fi3H4QDaNyG3IzZGNGNVVnpIvOlML/1ZxC6wlB7vhAwu4ErBXrq/bQ3hv/6fMcu80Ow5ZVCeApkgIwA347a/YLiYR/W5QvfTYGsoxqFAPgnbwD4uSal/eMg2w+rc6jSEWl11yzujKztdSqUFWOgXLZfSeRlj9redFLzol2CS/f5cb1k5E7suIHCt4yrjJCkzbTIV63SvjcmvJShDtzLRPHlDIVQPPqx3RyOpZSd+qRJzluxjUGpMT9DxEYwXpPGBjjOCq2bY+3Y9InujHclOYLgy/roF9fMg1QZRM7klEnSFYql vI+SBTlb KxWC1Lmit4jceQzlJHsSoEKsSoCy5auIppo2N9ytIthZ1qObUtyjser4pRNCJyjBx0JYXohuZJyio3EPgb/M87iZg4kC/Vyxupu6mI5dm2NXT1ij1BTOSKoLg62wkD9O4yVB8qRWRd7a+lZrlWuTsrLjrKVDuxhKAlb8JREFjHuV1X8kjSNRAHJy34OjYjeUXawT5aCZMp00CBIJw2GGfRQRZuxWngEMH0fKRsWgCPQh4Bqy2wN6UhE4n1g== 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, Jan 7, 2025 at 3:01=E2=80=AFPM Barry Song wrote= : > > On Wed, Jan 8, 2025 at 11:22=E2=80=AFAM Yosry Ahmed wrote: > > > > This reverts commit eaebeb93922ca6ab0dd92027b73d0112701706ef. > > > > Commit eaebeb93922c ("mm: zswap: fix race between [de]compression and > > CPU hotunplug") used the CPU hotplug lock in zswap compress/decompress > > operations to protect against a race with CPU hotunplug making some > > per-CPU resources go away. > > > > However, zswap compress/decompress can be reached through reclaim while > > the lock is held, resulting in a potential deadlock as reported by > > syzbot: > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D > > WARNING: possible circular locking dependency detected > > 6.13.0-rc6-syzkaller-00006-g5428dc1906dd #0 Not tainted > > ------------------------------------------------------ > > kswapd0/89 is trying to acquire lock: > > ffffffff8e7d2ed0 (cpu_hotplug_lock){++++}-{0:0}, at: acomp_ctx_get_cpu= mm/zswap.c:886 [inline] > > ffffffff8e7d2ed0 (cpu_hotplug_lock){++++}-{0:0}, at: zswap_compress mm= /zswap.c:908 [inline] > > ffffffff8e7d2ed0 (cpu_hotplug_lock){++++}-{0:0}, at: zswap_store_page = mm/zswap.c:1439 [inline] > > ffffffff8e7d2ed0 (cpu_hotplug_lock){++++}-{0:0}, at: zswap_store+0xa74= /0x1ba0 mm/zswap.c:1546 > > > > but task is already holding lock: > > ffffffff8ea355a0 (fs_reclaim){+.+.}-{0:0}, at: balance_pgdat mm/vmscan= .c:6871 [inline] > > ffffffff8ea355a0 (fs_reclaim){+.+.}-{0:0}, at: kswapd+0xb58/0x2f30 mm/= vmscan.c:7253 > > > > which lock already depends on the new lock. > > We have functions like percpu_is_write_locked(), > percpu_is_read_locked(), and cpus_read_trylock(). > Could they help prevent circular locking dependencies if we perform a > check before acquiring the lock? Yeah we can do that but it feels a bit hacky, we may have to unnecessarily fail the operation in some cases, right? Not sure tbh.