From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id AEB703A4F46 for ; Tue, 17 Mar 2026 10:01:21 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1773741681; cv=none; b=ZXib04FTbC+rN9OL9Qh2RstRfq/TWfMjMuMwJmWNOiishiDhr4/wR+HR86x1Av1am8OcwuY9WtcgJx176+i0+LmPjaArnBkpFy+g1OH+xKdzyg0XmRuP8+rRs1JgKohfEJv2wD/65S1cKITn010VXsy4C/al1srjEbgEwQFmkl4= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1773741681; c=relaxed/simple; bh=FRX7gMvgokkDLXWJAslMMqJm//JfKxgfgKg3VtyhJC4=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=pueOE3XRujudwkNsL0I86L09/w0QQTQiLyIR1NCAO5sPMGF4dTFaXX9rA0fx0f+l1NfAxl+5KRpGPB971zho6JTZS7xgFyJi3sSkq+BvAz1JAulqel4a+RE41AG1t/AOiJTjfCooPOPl7h0TuyJxC6tVkoEPt/PIKwgL+VQD7xQ= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=D1WMtBq7; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="D1WMtBq7" Received: by smtp.kernel.org (Postfix) with ESMTPSA id E566DC4CEF7; Tue, 17 Mar 2026 10:01:20 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1773741681; bh=FRX7gMvgokkDLXWJAslMMqJm//JfKxgfgKg3VtyhJC4=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=D1WMtBq7x7nk6P8850l+5YgDNwe/+2HGXRB90PKEnkf2ZdTrezqCoYAqT9/gFM5Cq 3QRPK844hptzPiNuibFBLXw+KJyva4jkXqf3GsBbCSlDtpGtmw69tw0Ot93rURVkDQ F1PjH2U6YFJJEujhgsgPLKYy1GQlkBBtHMjJZjEb5ljNGUNk6O/SGq8rruZN6Dp5QT soGamvWwyB7Cb/BFOlZz4DYFFx2HcgdE2T7KCJqMGFgvxVtb8TqjfdfazRuQa3jDsi B3NHJkUFcuITiDLY0gg5+r3xgbBmBAUcoMGY5XqLGc1DeRFOgeiGVZ9uQ8sfaCblhw islPFYdKcwEEQ== Date: Tue, 17 Mar 2026 10:01:19 +0000 From: "Lorenzo Stoakes (Oracle)" To: Andrew Morton Cc: Johannes Weiner , Yosry Ahmed , Nhat Pham , Chengming Zhou , linux-mm@kvack.org, linux-kernel@vger.kernel.org, Mateusz Guzik , Zi Yan Subject: Re: [PATCH mm-hotfixes] mm/zswap: add missing kunmap_local() Message-ID: References: <20260316140122.339697-1-ljs@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20260316140122.339697-1-ljs@kernel.org> On Mon, Mar 16, 2026 at 02:01:22PM +0000, Lorenzo Stoakes (Oracle) wrote: > Commit e2c3b6b21c77 ("mm: zswap: use SG list decompression APIs from > zsmalloc") updated zswap_decompress() to use the scatterwalk API to copy > data for uncompressed pages. > > In doing so, it mapped kernel memory locally for 32-bit kernels using > kmap_local_folio(), however it never unmapped this memory. > > This resulted in the linked syzbot report where a BUG_ON() is triggered due > to leaking the kmap slot. > > This patch fixes the issue by explicitly unmapping the established kmap. > > Reported-by: syzbot+fe426bef95363177631d@syzkaller.appspotmail.com > Closes: https://lore.kernel.org/all/69b75e2c.050a0220.12d28.015a.GAE@google.com > Fixes: e2c3b6b21c77 ("mm: zswap: use SG list decompression APIs from zsmalloc") > Signed-off-by: Lorenzo Stoakes (Oracle) > --- > mm/zswap.c | 7 ++++++- > 1 file changed, 6 insertions(+), 1 deletion(-) > > diff --git a/mm/zswap.c b/mm/zswap.c > index e6ec3295bdb0..499520f65ff0 100644 > --- a/mm/zswap.c > +++ b/mm/zswap.c > @@ -942,9 +942,14 @@ static bool zswap_decompress(struct zswap_entry *entry, struct folio *folio) > > /* zswap entries of length PAGE_SIZE are not compressed. */ > if (entry->length == PAGE_SIZE) { > + void *dst; > + > WARN_ON_ONCE(input->length != PAGE_SIZE); > - memcpy_from_sglist(kmap_local_folio(folio, 0), input, 0, PAGE_SIZE); > + > + dst = kmap_local_folio(folio, 0); > + memcpy_from_sglist(dst, input, 0, PAGE_SIZE); > dlen = PAGE_SIZE; > + kunmap_local(dst); FYI to address (in advance) the AI review from [0] which a couple people made me aware of - we don't need a flush_dcache_folio() here, because the folio is not yet accessible by userspace, so we can't have virtual aliasing of the folio's physical address on VIVT architectures. Examining call paths: zswap_writeback_entry() -> only calls zswap_decompress() if allocated -> zswap_decompress() swap_vma_readahead() -> only calls swap_read_folio() if allocated swap_cluster_readahead() -> only calls swap_read_folio() if allocated read_swap_cache_async() -> only calls swap_read_folio() if allocated do_swap_page() -> called in path where folio allocated shmem_swap_alloc_folio() -> as name implies, allocated folio -> swap_read_folio() -> zswap_load() -> zswap_decompress() So actually no longer doing this is a de-pessimisation ;) [0]:https://sashiko.dev/#/patchset/20260316140122.339697-1-ljs%40kernel.org > } else { > sg_init_table(&output, 1); > sg_set_folio(&output, folio, PAGE_SIZE, 0); > -- > 2.53.0 Cheers, Lorenzo