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 7288FC021BE for ; Wed, 26 Feb 2025 03:12:45 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id C99CD6B0095; Tue, 25 Feb 2025 22:12:44 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id C233D6B0096; Tue, 25 Feb 2025 22:12:44 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id AC3CF280001; Tue, 25 Feb 2025 22:12:44 -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 8E0056B0095 for ; Tue, 25 Feb 2025 22:12:44 -0500 (EST) Received: from smtpin13.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay07.hostedemail.com (Postfix) with ESMTP id 48E84160854 for ; Wed, 26 Feb 2025 03:12:44 +0000 (UTC) X-FDA: 83160623448.13.3B03EC8 Received: from out-171.mta1.migadu.com (out-171.mta1.migadu.com [95.215.58.171]) by imf27.hostedemail.com (Postfix) with ESMTP id 7891F40005 for ; Wed, 26 Feb 2025 03:12:42 +0000 (UTC) Authentication-Results: imf27.hostedemail.com; dkim=pass header.d=linux.dev header.s=key1 header.b=FHe5iexk; spf=pass (imf27.hostedemail.com: domain of yosry.ahmed@linux.dev designates 95.215.58.171 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=1740539562; a=rsa-sha256; cv=none; b=WbqqMPRnwIShYrZMTSvIbPc8V2M+iahsAgpRLwNERXfX2pDG40bVltHj84UYwN9+LADE2I Rerhw24RRNMCOBUOm2gPOkSBC2l+GOFlLo+rFOQPQk3wA6s+3PmYUz/UkhED4Zt8DmSORW Zt3/Ljr7YhamLaU46lUsw7VG/nEjHn4= ARC-Authentication-Results: i=1; imf27.hostedemail.com; dkim=pass header.d=linux.dev header.s=key1 header.b=FHe5iexk; spf=pass (imf27.hostedemail.com: domain of yosry.ahmed@linux.dev designates 95.215.58.171 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=1740539562; 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=YyGSXmyx3vQfVQV+XxrCOZhSj5bg+cbgXTy3aGv8JuQ=; b=rCim8+NBXbxU0gn5BB7EqYFFpf9qDoCrqWj2m1eUv3Xhz0bsicOwqcQ+8FPXb2Pfwh21bQ ou+cIBRNo9Fi9OCLKamDi08rmrSDj5EvX4gpPdJqac6vkYjPInRNkDescQDuWhKY56m8Qb VBfzSQ2+Yo/U3M3walAooU1fiaA83nY= Date: Wed, 26 Feb 2025 03:12:35 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.dev; s=key1; t=1740539560; 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: in-reply-to:in-reply-to:references:references; bh=YyGSXmyx3vQfVQV+XxrCOZhSj5bg+cbgXTy3aGv8JuQ=; b=FHe5iexkbGjs6UK995iroW1QDoc6qK7wVPrGLM7k+MCKlvVg9x3d8nizxWgM0pdyA8IWcW UWJDKiLCVxs0eLOSUuffYLvt4Cao5+gxZBw1Xb+TD0phCXLdiZLNXtH6/tBdSNjFzxRsko pp26qJzkyBGe81WnHliSGtAeHlljNWI= 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=us-ascii Content-Disposition: inline In-Reply-To: <20250225213200.729056-1-nphamcs@gmail.com> X-Migadu-Flow: FLOW_OUT X-Rspamd-Queue-Id: 7891F40005 X-Stat-Signature: 9fzewa6k6qbssx88da8wqt4meb769mh8 X-Rspam-User: X-Rspamd-Server: rspam10 X-HE-Tag: 1740539562-451657 X-HE-Meta: U2FsdGVkX19Qs6sxWiGqm0lZwTU8LhIYBy0j9daM7Ne37BqfiONzG42N7Anig5+IsX9JI/JfojjhT/Us9Zb643EhFWrj1npIf4Tr/LXvcnUHakqJQVH6XfaX5Ij/pCBU8STxXLFUnK91jzMFXzwHpWBfiiAsuAqWnj96U0lKLsuxeeV3x9cBFvYOnt9oyViU/k9/fyEz2dCF72K7AUhuiNDLAryALB8opJHRJ0C5kToVMKbWhwRN8ZOQ/uYtSPbCz5TNZGE7FPIIDg0Cxiakb8sFsK+NEaSt1p6oXDRIoHlkwCMJRmFrbkIYw33+DRsDxRP9Dko9RdvmvQtpm6h+9Gj3X0SpDO37yDSvARI3xh9jswi00UWnQgMwkSxowAb59gQaW6+JPjL6GuFf0VKATi7nqVk5XlrhyPJG9KGfMKgng4bkmaapkByKHJxFKT9W6j8VWw2mJqNAOm2EyBm7Qk21DPrBdUDfaxCHfKAALY8WU1Butb6v97XgNi3sOqKkh8+XUO3GkC6dg/ivJPqeXfijyN+qfIvbXCh16U+TdZ65kiDCer0xX/Nh1zY67nsSpaSzq7HnO+GiRdqFpxcv0Xb54gdKzFSHSp02oOxgiJXF6JbWWzFEgBdcHT5Z50TInlEs1NHlFbYv67dQ30OKgtGx4tNg+7x6fOB7USOdyl5052c3hHh/5YQX+ypCgGTSh6qsMscUTwaGS/bVf2rU4KtuiWxsjevvq4btMGWmlyCC0nylUAIz/EiWmRu+7sDPsWq3r1MBJlWeyZLbc/zXYCbgwIjEh8hTRDQK80nqVFN2V8cqr7v+6Y9f2ROWxW9ymcZ+c3ru51dnM/Uno2TckbKC6/H+5g2AJGE95UqkLK9f+CauY32AqhvXTwYFPFUPO2ddFV2xxBQvcvgX7IzkeeIkMQ6QRcSIlpZbCoE0LeBpuH6hxgSfa9iWoQJuxTlcjR0hah+VS4T5i8rkuo2 jNeSVI5i 4Hvu+ZGFYCa4hlm7tXdUv8jZX4kiLRK2axZA5Hs54lKv8NXHE0VZmFpXDLDugMBWHUodkLKLpTufH5nQH8sMbL8dewzAuljIILfAl9fuuiPG8FVRiHlvjto7Zn28oPx6MFw7V+0Fn2B3BrmI8LSrnQh1k21WiYodvcgwPTCZsJx2UixmG9QRfrBn/Bo3eb40llbycwLtyqu4aoX7+E9CTfKo4Aw== X-Bogosity: Ham, tests=bogofilter, spamicity=0.000015, 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 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. (2) A hwpoisoned swap entry results in VM_FAULT_SIGBUS in some cases (e.g. shmem_fault() -> shmem_get_folio_gfp() -> shmem_swapin_folio()), even though we have VM_FAULT_HWPOISON. This patch falls under this bucket, but unfortunately we cannot tell for sure if it's a hwpoision or a decompression bug. (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.