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 0B18EC021B8 for ; Wed, 26 Feb 2025 23:58:48 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 528B26B008C; Wed, 26 Feb 2025 18:58:48 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 4B1EA6B0092; Wed, 26 Feb 2025 18:58:48 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 3524D6B0093; Wed, 26 Feb 2025 18:58:48 -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 167216B008C for ; Wed, 26 Feb 2025 18:58:48 -0500 (EST) Received: from smtpin05.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay08.hostedemail.com (Postfix) with ESMTP id AB336141012 for ; Wed, 26 Feb 2025 23:58:47 +0000 (UTC) X-FDA: 83163763494.05.2E7BA37 Received: from out-178.mta1.migadu.com (out-178.mta1.migadu.com [95.215.58.178]) by imf06.hostedemail.com (Postfix) with ESMTP id B3C2E180002 for ; Wed, 26 Feb 2025 23:58:45 +0000 (UTC) Authentication-Results: imf06.hostedemail.com; dkim=pass header.d=linux.dev header.s=key1 header.b=T8Kqo0MO; spf=pass (imf06.hostedemail.com: domain of yosry.ahmed@linux.dev designates 95.215.58.178 as permitted sender) smtp.mailfrom=yosry.ahmed@linux.dev; dmarc=pass (policy=none) header.from=linux.dev ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1740614326; 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=yswrmCRrVsnZeMvvRyeXCzhvfViLwt8KDXKusOpWbOI=; b=Gb2blS5UDF9VSnKRBj1i8fZtxdwnlisog4+2Tf5Ax/MPvSCNRes8K67xOXud5JLPYhneA1 U/P82J4Vz1EmkpU7y/sB/NadNGjAidJw0wt81zwtFCC2hKCBXtTkJ5ftgojdOihg1ggrVZ k6qmdwQp3U1ORmclKGH1n4+GLT5wlxM= ARC-Authentication-Results: i=1; imf06.hostedemail.com; dkim=pass header.d=linux.dev header.s=key1 header.b=T8Kqo0MO; spf=pass (imf06.hostedemail.com: domain of yosry.ahmed@linux.dev designates 95.215.58.178 as permitted sender) smtp.mailfrom=yosry.ahmed@linux.dev; dmarc=pass (policy=none) header.from=linux.dev ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1740614326; a=rsa-sha256; cv=none; b=Nmw1gUw2craiw1YIAAYIpONz1xWJr0P0LNPqZ38ZBydfsO5XoFkRk6A/NjDwhsBG7Tvr7o z6YUzLqOUCTVDNMlUPZn0MZsuek0CMFLiS9dN+vkzYup+rNWr/dHD5jhMYAC6ejx5HME3l VLgSLfM/NQmQIl5TweLmjjjS3bsPvOc= Date: Wed, 26 Feb 2025 23:58:39 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.dev; s=key1; t=1740614323; h=from:from: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=yswrmCRrVsnZeMvvRyeXCzhvfViLwt8KDXKusOpWbOI=; b=T8Kqo0MO1ZeLalmsNe+Zfiw1jmoaYYsLmXnleDI/1ggc4o2kqX/wPyqiKkf9qKsWl/J+oU XGRzol7hoMsGyrYhK2ngvUz2dUntRBxYHJ8uz4awS2l8vSCPVGNnPUoiHQwbnURFOpJeb7 SB9KuG8Pyt7nI95EOdH1Y9ScQgj2VuU= X-Report-Abuse: Please report any abuse attempt to abuse@migadu.com and include these headers. From: Yosry Ahmed To: Nhat Pham Cc: akpm@linux-foundation.org, hannes@cmpxchg.org, chengming.zhou@linux.dev, linux-mm@kvack.org, kernel-team@meta.com, linux-kernel@vger.kernel.org Subject: Re: [PATCH] zswap: do not crash the kernel on decompression failure Message-ID: References: <20250225213200.729056-1-nphamcs@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: X-Migadu-Flow: FLOW_OUT X-Rspam-User: X-Rspamd-Server: rspam11 X-Rspamd-Queue-Id: B3C2E180002 X-Stat-Signature: t1pcahy85hiz35pspxrdqbm651n1jdqy X-HE-Tag: 1740614325-248490 X-HE-Meta: U2FsdGVkX1//2i/Dn0VB8N89DcxOGBn7e5vn4Mw6xKSuHmSqxPOCPpW6mkSpL890aQXwuOty7bS9MyQ9Hoe+dPdo9M+GfFGXIbDJJiqO9eDEOrjHg6vgjXdTVzrEtxto4zXm6O30J3DB20m3sMt5Q8NsvtULm3ShrlZEob/GJBq/XWmIvDl4nh+p5oxEF58kNu4wrgb78+zWQF4dq3epgP47Alga+pG7D4kjXKFCzadhgQGJWIIj97nGLdI/76mXzRjiFyrSkj/gCH6VrbfEvt1krVNU4fY7axUSQD7dnm3ISBRz+wG1KUVvEUYvyhPH2TC1bgzaHX0EvDLhiB1QOb19KmCqHQVKl7drUqLd0r6zQ9S8t+7gafWy2FsMJZ0wMVdsjfAfoSfcnBpqR4u3CMwREEOrU5quRjzmsoBfMsjYb9pyz0b75q14mJKQjiC8T/5vtUbhEfltxs/sZMmRreIFdL6SlriPnXP6LBI16PwvJIWv6rt0+izJw6wRv8f6rFQ0JJzyFp+bS6EGLWza650yNMwBdGc8+9TlKrM1DVfihqZXiVwuLNMl8SG954JC9tsB2aV2ksrab4vpTvKuT/49t/qumD2jCwcfjA/vgRS1EsQr6caAegdMY/mYWoqUL5nd/NcMxofhw+h+PkBgqMqKF1+b+Rd2M5/z/U+aYEix5w9wHpszRCitIrNM1YgwOk4BDBzBQzkgcdtBzsJ4tdiX70xm8JEUA2RXIsoSTKuYqmzFX2o4joljR+oLAa1Cub4WiyWFy9YHhvBxGvD8xlg7Fv6geyLnxguIn9nyKi323v8LHPyot/Wbco5PqsWUtSO1/aVwQF7OfG5GqLK43n8n23xDQN+OM2h4dLBCPQtVgF3jR9wA5l0z47DhN5BlfZ/CdOrLBUHjrkz8M8GSIQaPUMfy7xJ5uwu3FgueEBindkqgeBHHsfVfcihK/MDL57eBJYp7H5B5pvw9Lv2 Th4GaXU6 MCnm4sLaCaHY5y1yFSwyk0p+voCn61wk58THISl6lHDc1b8KF6gg6vPvJvz1lYaRRfWiMedGMvfE+STZUEvIKPSpBJtyAVhJjZ0E7ISk5KiYarhRteINe9x90Yqn7jC7vUmjF3jUDFGCOtczeFIuQaxvR8v5df2dqkau5XBF/cqOtStkfPj2J2FSvDeVCQRP+nlVaLpqptp2la06/G55WrhygLB3/iYQx64+hA64e4pr2m74= X-Bogosity: Ham, tests=bogofilter, spamicity=0.000001, 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, Feb 26, 2025 at 03:29:06PM -0800, Nhat Pham wrote: > On Tue, Feb 25, 2025 at 7:12 PM Yosry Ahmed wrote: > > > > On Tue, Feb 25, 2025 at 01:32:00PM -0800, Nhat Pham wrote: > > > Currently, we crash the kernel when a decompression failure occurs in > > > zswap (either because of memory corruption, or a bug in the compression > > > algorithm). This is overkill. We should only SIGBUS the unfortunate > > > process asking for the zswap entry on zswap load, and skip the corrupted > > > entry in zswap writeback. > > > > Some relevant observations/questions, but not really actionable for this > > patch, perhaps some future work, or more likely some incoherent > > illogical thoughts : > > > > (1) It seems like not making the folio uptodate will cause shmem faults > > to mark the swap entry as hwpoisoned, but I don't see similar handling > > for do_swap_page(). So it seems like even if we SIGBUS the process, > > other processes mapping the same page could follow in the same > > footsteps. > > poisoned, I think? It's the weird SWP_PTE_MARKER thing. Not sure what you mean here, I am referring to the inconsistency between shmem_swapin_folio() and do_swap_page(). > > [...] > > > > > > > (3) If we run into a decompression failure, should we free the > > underlying memory from zsmalloc? I don't know. On one hand if we free it > > zsmalloc may start using it for more compressed objects. OTOH, I don't > > think proper hwpoison handling will kick in until the page is freed. > > Maybe we should tell zsmalloc to drop this page entirely and mark > > objects within it as invalid? Probably not worth the hassle but > > something to think about. > > This might be a fun follow up :) I guess my question is - is there a > chance that we might recover in the future? > > For example, can memory (hardware) failure somehow recover, or the > decompression algorithm somehow fix itself? I suppose not? > > If that is the case, one thing we can do is just free the zsmalloc > slot, then mark the zswap entry as corrupted somehow. We can even > invalidate the zswap entry altogether, and install a (shared) > ZSWAP_CORRUPT_ENTRY. Future readers can check for this and exit if > they encounter a corrupted entry? > > It's not common enough (lol hopefully) for me to optimize right away, > but I can get on with it if there are actual data of this happening > IRL/in product :)ion I am not aware of this being a common problem, but something to keep in mind, perhaps.