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 00C42C197BF for ; Thu, 27 Feb 2025 21:55:24 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 88BB9280001; Thu, 27 Feb 2025 16:55:24 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 83B696B0089; Thu, 27 Feb 2025 16:55:24 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 7029F280001; Thu, 27 Feb 2025 16:55:24 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0017.hostedemail.com [216.40.44.17]) by kanga.kvack.org (Postfix) with ESMTP id 51A926B0083 for ; Thu, 27 Feb 2025 16:55:24 -0500 (EST) Received: from smtpin27.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay08.hostedemail.com (Postfix) with ESMTP id CF4F0141DB2 for ; Thu, 27 Feb 2025 21:55:23 +0000 (UTC) X-FDA: 83167081326.27.8DBDA8E Received: from out-183.mta0.migadu.com (out-183.mta0.migadu.com [91.218.175.183]) by imf08.hostedemail.com (Postfix) with ESMTP id 08CC1160016 for ; Thu, 27 Feb 2025 21:55:21 +0000 (UTC) Authentication-Results: imf08.hostedemail.com; dkim=pass header.d=linux.dev header.s=key1 header.b=b8SRXH8Z; dmarc=pass (policy=none) header.from=linux.dev; spf=pass (imf08.hostedemail.com: domain of yosry.ahmed@linux.dev designates 91.218.175.183 as permitted sender) smtp.mailfrom=yosry.ahmed@linux.dev ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1740693322; 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=TFg2zuo548IMIIuv4McDGaoyHDjLrtngqpZZrXkgG2E=; b=u28mFssIqHi8sK+AO6cMxyu7qHt/93ugnX3tspWmQHG1GTNn8mXSzBsnPAn8onkOgI9Ty/ Bye6Vr9nSehhjbsGwvYU2460/MS6uyDQLCordobtnYQcGg0B0XcjR3jcBeRD2n4TWv8UG5 z8P7iSQcVBeQV7+e5K6OEdszn/sNH7A= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1740693322; a=rsa-sha256; cv=none; b=HC7roywCjhm/cY7KCGVt2whaURc+4NIwDC2YU1R1rsHkuwzJE80qe2T6qkkeM7LXujIRd5 Cqqt1Fa5RvyVZ98fTOR+4dGns7nbmlCvyMEoqyKzQCoJbiSJTJ9j9aVX0weZGH318KBzxj PHRvVAhRSoFSid2MKVdlqtrZwZQ3Jr8= ARC-Authentication-Results: i=1; imf08.hostedemail.com; dkim=pass header.d=linux.dev header.s=key1 header.b=b8SRXH8Z; dmarc=pass (policy=none) header.from=linux.dev; spf=pass (imf08.hostedemail.com: domain of yosry.ahmed@linux.dev designates 91.218.175.183 as permitted sender) smtp.mailfrom=yosry.ahmed@linux.dev Date: Thu, 27 Feb 2025 21:55:13 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.dev; s=key1; t=1740693318; 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=TFg2zuo548IMIIuv4McDGaoyHDjLrtngqpZZrXkgG2E=; b=b8SRXH8ZJOO3+adX0eOnYQGQkjoTal1FzaV2cTTaiSoKv62CyhPBwh+b7or0o2PFDYFsDf wkEdd2bhKp4lmV9BCBS9d1lPNiCoUbMFhI2xtxyyK3roOrp6Ejo6qCn6M/dXSPO+NfBlSF OuI9lGR1CgXmtof5HDPTTkgN52mCY4M= 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 v2] zswap: do not crash the kernel on decompression failure Message-ID: References: <20250227001445.1099203-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: rspam12 X-Rspamd-Queue-Id: 08CC1160016 X-Stat-Signature: siryn1sfr7jtroow7w8o1swqxj968bme X-HE-Tag: 1740693321-680507 X-HE-Meta: U2FsdGVkX1+DhNqE9dFsncd+nEwJn/u5ENuAiOofyMF+9S1W8MJ2JIiv9NEbUxRn6rQKIeCDnzMeIuGHk1W5HKe4mJ5x1HHrKrNF6+MIG7p1r7GXH7FG59PfamxZMsD+M/fzUH/nOSzWR/g9m3sDnk3RSLWyyCvnSpFyA6CLTPP5qufsKFXmJ519KPq1V7vNeuOpjvdS60weO1qTuH2+aWKDf1hoHtHHTkUSOftO40IiwgIV5xq9stjLET1EZTU8hUwfEwc5PN2ysNyI6ttRj0n2KiY+XdeZWdmXhvai/aO51D5gppQzKKgPgLbiwN3kS7zSCie/XUVQbPRPiecDSdJVATfXRqHSAvjs8cfQd51agP+vczfX8Gv7iF9OdFCxae8HHa230tj4Y0+SNm9BkbXBqga33q8OVFDuyp0J74sAZdmylkj0zYh2/d6nFOj13rC54cG/C9tqFJPn0OEz7/v+WDXs830otqyiqJ/c2U78QpS/l0xJqBoLWjqfqrDPu3MUyu4NaaRjzk4dP7UiJeE2Q5EKg5bOzhySaI51XX2xpw77McsHQGeevkAtx49N4eJX5u+PK5PLlIM/Bto2hnYOlX+mQeoj9WgDZ95F+3Y3/VXNokQs3MstlqbD1ytLyH6b2QpucbhgJToe4a0YOlN38EpW///sb0Kmt6/ZV8D+LShcVjzBw8agDMLP0Ck0UqDYR2Dyoe/nfcHbs+Al4C35mjvQ6ESIY+n50NGHUSvGw32eTvxT8bO9hlhqcgsAbAqQ0IG3FtGuorYp0qkbIQ+hNew1ffYj5gLrxVKrlw9/WE2eBs9hfN6p/f7w3awUJCydePPzZoTTb7tcR+aoeOoGaS1yQE3iaaWA4SqKf6LpFKjwkjSQ3NGQnEMnxyP1NmTj6wSS3esx12WxPXp6aZJbnypdjdAz+qZ5XTiK/kqVS1tOEa+xPy4C0IPjECPRBJS0A533o7eD25bZY// IvpTgLMR wlnzCgc7bWeH/KUmRJGaNUppQ/0Dhmhdx9QKV30NnLucdU8gTIO+2p2TlJy7HZ42vjGXojQXbSFf90Zc/lA5Y4azanaNnGgCyPc9f+uACvSwl1mpQHsz1h5c0c1lHHQREQ1I04k95ogU40bstMaSBfctVNva7LGcx9zlnuwLeDMd+ZX71RCmP16PjSltbLOOTt/BhuDijjye202RnVBA5L8lVi2mE377/Ay5H4VKJ/JHZT3Btd4yUrx7w8BYt8fgMsZUbZ+BWx9sRD5UZP/bFqCRsqf3cbi44d1ag4dP4YE5kImQvpV9xc5CptzahJdGBSQyNWq98lo5iX3o= 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 Thu, Feb 27, 2025 at 01:46:29PM -0800, Nhat Pham wrote: > On Wed, Feb 26, 2025 at 5:19 PM Yosry Ahmed wrote: > > > > On Wed, Feb 26, 2025 at 04:14:45PM -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. The former is accomplished by returning true > > > from zswap_load(), indicating that zswap owns the swapped out content, > > > but without flagging the folio as up-to-date. The process trying to swap > > > in the page will check for the uptodate folio flag and SIGBUS (see > > > do_swap_page() in mm/memory.c for more details). > > > > We should call out the extra xarray walks and their perf impact (if > > any). > > Lemme throw this in a quick and dirty test. I doubt there's any > impact, but since I'm reworking this patch for a third version anyway > might as well. It's likely everything is cache hot and the impact is minimal, but let's do the due diligence. > > > > > > > > > See [1] for a recent upstream discussion about this. > > > > > > [1]: https://lore.kernel.org/all/ZsiLElTykamcYZ6J@casper.infradead.org/ > > > > > > Suggested-by: Matthew Wilcox > > > Suggested-by: Yosry Ahmed > > > Signed-off-by: Nhat Pham > > > --- > > > mm/zswap.c | 94 ++++++++++++++++++++++++++++++++++++++---------------- > > > 1 file changed, 67 insertions(+), 27 deletions(-) > > > > > > diff --git a/mm/zswap.c b/mm/zswap.c > > > index 6dbf31bd2218..e4a2157bbc64 100644 > > > --- a/mm/zswap.c > > > +++ b/mm/zswap.c > > > @@ -62,6 +62,8 @@ static u64 zswap_reject_reclaim_fail; > > > static u64 zswap_reject_compress_fail; > > > /* Compressed page was too big for the allocator to (optimally) store */ > > > static u64 zswap_reject_compress_poor; > > > +/* Load or writeback failed due to decompression failure */ > > > +static u64 zswap_decompress_fail; > > > /* Store failed because underlying allocator could not get memory */ > > > static u64 zswap_reject_alloc_fail; > > > /* Store failed because the entry metadata could not be allocated (rare) */ > > > @@ -996,11 +998,13 @@ static bool zswap_compress(struct page *page, struct zswap_entry *entry, > > > return comp_ret == 0 && alloc_ret == 0; > > > } > > > > > > -static void zswap_decompress(struct zswap_entry *entry, struct folio *folio) > > > +static bool zswap_decompress(struct zswap_entry *entry, struct folio *folio) > > > { > > > struct zpool *zpool = entry->pool->zpool; > > > struct scatterlist input, output; > > > struct crypto_acomp_ctx *acomp_ctx; > > > + int decomp_ret; > > > + bool ret = true; > > > u8 *src; > > > > > > acomp_ctx = acomp_ctx_get_cpu_lock(entry->pool); > > > @@ -1025,12 +1029,25 @@ static void zswap_decompress(struct zswap_entry *entry, struct folio *folio) > > > sg_init_table(&output, 1); > > > sg_set_folio(&output, folio, PAGE_SIZE, 0); > > > acomp_request_set_params(acomp_ctx->req, &input, &output, entry->length, PAGE_SIZE); > > > - BUG_ON(crypto_wait_req(crypto_acomp_decompress(acomp_ctx->req), &acomp_ctx->wait)); > > > - BUG_ON(acomp_ctx->req->dlen != PAGE_SIZE); > > > + decomp_ret = crypto_wait_req(crypto_acomp_decompress(acomp_ctx->req), &acomp_ctx->wait); > > > + if (decomp_ret || acomp_ctx->req->dlen != PAGE_SIZE) { > > > + ret = false; > > > + zswap_decompress_fail++; > > > + pr_alert_ratelimited( > > > + "decompression failed with returned value %d on zswap entry with swap entry value %08lx, swap type %d, and swap offset %lu. compression algorithm is %s. compressed size is %u bytes, and decompressed size is %u bytes.\n", > > > > This is a very long line. I think we should break it into multiple > > lines. I know multiline strings are frowned upon by checkpatch, by this > > exist (see the warning in mem_cgroup_oom_control_write() for example), > > and they are definitely better than a very long line imo. > > My personal take is I prefer multi line strings, but was not sure what > is the "preferred" or "official" style. Oh well. > > > > > > + decomp_ret, > > > + entry->swpentry.val, > > > + swp_type(entry->swpentry), > > > + swp_offset(entry->swpentry), > > > + entry->pool->tfm_name, > > > + entry->length, > > > + acomp_ctx->req->dlen); > > > + } > > > > > > if (src != acomp_ctx->buffer) > > > zpool_unmap_handle(zpool, entry->handle); > > > acomp_ctx_put_unlock(acomp_ctx); > > > + return ret; > > > > Not a big deal but we could probably store the length in a local > > variable and move the check here, and avoid needing 'ret'. > > Ah the suggestion you made in an older version right? But sounds like > we're just trading some one local variable for another? > > That said, it *technically* move some work outside of the lock > section. I'll just give it a try :) My goal is not really to get rid of the local variable, but rather to obviously return 'true' or 'false' directly rather than a 'ret' value. > > > > > > } > > > > > > /********************************* > > > @@ -1060,6 +1077,7 @@ static int zswap_writeback_entry(struct zswap_entry *entry, > > > struct writeback_control wbc = { > > > .sync_mode = WB_SYNC_NONE, > > > }; > > > + int ret = 0; > > > > > > /* try to allocate swap cache folio */ > > > si = get_swap_device(swpentry); > > > @@ -1081,8 +1099,8 @@ static int zswap_writeback_entry(struct zswap_entry *entry, > > > * and freed when invalidated by the concurrent shrinker anyway. > > > */ > > > if (!folio_was_allocated) { > > > - folio_put(folio); > > > - return -EEXIST; > > > + ret = -EEXIST; > > > + goto put_folio; > > > } > > > > > > /* > > > @@ -1095,14 +1113,17 @@ static int zswap_writeback_entry(struct zswap_entry *entry, > > > * be dereferenced. > > > */ > > > tree = swap_zswap_tree(swpentry); > > > - if (entry != xa_cmpxchg(tree, offset, entry, NULL, GFP_KERNEL)) { > > > - delete_from_swap_cache(folio); > > > - folio_unlock(folio); > > > - folio_put(folio); > > > - return -ENOMEM; > > > + if (entry != xa_load(tree, offset)) { > > > + ret = -ENOMEM; > > > + goto delete_unlock; > > > + } > > > + > > > + if (!zswap_decompress(entry, folio)) { > > > + ret = -EIO; > > > + goto delete_unlock; > > > } > > > > > > - zswap_decompress(entry, folio); > > > + xa_erase(tree, offset); > > > > > > count_vm_event(ZSWPWB); > > > if (entry->objcg) > > > @@ -1118,9 +1139,14 @@ static int zswap_writeback_entry(struct zswap_entry *entry, > > > > > > /* start writeback */ > > > __swap_writepage(folio, &wbc); > > > - folio_put(folio); > > > > > > - return 0; > > > +put_folio: > > > + folio_put(folio); > > > + return ret; > > > +delete_unlock: > > > + delete_from_swap_cache(folio); > > > + folio_unlock(folio); > > > + goto put_folio; > > > > I think I suggested a way to avoid this goto in v1: > > https://lore.kernel.org/lkml/Z782SPcJI8DFISRa@google.com/. > > > > Did this not work out? > > Oh I thought your suggestion was the same as Johannes. Let me take a > closer look... > > > > > > } > > > > > > /********************************* > > > @@ -1620,6 +1646,20 @@ bool zswap_store(struct folio *folio) > > > return ret; > > > } > > > > > > +/** > > > + * zswap_load() - load a page from zswap > > > + * @folio: folio to load > > > + * > > > + * Returns: true if zswap owns the swapped out contents, false otherwise. > > > + * > > > + * Note that the zswap_load() return value doesn't indicate success or failure, > > > + * but whether zswap owns the swapped out contents. This MUST return true if > > > + * zswap does own the swapped out contents, even if it fails to write the > > > + * contents to the folio. Otherwise, the caller will try to read garbage from > > > + * the backend. > > > + * > > > + * Success is signaled by marking the folio uptodate. > > > + */ > > > bool zswap_load(struct folio *folio) > > > { > > > swp_entry_t swp = folio->swap; > > > @@ -1644,6 +1684,17 @@ bool zswap_load(struct folio *folio) > > > > The comment that exists here (not visible in the diff) should be > > abbreviated now that we already explained the whole uptodate thing > > above, right? > > Lemme take a stab at it :) Take a look at the other thread between Johannes and I first. We discussed more involved changes around this.