From nobody Tue Apr 7 03:12:02 2026 Received: from mail-dy1-f171.google.com (mail-dy1-f171.google.com [74.125.82.171]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id D042F18A921 for ; Tue, 17 Mar 2026 01:48:20 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=74.125.82.171 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1773712102; cv=none; b=YoqxxsH8QSTdSFNciVnHskZl4VqT13SVVjpyJu6DlidsV2cG5DMYeCD/gG+fwauvgl5CUIouUCaygktaAwatyCPSUgungMWnyFzvTADJBSXoM7BodmMUi52oX+xa/MzeSPnG3B8b4EKJvQHY3q/8pkXlZSIKa4C+W8+wWQt5zCY= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1773712102; c=relaxed/simple; bh=K/l5wPzkypoBGGowWuf5aDp8l9HqTc1CTviVyc6uyFQ=; h=From:To:Cc:Subject:Date:Message-Id:In-Reply-To:References: MIME-Version; b=GTUc1yY5AiO9NpZ2Bij3skVAGo2Mhrpx18RKeUg9W5gIfujfrA74L0ftpPGP0qc2q567rMhUxlXcAb7VQnkdee93+D5hKvualsPzxyk6rtX16JoriF0IPzPM9uppbB1ovAsp/SrtJNTW1WR4SOjuogkS21dakTCkhqtLBDYFZKw= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com; spf=pass smtp.mailfrom=gmail.com; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b=WO6yKgp4; arc=none smtp.client-ip=74.125.82.171 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="WO6yKgp4" Received: by mail-dy1-f171.google.com with SMTP id 5a478bee46e88-2c0c955a481so2412225eec.1 for ; Mon, 16 Mar 2026 18:48:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1773712100; x=1774316900; darn=vger.kernel.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to; bh=woq8g++l5pYTnrwN/CGFOIvueDbJv5G2Fq6vUnhRrQA=; b=WO6yKgp4LIx7RfVDJv0FWpd8kuBcNtQS6lsgF8Y39/KoCCYl4CNUE5xAM/Diezl6+t 8YMsF38VOkGcghC919fdqcioS5hc+h7gTYnraQjEUYPKfLffPLgYBwf7IByBeTicYewp 4KoC193eWE1dqZ2IpAmnm6ZDOB9/LK6616RyuYgfRNkrA1zjW6gFOYIFRirapNFvK0jP UT6nZkfPiEtttX7/zus5kek6mmfIzC8M7I7eWky0Lnnshc8X4HApZrnVDg33YsLsmByD JmSSaHFdUo4gGKnQt23z5YRf1uQCuaMlxssR+Um0pD7sXaCyQhBdjx8kc0gXMmEgq6m9 QI5g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1773712100; x=1774316900; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-gg:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to; bh=woq8g++l5pYTnrwN/CGFOIvueDbJv5G2Fq6vUnhRrQA=; b=lu2IADQvPCAit15NnaL6ABuY2eCqlLVKfKPlrn19c4SQClD30yVzj0f9/7k3Ti7duJ XpHqoSi9o+yy4t5pnCdvO4JtfKTgWSEN5Bjz70wHZEydLxGXcoscZ+rSDoKHHb/QsEA0 pd1soGdSVpNbcaWheOyLCHFwJ2Kjqpe9t0EOkTRg5k8EuhRu6A6P4pdm+j8zUlfNLMV+ CZrflb2iWBRQBwItoz5plQ5HyfbdlozGnBvhm7IfLS8zxfhe1/mVkgt/qt0ohtR1EKTk HBMfXGKtXv+gpanoUapLpy2FL4RZ2hIeg9POw7uEwyHMD4YMS2nLz08YglDcpLeWNQoA VPqg== X-Forwarded-Encrypted: i=1; AJvYcCXtWftdPH89CWWRXIw+h3YPRuYxeQvymiJrpWYp90K4zC7JaXGGk4oO2F16rkrET4BUOir3/onmyYBikMQ=@vger.kernel.org X-Gm-Message-State: AOJu0YwTCHBvw3xU9t3ZOu6JQWbQlz6fFSiH86atpB9l/CTa8UyRWRhb zMlHrj8muIDOTk7IVNfj7ZFgiljbRIbSU0GUiinW0+ewDx9OAm+NAD5a3zkX7AB4n2U= X-Gm-Gg: ATEYQzz0kQwd0viTyWgMIKmPRvQdBRU81LkcqoJQMENyszRmkQlEXE27pG6yx5SxXoy T6+DYNeIdDzwkJ6e5fY5nFCcueAzqA6DkAwqoqiG1tEgbbe4WO5f9DfqwRknf3ccqb7mtL2lhN/ JQ5qJIUkEGrFw/PPtM6Pn6A0xtS3KLnMB43ibAVcs4HzEtRZXclVOFZuOSz3z5jjfGeTBN3nNg2 viPHyAYq0Hl25NInZjiB7DoXnahd/YtI2mi6mdFmpAIDNDaVyGALduNMveo8cQnzOB4dJwP+v1n cRY+13d5t6o7mWoELUzvz+NzdZlpI4NAsHc6tJ1Cf0xy7Fsbh/meF4HPakySHe/IoJJJTG3kIch pi8CdwOBh1ZIlywk+dUM3J3jQlIK6quuhhP6l0AO2EFNNw1Sx1xzPW1oIcvXYXXk+jDtu2a7aM+ 90qzLyb8dXB+96o2fEqSRO5CAhyXhvGXzes/mgsQ== X-Received: by 2002:a05:7300:fd02:b0:2be:8216:57db with SMTP id 5a478bee46e88-2bea5418f42mr7112556eec.3.1773712099946; Mon, 16 Mar 2026 18:48:19 -0700 (PDT) Received: from penguin.lxd ([2601:647:6400:3ec0:216:3eff:fecd:e4ef]) by smtp.gmail.com with ESMTPSA id 5a478bee46e88-2beab3a12e2sm17931130eec.2.2026.03.16.18.48.19 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 16 Mar 2026 18:48:19 -0700 (PDT) From: "Kanchana P. Sridhar" To: hannes@cmpxchg.org, yosry@kernel.org, nphamcs@gmail.com, chengming.zhou@linux.dev, akpm@linux-foundation.org, kanchanapsridhar2026@gmail.com, linux-mm@kvack.org, linux-kernel@vger.kernel.org Cc: herbert@gondor.apana.org.au, senozhatsky@chromium.org Subject: [PATCH v2 1/2] mm: zswap: Remove redundant checks in zswap_cpu_comp_dead(). Date: Mon, 16 Mar 2026 18:48:01 -0700 Message-Id: <20260317014802.27591-2-kanchanapsridhar2026@gmail.com> X-Mailer: git-send-email 2.39.5 In-Reply-To: <20260317014802.27591-1-kanchanapsridhar2026@gmail.com> References: <20260317014802.27591-1-kanchanapsridhar2026@gmail.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" There are presently redundant checks on the per-CPU acomp_ctx and it's "req" member in zswap_cpu_comp_dead(): redundant because they are inconsistent with zswap_pool_create() handling of failure in allocating the acomp_ctx, and with the expected NULL return value from the acomp_request_alloc() API when it fails to allocate an acomp_req. Fix these by converting to them to be NULL checks. Add comments in zswap_cpu_comp_prepare() clarifying the expected return values of the crypto_alloc_acomp_node() and acomp_request_alloc() API. Suggested-by: Yosry Ahmed Signed-off-by: Kanchana P. Sridhar Acked-by: Yosry Ahmed --- mm/zswap.c | 12 ++++++++++-- 1 file changed, 10 insertions(+), 2 deletions(-) diff --git a/mm/zswap.c b/mm/zswap.c index bdd24430f6ff..8ac38f1d0469 100644 --- a/mm/zswap.c +++ b/mm/zswap.c @@ -749,6 +749,10 @@ static int zswap_cpu_comp_prepare(unsigned int cpu, st= ruct hlist_node *node) goto fail; } =20 + /* + * In case of an error, crypto_alloc_acomp_node() returns an + * error pointer, never NULL. + */ acomp =3D crypto_alloc_acomp_node(pool->tfm_name, 0, 0, cpu_to_node(cpu)); if (IS_ERR(acomp)) { pr_err("could not alloc crypto acomp %s : %pe\n", @@ -757,6 +761,7 @@ static int zswap_cpu_comp_prepare(unsigned int cpu, str= uct hlist_node *node) goto fail; } =20 + /* acomp_request_alloc() returns NULL in case of an error. */ req =3D acomp_request_alloc(acomp); if (!req) { pr_err("could not alloc crypto acomp_request %s\n", @@ -802,7 +807,7 @@ static int zswap_cpu_comp_dead(unsigned int cpu, struct= hlist_node *node) struct crypto_acomp *acomp; u8 *buffer; =20 - if (IS_ERR_OR_NULL(acomp_ctx)) + if (!acomp_ctx) return 0; =20 mutex_lock(&acomp_ctx->mutex); @@ -817,8 +822,11 @@ static int zswap_cpu_comp_dead(unsigned int cpu, struc= t hlist_node *node) /* * Do the actual freeing after releasing the mutex to avoid subtle * locking dependencies causing deadlocks. + * + * If there was an error in allocating @acomp_ctx->req, it + * would be set to NULL. */ - if (!IS_ERR_OR_NULL(req)) + if (req) acomp_request_free(req); if (!IS_ERR_OR_NULL(acomp)) crypto_free_acomp(acomp); --=20 2.39.5