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 A1D8B3BD62C for ; Tue, 17 Mar 2026 12:14:09 +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=1773749649; cv=none; b=SYybxtcQQ5As1RV/bP+GttkSK1kx8SadBz37Z6ZK1jZMak7G7r6azTUSgVmnhiKVIlvg9FrK0pSn5SUEClrLK/rfkB+Rc7KlCkij/SO4kPU5gHpUpko5zg6yVnmNIZ6yEigXqv9mxkTXf1T+4i28n9TNC9/QY9Mo3qOGOl5OTGk= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1773749649; c=relaxed/simple; bh=h2yNj/JlK8uUWz6oueVZrppiSDLJqWd0uEjVTtCBuyY=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=dreYqzvfSrVVsPVszjCuG+QTf1sahIBYuXnZ0FniOGRL4xpM8Jn5vXNNPcGCVCse8e+tNMfPKEqPUwzW5wlxUY76pdCivibeQleYuQuGfOw+neriHKI1oBF7U+PHKST/3X54vj+MFqY4FQgJhR2XDpuJ2SfYC0HkrJggCKHYrD8= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=ows9e84F; 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="ows9e84F" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 213DAC19425; Tue, 17 Mar 2026 12:14:06 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1773749649; bh=h2yNj/JlK8uUWz6oueVZrppiSDLJqWd0uEjVTtCBuyY=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=ows9e84F4eolPF6a0yRJ+ZioFE3OdIGV4p+J5awFCnKRj03CyNoc3Wix4W1oioAV1 KByL/Fg9tQPh1ZWFCVDaxlCyK9TBDIwiKbYJ2MrphlT4seY33NXo0fDys6FIPxTAui 4VhYIIbPQgodQ9d22mzQtI3uz/IFAaiwAli+8oFtQdIgcJBgMZrPyJB3l06FH6w1iZ 8xBru0mGQwGukYjkrOCjb4McWDPbbXYY8JNGcmI0s5j9lnTKGYOhqom29VRQyJlZjO NDD5qPNMMi5yR3mBjdrRBpd9mvw/DfdVIwGmncQY2vnEaf6wndQ5V58hyLRLS8gH9q Q9RIEtdQgEi/A== Date: Tue, 17 Mar 2026 12:13:59 +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: <4587357e-e503-4a01-ae2c-df4ebd2c24a7@lucifer.local> 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=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: On Tue, Mar 17, 2026 at 10:01:19AM +0000, Lorenzo Stoakes (Oracle) wrote: > 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 ;) On second thoughts, I'm wrong, this is required. The documentation is really not clear on this, which is a problem given how horribly fiddly this is. https://docs.kernel.org/core-api/cachetlb.html it super vague on update_mmu_cache_range() - "At the end of every page fault, this routine is invoked to tell the architecture specific code that translations now exists in the software page tables for address space “vma->vm_mm” at virtual address “address” for “nr” consecutive pages." It doesn't mention that you really need to have invoked dcache flushes in advance for anything you changed, and that the architecture may then choose to not do anything at this point otherwise. Anyway, I'll send a fix-patch. Cheers, Lorenzo