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 42972E77188 for ; Wed, 8 Jan 2025 20:51:14 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id BAB976B007B; Wed, 8 Jan 2025 15:51:13 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id B5AFA6B0083; Wed, 8 Jan 2025 15:51:13 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 9FC5C6B0085; Wed, 8 Jan 2025 15:51:13 -0500 (EST) 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 7FCEF6B007B for ; Wed, 8 Jan 2025 15:51:13 -0500 (EST) Received: from smtpin25.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay09.hostedemail.com (Postfix) with ESMTP id 1B48180A8E for ; Wed, 8 Jan 2025 20:51:13 +0000 (UTC) X-FDA: 82985479626.25.5ADAC6E Received: from mail-qv1-f45.google.com (mail-qv1-f45.google.com [209.85.219.45]) by imf26.hostedemail.com (Postfix) with ESMTP id 2E87114000C for ; Wed, 8 Jan 2025 20:51:10 +0000 (UTC) Authentication-Results: imf26.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=C6T5D+G5; spf=pass (imf26.hostedemail.com: domain of yosryahmed@google.com designates 209.85.219.45 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=1736369471; 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=Wx/VEGMkeIt5WYq6KEeveH6sAZ8pY1jywkUqWY0DpDE=; b=ao8dP6MKgd+4jmyJ26xEov/FYm7eogpnSC4j4pRTHcehWhureKsaDdfHWoDqgd9+wK/e05 bxiAzTIYQx7fNpM3D+Hit9WJwFhATFM936221fYXhLe3cqFuXfCDpJ7VyTVR8kT+zl05Sw KhkyUV8pM9s8YwbJ4jbfqW2NbimtSng= ARC-Authentication-Results: i=1; imf26.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=C6T5D+G5; spf=pass (imf26.hostedemail.com: domain of yosryahmed@google.com designates 209.85.219.45 as permitted sender) smtp.mailfrom=yosryahmed@google.com; dmarc=pass (policy=reject) header.from=google.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1736369471; a=rsa-sha256; cv=none; b=Gk265jNCtAnMj1FPteRLRrT5NUlvCcKHwrgABy9xDxXcdUzimfujavRumCuN4/Fae13PqW gPVIOBJ5GP98+7YCFGDRVIGJ7haTsKyKle0C0TS6akRSVhH/n2kL3swBF9NWO+gQLIxCNc wdg19i5jFZZnE+nejqb4K+QRUC7Fg1s= Received: by mail-qv1-f45.google.com with SMTP id 6a1803df08f44-6d88cb85987so1808536d6.1 for ; Wed, 08 Jan 2025 12:51:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1736369470; x=1736974270; 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=Wx/VEGMkeIt5WYq6KEeveH6sAZ8pY1jywkUqWY0DpDE=; b=C6T5D+G5p2Aajfi+02FiDTKay0i0W2UeTVCTq+sNv4AueC6eOdKOcvnfIBA38m9sYi NJEP4/R27z2UqPq2C7mVxLoV2rbeS17nqQvJO4aekFy0HtH3WSiSD0Ee3UqJ8Nu5DtWF 0VpMlG1zNnZGLAuGtGQQgmCD1F85HIxnoLdCX/wM+zUFrTgvH1LmFqXNUCcvFBdIVibG IvECOXXzesn/qaMZSuePz7TwQgmSSuU8iFdEi2S5uwF3ML1FQHunzGLd8N9gW/OmdY5k YRhTtyMdotzWIYXtjDNyC14bhjJyALnISpfU4qa36P5pawHEWpz853eB/Lqq7p6ujk3A wHaA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1736369470; x=1736974270; 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=Wx/VEGMkeIt5WYq6KEeveH6sAZ8pY1jywkUqWY0DpDE=; b=cvnkjudkYzcaDPMd0wkY+cLoQbUl4AxCYydKCJ4dGjhm6Bu08T7rMoAezY73JHFJTb j7EPjKt5ix983emku4NCXbfxa3kMsDvbNznOKaTwQd+5r0A2LAwcMKnByVsL6aW1jztI Ci38emeTxI4V5BQAmRfM9OG3vdpdopx62mehdhO6qImGCekq0vtg7c/n86DfWhYHxaMe 2Zp0qBopzoy8FI1t+EDJSWT7ekImY9O+AtNua0+93VB9DcaK6TFHtTH6oOkcYDuZvxLk hGiEXz9LXLWZ6EMus2rsBAGrogkhFdOactqaeFoC4x9IsYiWd17kZzqIVU+QOAQYjA/C cQjA== X-Forwarded-Encrypted: i=1; AJvYcCV/E2NIpIqn52HapUCzh8SoQx2zd/DyeeEcXu37Q9bZ82Ei2bPpFLldqJ2Yj9RKWgNCnUh8bRga4A==@kvack.org X-Gm-Message-State: AOJu0Yy6oA3tGCGy6dti7HFLbVFDWeA5WdjNiOuR9z4wQT/Pl6iJG6GE f4BuAAhYk5jxm2Ztq3wAp+WtMFOyBhSc4pLRalnG7HVsbl1oH8te6bhk8uVAkeTIriFekk6AF1B ZUI9v0hpFvaxToAWr9kq69460Rn2PK7NNSlVw X-Gm-Gg: ASbGncuR6Z8mEA3hFN6Sa3bZdqNwv38SydkgolAIILCOn6W7qRoo/7cUlH7C9dn4eR9 5ew4IHYQ6BDTvGmAZMbYxqPqFpOg6VFdsLWU= X-Google-Smtp-Source: AGHT+IFQNnq/INYgA5nBsQT8tp6CMYs66PK8YQLseNJtE/Y8rrYvRne6lKX5fTDj6weDS2lADETm0mU7k4QbQ1lMFYk= X-Received: by 2002:a05:6214:240f:b0:6dd:d24:3075 with SMTP id 6a1803df08f44-6dfa3ab42b5mr10878176d6.17.1736369469975; Wed, 08 Jan 2025 12:51:09 -0800 (PST) MIME-Version: 1.0 References: <20250108161529.3193825-1-yosryahmed@google.com> In-Reply-To: From: Yosry Ahmed Date: Wed, 8 Jan 2025 12:50:33 -0800 X-Gm-Features: AbW1kvYw9p95QyAd_z1vXO7uv74RqqK16Z8scGAl5-Kxnxx3uwCBPbG6gFr7GQQ Message-ID: Subject: Re: [PATCH] mm: zswap: properly synchronize freeing resources during CPU hotunplug To: "Sridhar, Kanchana P" Cc: Andrew Morton , Johannes Weiner , Nhat Pham , Chengming Zhou , Vitaly Wool , Barry Song , Sam Sun , "linux-mm@kvack.org" , "linux-kernel@vger.kernel.org" , "stable@vger.kernel.org" Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Server: rspam06 X-Rspamd-Queue-Id: 2E87114000C X-Rspam-User: X-Stat-Signature: 3nz9o3y9b6q39kmx4m9ntfsxzc1q79kt X-HE-Tag: 1736369470-871696 X-HE-Meta: U2FsdGVkX1+lb+OEYi8FWJfGXEB+rZ7SoCN+DDkcQX6VO7J7v40CpDNUkO3uKUCkorrXC8cA4PK/rW6Fug5unSYUvogsiNaqy3/fX4xijvKbtLLh/mqeIu2cehkbQIxrPm4v6LtHOahkFiGdjSQcGD6mpA/SyfU1wxKBzrkJnE4TGVhqrcM1yDt2BwF2Wfxsr6V9qL03XBmW5hgLmzblBjOQiN0Qi7DFLyZqpw7pHVc/l9mTBXmT96fzSVi85LR11RNM2lOR1RKcNnXY/dm3NzozjO/7x+69eBwScoRXDBE13SEg6QT0HjLxQ2Qs3dQW1ayziaLgO8N9X5TBtmLbX9o9e4dQ4KkBNpAGywJix0bHhg/ILIyDgbWjmY3USDHjE9HK9pry5n252b9t29W4LfaQWhM3aC/x/2vIIzBE59Ua0ttQx2+ARAhI0MkqkJuLSybjTQ39V2XXYCVjaMkXfltRbYJEH10NOFbDhG/7Vyln10+RC8H7E//UNqJXAX+YDShO37HqxIfcXpH7B4PWTBDbDcWhG+Cpr70y0le1qPVvDvh6ZmR/aTXB4EgkGZ+Qkb+VI2Eh+65I7/MKSdAQwB+iSJezkH6GTOR2x34izV0h5mBANcr2HsGWmYuRHbCF2N8mhxu4PgvVtpfuAwUkZuoO2OrkyCF2CwMukmoGnyEZDpUZoPRpAag2RDdPf6j5Rs6xyFOQbKaGxxs7vTUJ2ySSFe36ut0baVXVcAtxYZIC5G/wYR83LXiTGAa3yuAIKOyUgPyqQTiXd93Sud1LBr93tiNYm9Prog4gmuofxsPLhmcRZYZqPv/LCdfs2/83l22ZlWrRHBTheZ9C9fA6JBa2gl7R74v6cKFTSfm4iuX57C0BCTSfkVoMpIAm7ervBxA0uuedEyOv8/tyITPtI8JluyyJ19m++spP/m1Hp3pH17FySae257BuCoG1KutUmp+PO3FtQZ5Kej7qroE LmPfpzk0 hkskpGVjTnaN7QOxwzZrFxfZdZSRjDKz4ssySf2Pfa2Co8w1+AaezOAaJALX6x33DvTAbPHDazanF5kohJUQHvRMLtjtuuxO+0ycXhHCvhbI0cgQw+q/SrgBgsVcvsKnKDvByKnD6/xq/nai7lo9diFyYq6UTlzIb71Vg5a0umR5tB84fBHvfcj9PSPBV+QEmyPtqOBtgambtSvtIsrsmGuuXc8V0qj6AcF/YFnBfdS1DYYUrHbITWxGmJFdsHVhDoYx5jIy7WvcFv1gK4lfA/jmMsdRQKW/IU4jgpcKEaBjU+U3ph/yDHnQawp1ZggUIBBf3ApTAxUWR5xAO0Vp0YXm3LMLCCOAksWhU8yIHQ4dY16LOSGB5RqvR2gVXJqSEg9ml1s0KAVk0ATvj+mmcbQ+JDi/t9urRofeXlYZbVZYw9K0pCzYrfR7BhUtpX5baYjw7AU2bIGC8tOrLI5OS9KOcEqqmkLx3HFHtkwkDO1O9S9IM2Aff2zeDLh8vgGWDuRNf 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 Wed, Jan 8, 2025 at 12:23=E2=80=AFPM Sridhar, Kanchana P wrote: > > > > -----Original Message----- > > From: Yosry Ahmed > > Sent: Wednesday, January 8, 2025 8:15 AM > > To: Andrew Morton > > Cc: Johannes Weiner ; Nhat Pham > > ; Chengming Zhou ; > > Vitaly Wool ; Barry Song ; Sam > > Sun ; Sridhar, Kanchana P > > ; linux-mm@kvack.org; linux- > > kernel@vger.kernel.org; Yosry Ahmed ; > > stable@vger.kernel.org > > Subject: [PATCH] mm: zswap: properly synchronize freeing resources duri= ng > > CPU hotunplug > > > > In zswap_compress() and zswap_decompress(), the per-CPU acomp_ctx of > > the > > current CPU at the beginning of the operation is retrieved and used > > throughout. However, since neither preemption nor migration are > > disabled, it is possible that the operation continues on a different > > CPU. > > > > If the original CPU is hotunplugged while the acomp_ctx is still in use= , > > we run into a UAF bug as some of the resources attached to the acomp_ct= x > > are freed during hotunplug in zswap_cpu_comp_dead(). > > > > The problem was introduced in commit 1ec3b5fe6eec ("mm/zswap: move to > > use crypto_acomp API for hardware acceleration") when the switch to the > > crypto_acomp API was made. Prior to that, the per-CPU crypto_comp was > > retrieved using get_cpu_ptr() which disables preemption and makes sure > > the CPU cannot go away from under us. Preemption cannot be disabled > > with the crypto_acomp API as a sleepable context is needed. > > > > During CPU hotunplug, hold the acomp_ctx.mutex before freeing any > > resources, and set acomp_ctx.req to NULL when it is freed. In the > > compress/decompress paths, after acquiring the acomp_ctx.mutex make sur= e > > that acomp_ctx.req is not NULL (i.e. acomp_ctx resources were not freed > > by CPU hotunplug). Otherwise, retry with the acomp_ctx from the new CPU= . > > > > This adds proper synchronization to ensure that the acomp_ctx resources > > are not freed from under compress/decompress paths. > > > > Note that the per-CPU acomp_ctx itself (including the mutex) is not > > freed during CPU hotunplug, only acomp_ctx.req, acomp_ctx.buffer, and > > acomp_ctx.acomp. So it is safe to acquire the acomp_ctx.mutex of a CPU > > after it is hotunplugged. > > Only other fail-proofing I can think of is to initialize the mutex right = after > the per-cpu acomp_ctx is allocated in zswap_pool_create() and de-couple > it from the cpu onlining. This further clarifies the intent for this mute= x > to be used at the same lifetime scope as the acomp_ctx itself, independen= t > of cpu hotplug/hotunplug. I mentioned doing this initially then dismissed it as a readability improvement. However, I think it's actually required for correctness. It's possible that the CPU becomes online again after acomp_ctx_get_cpu_lock() decides to retry but before it unlocks the mutex, in which case the CPU being onlined will reinitialize an already locked mutex. I will add that and send a v2 shortly.