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 0CC2FE77197 for ; Wed, 8 Jan 2025 00:34:30 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 74C176B0082; Tue, 7 Jan 2025 19:34:30 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 6FBC16B0083; Tue, 7 Jan 2025 19:34:30 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 5C3986B0088; Tue, 7 Jan 2025 19:34:30 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0012.hostedemail.com [216.40.44.12]) by kanga.kvack.org (Postfix) with ESMTP id 3E4ED6B0082 for ; Tue, 7 Jan 2025 19:34:30 -0500 (EST) Received: from smtpin13.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay09.hostedemail.com (Postfix) with ESMTP id 6A2F480525 for ; Wed, 8 Jan 2025 00:34:29 +0000 (UTC) X-FDA: 82982413458.13.86028F0 Received: from mail-vs1-f43.google.com (mail-vs1-f43.google.com [209.85.217.43]) by imf29.hostedemail.com (Postfix) with ESMTP id 8F2DE12000E for ; Wed, 8 Jan 2025 00:34:27 +0000 (UTC) Authentication-Results: imf29.hostedemail.com; dkim=none; dmarc=fail reason="SPF not aligned (relaxed), No valid DKIM" header.from=kernel.org (policy=quarantine); spf=pass (imf29.hostedemail.com: domain of 21cnbao@gmail.com designates 209.85.217.43 as permitted sender) smtp.mailfrom=21cnbao@gmail.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1736296467; 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; bh=WXR4FkH3LYEri64QgwfAM+8GZSYiedJ170VY4fJgr2Y=; b=5MW8JXQmjAqCpklvVuiCXOwanF6Of3EVSPxkVbXYpQxWienZBftJyqobNihl0GnUXEBzLx /+zKQx1AxoGFHdpSeCzYd3+VUfIo2+TYJmMc9QgEilk5xLvS52KYh9QvkZqAVYxIUOvYhD 3wlS3qtA3diJ4bCz4bebCwvMWhU+bwM= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1736296467; a=rsa-sha256; cv=none; b=baQR32bmWhoQvIZmiVdo2Gu4OCulnXfCkyreRbuz5rlzKIpgXuygY1gx3D4MMLVx+G1g1N g5BpuTWVEW61ZZ5EsA4D56a1uQyvNIr55kcQh2k2+3jCLgKOZOGaI79D45yrlL2b4XfAG9 A/H3ponS4H4oh8A17ZsSpRQxCT36aao= ARC-Authentication-Results: i=1; imf29.hostedemail.com; dkim=none; dmarc=fail reason="SPF not aligned (relaxed), No valid DKIM" header.from=kernel.org (policy=quarantine); spf=pass (imf29.hostedemail.com: domain of 21cnbao@gmail.com designates 209.85.217.43 as permitted sender) smtp.mailfrom=21cnbao@gmail.com Received: by mail-vs1-f43.google.com with SMTP id ada2fe7eead31-4b10dd44c8bso4591260137.3 for ; Tue, 07 Jan 2025 16:34:27 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1736296466; x=1736901266; 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=WXR4FkH3LYEri64QgwfAM+8GZSYiedJ170VY4fJgr2Y=; b=oa4WCtYZqU/h6CpfRnJtegYRi9ETIvOWR3Dtz8OhqgWI5yyO3LTzPIhq0XYJjC2N7s nt8Jhy2WepSzASLVfke5je7UqamyCaXPUBzl9ciGmWYeDEQH+WOnhlKICZkAZzwcldBh PgUUnJd6oHckmkLvC31NsCu4KphD7K2ZgPZlMDOoE06/4enpFbT7ps2L8Ot8VfuhtRm+ WIjC6v/XRKzv2v/BUyR/0/Z+kjjJ5U4fIBr66bA3kDwEUYjpRATzWbnt2KFu7iuBIuWv Nk2PV6GF1Kuy56AblDz07XGHopmVcoUjhhOUNXBz2FpMSqO9QdLWRTPADmGI4PRMGAow 4E5w== X-Forwarded-Encrypted: i=1; AJvYcCWhwnojW8VdbmlWEZUDOvGGVAtIC4DdkS8fg6dzgKfe26YIn6AYJyIF80E4POJjmGs6RC0f7CWiew==@kvack.org X-Gm-Message-State: AOJu0Yw96CRJVc22u2IGIYtqRAkjUdCLslXAiLqPm4brlTyDB7YUbmrx YoYM9QhnIr4oexQXZmX7tNJD0WutIwjhNJFxmgM/S1dzgK8QyDGgMJHFp+Z6a3eO6OF2kWXspxZ q5O6z1vGcIaw6231AoYp5eq1Vz+g= X-Gm-Gg: ASbGnctl6OCEdFeNYq8B4soml+tnskNh/P4V9Pen5ZOyRr6nbKDDcd7mx4EHqVb/MqP BHSeYfoZX5GqKxklA69zE84/bVGB+eJXt5iSFiN8CM+3oumJ5zOv6JsxzPiF8wMYofxctaXU= X-Google-Smtp-Source: AGHT+IExH6x0qTF2jzVT0i6wjIz63AzvkDBylR5RNx/SqPZjtD14pmzjmudG4a/TmZ44djBeY10SeMJ+GLd6/Phszf8= X-Received: by 2002:a05:6102:a49:b0:4af:f1fb:1c36 with SMTP id ada2fe7eead31-4b3d0f9484emr829794137.8.1736296466731; Tue, 07 Jan 2025 16:34:26 -0800 (PST) MIME-Version: 1.0 References: <20250107222236.2715883-1-yosryahmed@google.com> In-Reply-To: From: Barry Song Date: Wed, 8 Jan 2025 13:34:15 +1300 X-Gm-Features: AbW1kvZhfCD_7d95qkNuGm3rJ_YYsgcdl6zzV1Yjg4Z4zN0WTuuJBFn0HSNuQ1w Message-ID: Subject: Re: [PATCH v2 1/2] Revert "mm: zswap: fix race between [de]compression and CPU hotunplug" To: Yosry Ahmed 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: 8F2DE12000E X-Rspam-User: X-Rspamd-Server: rspam07 X-Stat-Signature: ez8a93eq38e6gcpch1uoo1sbyyqmq97e X-Rspamd-Pre-Result: action=add header; module=dmarc; Action set by DMARC X-Rspam: Yes X-HE-Tag: 1736296467-485247 X-HE-Meta: U2FsdGVkX194jJtZ5vV0j84DWEGceGGOFhmv3qyYbCyc/Cn5Z0rKSdpVDXhbAPFOPxxzEjN8JIp/jPxPmfo6EeIdMM2GWaZGam4eeB4CgtyU6AW80JQiBwwlADzct8xjRx1eS9LsBJoezH/4fOYQiQWQFrCzQdfK9ymRrecjl2k5AMe5vGPjTYER3KacgEbQRL9KseLFmj/RY8exU0JLRUAqhenz0EyXj8a8btpZPByDLcZVKSsn28aEHEpI0qieo0evO6Z+IZBhJ9lKVuxdTpLOEvxiDmOxi1Hs/aYbCKCTLDdlKc2x8Y9j61PRJSlI/NCtFnS2ExeaiI7EHGzPhKQtW+PT3toFwG0X5JsdKSN/+FQv4hSJqobri5bw9azDnIIZ5I6oHGJXyt/2cYfHZeO7m7cf5YOzp8puNWzQU8aU8KgOcLpPGH+QN6UYLf9UWoMsYDys37EQumUbyNLrbrwL9hv7mbMgKggxKUj5EwTS9P5+VXp1VgXRJ10tnpt4NfepGtHI/d1CV61Qf9JMDceQHMgH7NHvyO/PQBt4Ie/jhCUtR7O4QDOrdXstBsqS6oJX/RCbTvdUlCXs5r+bdfrBEW3g5szk9xeGxV3EOouNILtgZsGsrEbckKpoSRX5guW1ZX1btteT0eGfr5xqZ5GEoaCYFT2qaS73fLfkYNQObK0e6xHFPl4BiFJzQynStRBqCK4nUjvikKFQyCiu6+lRD5eYeB0rRb/vmXrxDJG/QQ3lo5xQGe25XQxysQ45S6OsQFDh5ECJCG5ofPKm1/thUe/AzjVtYcrYJKqC0rbT2pwPAwFf8tni8sdf/TrbQpH65bqv+LM8gLUN4VTwdU+whDqnaSfMBecMJ73YMKvl1Uv+yA+umCrF8bMT8qJFdSVDlsRSI/ei3JA+D+YLVuvXf0k0zpcUopEUeGtJZWSnbjQ3lwd97IWocpk/GUgb4KGJS6k9T0feMhK/E8i s4GpPILd etMy842XyLo3wYV+s8LfSBJjIKf0B7Idzovr5rnUI7eQl02APWZD8MZtBkkfbUxKtAL4j+ONabK+XPryVxrqyyeMRjeiFejbX2gGPmsYt/uU+1Ik7JtTwsFh6GpssaOWa3vt2Ox+r6H3to+aloDjB+YKRKb70Y6TMCokGEfBdG6mAYouBsUh4p0VNI9d0lUlgZT5JstjhEJBTq+LbPI3p6G+yztjTlxa/XU8NDZalm7uSchgVz3fXxxix4PRc3Ooizcr9QUal+yQ5APhXcbuo5/pqrghHknOUEeQP2FfsGw9G/MD1GgZra2cSeAnIMrlee3NToQa/RpMmlm/tuZxeYOql8A== X-Bogosity: Ham, tests=bogofilter, spamicity=0.000418, 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 Wed, Jan 8, 2025 at 12:39=E2=80=AFPM Yosry Ahmed = wrote: > > On Tue, Jan 7, 2025 at 3:01=E2=80=AFPM Barry Song wro= te: > > > > 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/decompres= s > > > 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 whi= le > > > 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_c= pu 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_pag= e mm/zswap.c:1439 [inline] > > > ffffffff8e7d2ed0 (cpu_hotplug_lock){++++}-{0:0}, at: zswap_store+0xa= 74/0x1ba0 mm/zswap.c:1546 > > > > > > but task is already holding lock: > > > ffffffff8ea355a0 (fs_reclaim){+.+.}-{0:0}, at: balance_pgdat mm/vmsc= an.c:6871 [inline] > > > ffffffff8ea355a0 (fs_reclaim){+.+.}-{0:0}, at: kswapd+0xb58/0x2f30 m= m/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. Not sure if it can be as simple as the following: locked =3D cpus_read_trylock(); .... if (locked) cpus_read_unlock(); If this works, it seems better than migrate_disable(), which could affect the scheduler's select_rq especially given that swap is a hot path :-) Thanks Barry