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 C38F5C021B8 for ; Wed, 26 Feb 2025 23:29:22 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 5AFA76B0082; Wed, 26 Feb 2025 18:29:22 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 55B896B008A; Wed, 26 Feb 2025 18:29:22 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 422526B008C; Wed, 26 Feb 2025 18:29:22 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0014.hostedemail.com [216.40.44.14]) by kanga.kvack.org (Postfix) with ESMTP id 2694D6B0082 for ; Wed, 26 Feb 2025 18:29:22 -0500 (EST) Received: from smtpin21.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay04.hostedemail.com (Postfix) with ESMTP id A51EE1A105D for ; Wed, 26 Feb 2025 23:29:20 +0000 (UTC) X-FDA: 83163689280.21.4FEC261 Received: from mail-qk1-f174.google.com (mail-qk1-f174.google.com [209.85.222.174]) by imf04.hostedemail.com (Postfix) with ESMTP id 9999840006 for ; Wed, 26 Feb 2025 23:29:18 +0000 (UTC) Authentication-Results: imf04.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=kWAjk2Or; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf04.hostedemail.com: domain of nphamcs@gmail.com designates 209.85.222.174 as permitted sender) smtp.mailfrom=nphamcs@gmail.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1740612558; a=rsa-sha256; cv=none; b=viUzinCZxpw+YY2RPsm9ejt7p1TfMGP7la3nJUbbdbZZTNJd6L5t/KpUZFbqOLCrGV/USU 9/DNGUr/WmxXI3WhKIywp2Lj+KOZaVv1fFzdQgxGhR6weX0GzUXu5ESsn0CvOQ6gFi7930 AtPUGecnxL1R03+qbpBe9Lgskvk6Uwk= ARC-Authentication-Results: i=1; imf04.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=kWAjk2Or; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf04.hostedemail.com: domain of nphamcs@gmail.com designates 209.85.222.174 as permitted sender) smtp.mailfrom=nphamcs@gmail.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1740612558; 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=J/dQk4SZYN5ePkzsS3cMgdnGZmrR3Q/tY6oGbPoub5w=; b=k83GiNMVUIVQvgnLJtZff/HOP2FGj3SFTxz5IaXdTa6bINW3LwqWLxDueqpojpCKJuiiGJ /xow3dyiG8s2ty78nVbHFhfo5fGuG+26XJPxmCDXsAis6xg5mQAovA8FkFjgkUYozweFHz 59Bze83bzoPlrP9/1okt9z2oteUPb8E= Received: by mail-qk1-f174.google.com with SMTP id af79cd13be357-7c08f9d0ef3so19750585a.2 for ; Wed, 26 Feb 2025 15:29:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1740612557; x=1741217357; 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=J/dQk4SZYN5ePkzsS3cMgdnGZmrR3Q/tY6oGbPoub5w=; b=kWAjk2Or3awTRYQAdBGKdeSOVKutD+QVPfG20hS6tFeUC6XBPephLyuC+TYyoWmt1Z lA+VEA5veQyhcw/FIcseSnkt58xrOq410ke9jWfEtDFNlvPUGkdcZ1HBKgHEAYr6IzOL rHIJXfb65bgelH19CRhYcQtdmrCh9M7CgSDwcze0/0SgiqBAEM9PWj+Vk2DY6DYzrZNo O393XgTVY6uG+LX0zgxqkZYt97cxp/H82cQdGaFRaZ5K918NAJIVkouXy8j0zkDxFPin j9UJWQClSYNPrxbqJxrX5f4+pV1uQOp/dkod6GtGNUXlRgxieimPZitZv/7nlrlrYB7N NHcg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1740612557; x=1741217357; 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=J/dQk4SZYN5ePkzsS3cMgdnGZmrR3Q/tY6oGbPoub5w=; b=gDndmqsX1IUaMI7Uh7UcNgOXHSv8NGVzrF3eEfzWxhBHRcby2p+nQTcPmvXknnUdMI lbvS3qBWYMvobZLQ33Dy7g3xAAJRgmATYcM3CB9iH6KN9FJFOvMUz8bZ7GQK6344fPAs cZ+prGoH/UpAjw3+1+jZMw4PXUYi1Ont8iwoc8oNYF8WbL31w5Oh5D4sWCqEV/oh9UXd Y4msQdDbAAs+u/mjuL39sCjlz8sRKYvy/+/lFOzkq/X/kyNknJIx33to5+tfybjpUwQD FIca6Hwga1eaJkUI1OLqnvL+0KSgLy0THWF8Z5OKG1kaHSn00cPZrs1CvVl4XCi1IOiT 9pmg== X-Forwarded-Encrypted: i=1; AJvYcCWocsKb9NOSn9PkuOl4llG3D8hps7Sx8q+wc3aaL1lWNPpphLW93QnhBdVwryw27qO+ARtKcHTBaw==@kvack.org X-Gm-Message-State: AOJu0YwPABi3gZNDNPRDnQrEwr6FoNkO+YmrCaAB4xFaqLNyL8RqH9dl HBE79diOlMQCaqpbXDt4FYzD1ubPyGlYRRp5vfAZnFCQdnyBNJ1scowADiBOI3arPlvKhfmmAk7 a3rWh3xrCTl2z+8CELZIi3PxcUUg= X-Gm-Gg: ASbGncvkGxEqJlJEP1jEvWAPSMpTP1CTBSV5Gbh/XkjBEMGBbRrh3larJJ9W44ywnO6 2R0Fwa8SMATyMb12FPsm3lzxjWGOR8pkgA94d6GwR7uRCTAHlCVZIu+gUu/aTSnQ1IyObc66MIH 6idTaLw9Vry5OrfvVS4cNjrjU= X-Google-Smtp-Source: AGHT+IEK2N3gE/8VfY/AR0Y6ytUjwbGPgl9rer6rSlGeqvaTDUu0JLII+3SkCTDMI092dXsoJ6jINsLMcK/3wYhwkCk= X-Received: by 2002:a05:6214:c88:b0:6e1:5076:c400 with SMTP id 6a1803df08f44-6e886902ec2mr59807596d6.39.1740612557602; Wed, 26 Feb 2025 15:29:17 -0800 (PST) MIME-Version: 1.0 References: <20250225213200.729056-1-nphamcs@gmail.com> In-Reply-To: From: Nhat Pham Date: Wed, 26 Feb 2025 15:29:06 -0800 X-Gm-Features: AQ5f1Jo8WiMfrrcbDj1XSStbJugMrvbOacaXonziWyPRA4RnosYcazj9rzgd2kU Message-ID: Subject: Re: [PATCH] zswap: do not crash the kernel on decompression failure To: Yosry Ahmed 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 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Server: rspam02 X-Rspamd-Queue-Id: 9999840006 X-Stat-Signature: ej3cg7sf9e6cd6311ozmgg45bx5rgdbi X-Rspam-User: X-HE-Tag: 1740612558-903719 X-HE-Meta: U2FsdGVkX1+Htoxqg3c37voWgjkxk22cCxaPDQOnVcJNV5Q53rVDPQJkwC6rxXg5P2yuDtW6d4Gcaakv92egi+xmx22nZre5rbnIZnGOwTN12mZvf0SM2ija7d3nauXtHjcCFTJWt3D6MQ60rwNl+nDvoWeraM1rf0BtYtv71PtqshYnXnY3pdnIUCLJXU4xG83vWbog1butbEW+6oVQazkW5dOP+mjTW0JM1M3mS5/3trT1sbYPtwWXSllwmpedYJ86C/869hNaZPOdp/8OqwsuKIPY670qJ7bVt0iMnWdggEumJERnQ75Jc3aNKCd/+8pQ5rqGNQ5BjEtWVZ1X3A/mqgjUMHJ2C+KT3KWFO8czTwBVKOYXrB0ayY626/lzlsbXdUsvFHBgwQ2v8U7jMyBmD08qhAWcBoMShwCi+hoJKk5vIwaVwmU8DjSy6r5h49ByoFx62Rr2wJgk0StwMktZ0nxSYdWmp5EoX51+Y1ARfoa3m/QY/TDWx6Mlz1AlTr8+YbotjQuD4NGBkdz+5RHkdfkqX2fwG5lUlKuSRzgxMmqMu+YBPQLdIzinc7REGq4iGXrpAjgakQX4uTWAKKmMlv4O1nYijGOu42ZnuPo9yoWRib9CPTxraZZOqcXrC2rQnswMW9jnGOreZhkStiE5jPgVPY7lKCgwPJI5XQxPQ8qcPtTcb4f3rz6Bf7/0QvLNX+r4GEoDNDYYAGR2rNHGK2Xxggapjui/Hfm8UYUVXwllJUfp822nFgB2+OsJAmBaL0569JKrwrNepeKYldXt11ZWuNk1Rv0k0Mv3P/uuKh5GqwDZXGAtxJY5FTuLCmSO+Qbs5U/mQyLFlyLfxX/xSItwfJm7KrysZaCAuepJpqbQl33susOzWlhPajRM0LDcmWAwE6vesn+l13gJe3ncd7PiT8/nBhzDFcKu1HckFB22C0C1pxeMlnVDcsfBj4kLjAfHnlHjg8rO8xc 5Mrrt7MD nXUTvERi+bOwKpi2fp2IxtKR917Hjg2zw0/Sr8+JEV4RK2IVFbIx3xbHa+SW3Vwrr+Gz1i5TOJmF5+N6c8Rp0XoBg830CE9FjI4n+rHs8REwyNeR4EMsTPjbjU+3Ln49co2Znh8C6XxSGIXiV+npKCnuFXPOoXYs9wab+uqzPbdPTdA7+bMOIL+Ol+9IyA+ckwdfI5TTW9Q75Z0724x0HMuf0yt1x1aOULKo5kLQaWXxb2bg6Lc0pUlMcRwYMIX11KxqLNW1UD01WQNCcG/AdWmOYCF5OcurYVEI3/wecNPHeBzVRUidn7C3laiMc54nt2T6+ X-Bogosity: Ham, tests=bogofilter, spamicity=0.185496, 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 7:12=E2=80=AFPM 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 corrupte= d > > 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. [...] > > > (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