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 687DBC3ABCB for ; Mon, 12 May 2025 20:43:06 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id E8E356B0088; Mon, 12 May 2025 16:43:03 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id E3BF26B0089; Mon, 12 May 2025 16:43:03 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id D51A46B008A; Mon, 12 May 2025 16:43:03 -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 B69CE6B0088 for ; Mon, 12 May 2025 16:43:03 -0400 (EDT) Received: from smtpin08.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay09.hostedemail.com (Postfix) with ESMTP id 30810809A6 for ; Mon, 12 May 2025 20:43:05 +0000 (UTC) X-FDA: 83435430330.08.0A59604 Received: from casper.infradead.org (casper.infradead.org [90.155.50.34]) by imf29.hostedemail.com (Postfix) with ESMTP id 6B879120002 for ; Mon, 12 May 2025 20:43:03 +0000 (UTC) Authentication-Results: imf29.hostedemail.com; dkim=pass header.d=infradead.org header.s=casper.20170209 header.b=voj0E+GC; dmarc=none; spf=none (imf29.hostedemail.com: domain of willy@infradead.org has no SPF policy when checking 90.155.50.34) smtp.mailfrom=willy@infradead.org ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1747082583; a=rsa-sha256; cv=none; b=xkgsVuheFQgX7e/a0HasRvulq5LRj2lSSBEs8bMZ0hG9mD7NMEShBCx18W0sdMa33ZwSD4 5yzyzcasfsXdYpRE6QTb9MQEW4pcRfSYBVAdOGNcAxQkUBqIaeMASoaGVqYCOvA6ZZmxJR AB3XmwyyfLtPLS1GZ4oRD3Ic5gXO9as= ARC-Authentication-Results: i=1; imf29.hostedemail.com; dkim=pass header.d=infradead.org header.s=casper.20170209 header.b=voj0E+GC; dmarc=none; spf=none (imf29.hostedemail.com: domain of willy@infradead.org has no SPF policy when checking 90.155.50.34) smtp.mailfrom=willy@infradead.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1747082583; 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=Wg98wcvMhHEl7nkgNnx0lyBV38Qm+zLVW0jUJJpZJQI=; b=lKT7kZOgLpnhEpEo5+OFZV2iz/BRviB+5XBQGLlIihYjElvrazF+b9XTlo6Hk7XNgND+nt KaJu5rX9MYGFfwei4ThBWVCFvCH89FtBvjDbriOqzmNz4u1JRiB6PWCRSV8ljySCAMckT8 hd5hZB1wcAxJIyqPBGSyMQpD3Y/hBVo= DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=casper.20170209; h=In-Reply-To:Content-Type:MIME-Version: References:Message-ID:Subject:Cc:To:From:Date:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description; bh=Wg98wcvMhHEl7nkgNnx0lyBV38Qm+zLVW0jUJJpZJQI=; b=voj0E+GC7GVujyZlzXngrUwDpq ju/2rNYOcZ4hm9/xnqhBDf7gRStSaRNgBijO9DlZC/vEszhTqs89cErNFh1e/AVDl3dGw0AVb7i7d XeQYmCvxNGE/7Xuz6Z1nUkhBnJeJpFYPufq8eGkZClCvJfI551LKpqw5PrPmzHe2jFzmYLfS+rp3g mrYUmBIQq9/DEDUvCPdoijq1GzJ5Iq89tQ7K4l3cajtI2sccui6tzs3Aauh+8LWITToyGS9KJUvm2 8bQdacHFovxhE73TxyueEv55ppOIZDDjxSpGgkh/lGms9Ek2t8wh/d+Yvvy3MU/KQhDcAFL47eFMq EaB+D2Cg==; Received: from willy by casper.infradead.org with local (Exim 4.98.2 #2 (Red Hat Linux)) id 1uEZzF-0000000AEOU-3iUi; Mon, 12 May 2025 20:42:57 +0000 Date: Mon, 12 May 2025 21:42:57 +0100 From: Matthew Wilcox To: Nhat Pham Cc: akpm@linux-foundation.org, hannes@cmpxchg.org, yosryahmed@google.com, yosry.ahmed@linux.dev, chengming.zhou@linux.dev, linux-mm@kvack.org, kernel-team@meta.com, linux-kernel@vger.kernel.org Subject: Re: [PATCH v4] page_io: zswap: do not crash the kernel on decompression failure Message-ID: References: <20250306205011.784787-1-nphamcs@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Rspamd-Server: rspam12 X-Rspamd-Queue-Id: 6B879120002 X-Rspam-User: X-Stat-Signature: syhfygg64gth7eabbyff6i4xbmn8qn6z X-HE-Tag: 1747082583-238693 X-HE-Meta: U2FsdGVkX19DTA7qNByA0yHoujEajxBY67Z4YQfv51dogPlkkZOg5FDUYKwWy756RuRZPHPWGfovqU2Rtl3iI/GJt8mKNHWcT38dgFDx6erIC/E8ueyvvyDmocc5O6M7m+GNpr0mx52um4c5fuh0czoUjaQEPYSk0zkMiGhCVhoV/XJKv7ihOCroYbfr1w8Y7tEpD+ySkmEUFxoBtwOqMrpPw9g+O6Mlp4hiB4YSJbEZAiEKHw3IHpTQBxLXkmumrm+8/7XeMyV2SidRg80dBiSHuK5hc4egq3aMdaWGxOoPT2DFMHLMSKuAuTthMkhNMqVFgWaBZLC+85MMeMtu8SkKqA7wBQNlMqbipul577VE6+IiiUe0sQ/RDcRuq9ofH6wkvpm5mox7B6XOz/l0OAIBtozskkUdFg9S2BF0NG2QD0y0c65nkByh57I7DoYhAj15Lzg3ackCSFcwHdEZro9W7CSK3wabe3Ssvywmq0IT5cT36hPpFyXybKLFKkBX56T8boxldiOIg6NPlUtZq+0FsbrNrvOVq/s2LjkXFhQ32bSc7ljgNIaUoE6xkVn37q0wvdKcrjFKMkYnAtl6VCsvjqh+RzaZvd5UyD8wcRBK2f+xlfjl3kb0g8fxx7uMKQGICpPWLo+dOjx/pLiW3CBiIxtKMvdNbcuotrLnKpkfdFq0+KolbWf2r7/HEf2BN+10V4z/FJpROosCEQiChL9/nY8vfqJ6vdXRseWQKb4SyjWXz3yz/116JfoMB6zrrd9YBDuzf5BiFEWvguFo/16+Q3mLkHIwuROKeeHIFjLAqT4A3YVatm3NXLG7KEcKvNnvoYxrUdtev93/vEo2JfxOi6cEQit28u9CPH1ngIyFZxabBWjiIc7UrjYeHIJCUVuciEmSYvYO62JW1YcuXzbgxyN8OoVXIAqq0v1oab1TtuOv00UQQoxOE7JB6XC/7ZjJYl9/Etq1jUKtZCo 2AEQ2hYy rxN05BLZYunXse6xg7TNh90i8CHJu1Fs/V92D2/wrnywtNOTVRHLKO20BIGUuv9sDUsjlnq0ehEsy44EthKXboiddq67eelRVbys3jzk2s4grwlWw636rG4HJDuHZtxchUsepYOg8JxuMC/boPOJoAJgJxZPDXFbuJMPY4HRp2OKwXwg5E1wgF2hvY5nQ6ditNvaf3163/PPVVBXpwV1CJIlDwH7lJ3No+3r9kHMAE9b/R4B3nxJJk//WefzXF9J6+tuKYJCaYbvdxZ1yrmCOHD1xRPYEqukbc3Zsn/Abibmt+kA= 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 Mon, May 12, 2025 at 03:49:29PM -0400, Nhat Pham wrote: > Not a bad idea, just no usecase yet. From the POV of > zswap_decompress()'s callers, any decompression failure is handled the > same way, no matter the cause. > > Where it might be useful is the debug print statement right below > this. However, zstd and lz4 only return 0 or -EINVAL, I think - not > super useful. > > https://github.com/torvalds/linux/blob/master/crypto/zstd.c#L163-L165 > https://github.com/torvalds/linux/blob/master/crypto/lz4.c#L61 > > Not sure about other compressors. OK, fair enough. If there's no better information to return, then this way is fine. > > (also i really dislike the chained approach: > > > > decomp_ret = crypto_wait_req(crypto_acomp_decompress(acomp_ctx->req), &acomp_ctx->wait); > > > > that's much harder to understand than the two lines i have above) > > I can send a style fix sometimes if people dislike this - no big deal :) > > BTW, hopefully you don't mind the Suggested-by: tag. I know it > deviated a bit from your original suggestion, but the main spirit of > that suggestion remains, so I feel like I should credit you and Yosry. The Suggested-by is appropriate, I think.