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 EBB1B1A6826 for ; Wed, 18 Mar 2026 00:34:53 +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=1773794094; cv=none; b=eH9XAU+vrUA1Kplw4Rxl0Dl787DF8IgKf0Z2hrSRFvE9KpDSW/bCfr08K19xXMDI38xkLAkYuzZfhmalUzRdqgdUBgRv3m0p307Q6zVhfnB//2Qw844tNP3RgcQ7SY1BAcgPbwxdVXL/hEUIVm5N7/KCp4iz8wMOXYH9CoHljf8= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1773794094; c=relaxed/simple; bh=o+2EsIbr0oIAwZoKtQpYtJm5KnU4WKUHU9+5NFqAz5Y=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=ojXmOnTwHfbDzMZM2zmTzE7Z/6gvPX5pod5q4oHnJaLs3nq8eNRp5154pduqKUDAZYQsKCsZMJ2Y0e9XMwsT9n9ZSHFIZb6gfHOkn9xCENIscBpt+V0A9sFFM4WQ4fu9PSfwaLC3dk08lVNQUDp1Fjq96WwSX08eIM4ovDdrMf0= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=s+6zukas; 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="s+6zukas" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 7EA85C4CEF7; Wed, 18 Mar 2026 00:34:53 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1773794093; bh=o+2EsIbr0oIAwZoKtQpYtJm5KnU4WKUHU9+5NFqAz5Y=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=s+6zukasbBZhmH1EtCxMiJj6J53CY7qrVYduVrdi2hUhkqKjruyVm6bC6NvGRycXb MIKaa5JBTG+Ti1LDUtnW4YvmA6t2UT7N3PN/YgEZ0nyetyWGvRMJNXv/2818gI2x8v BBoLaZC8bTrWRk+dajPwhSnvUlkhjsapwqNQ6WMpTSjeaU2CYIhzYsKcNrcxEiZmXe SpB5CN92VNUYTGClNeAsPS1gakRj0311McyRjfFquu5uNHRcrk7MM9GsdvxVfDNMp6 x1rZD+emjyHY1i/iF3dD3tti65Zw+KDlJOM4/VL41vpQ00errtHlvUm43Wxz4iuAwn K72RcoN0FMBTg== From: SeongJae Park To: "Lorenzo Stoakes (Oracle)" Cc: SeongJae Park , Andrew Morton , Johannes Weiner , Yosry Ahmed , Nhat Pham , Chengming Zhou , linux-mm@kvack.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH mm-hotfixes] mm/zswap: add missing kunmap_local() Date: Tue, 17 Mar 2026 17:34:45 -0700 Message-ID: <20260318003446.132008-1-sj@kernel.org> X-Mailer: git-send-email 2.47.3 In-Reply-To: <13e09a99-181f-45ac-a18d-057faf94bccb@lucifer.local> References: Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit On Tue, 17 Mar 2026 12:59:35 +0000 "Lorenzo Stoakes (Oracle)" wrote: > Hi Andrew, > > Please apply the fix-patch enclosed to add a dcache flush which was also > missing here. > > I had assumed that a new folio here combined with the flush that is done at > the point of setting the PTE would suffice, but it doesn't seem that's > actually the case, as update_mmu_cache() will in many archtectures only > actually flush entries where a dcache flush was done on a range previously. > > I had also wondered whether kunmap_local() might suffice, but it doesn't > seem to be the case. > > Some arches do seem to actually dcache flush on unmap, parisc does it if > CONFIG_HIGHMEM is not set by setting ARCH_HAS_FLUSH_ON_KUNMAP and calling > kunmap_flush_on_unmap() from __kunmap_local(), otherwise non-CONFIG_HIGHMEM > callers do nothing here. > > Otherwise arch_kmap_local_pre_unmap() is called which does: > > * sparc - flush_cache_all() > * arm - if VIVT, __cpuc_flush_dcache_area() > * otherwise - nothing > > Also arch_kmap_local_post_unmap() is called which does: > > * arm - local_flush_tlb_kernel_page() > * csky - kmap_flush_tlb() > * microblaze, ppc - local_flush_tlb_page() > * mips - local_flush_tlb_one() > * sparc - flush_tlb_all() (again) > * x86 - arch_flush_lazy_mmu_mode() > * otherwise - nothing > > But this is only if it's high memory, and doesn't cover all architectures, > so is presumably intended to handle other cache consistency concerns. > > In any case, VIPT is problematic here whether low or high memory (in spite > of what the documentation claims, see [0] - 'the kernel did write to a page > that is in the page cache page and / or in high memory'), because dirty > cache lines may exist at the set indexed by the kernel direct mapping, > which won't exist in the set indexed by any subsequent userland mapping, > meaning userland might read stale data from L2 cache. > > Even if the documentation is correct and low memory is fine not to be > flushed here, we can't be sure as to whether the memory is low or high > (kmap_local_folio() will be a no-op if low), and this call should be > harmless if it is low. > > VIVT would require more work if the memory were shared and already mapped, > but this isn't the case here, and would anyway be handled by the dcache > flush call. > > In any case, we definitely need this flush as far as I can tell. Makes sense, thank you for detailed description! > > And we should probably consider updating the documentation unless it turns > out there's somehow dcache synchronisation that happens for low > memory/64-bit kernels elsewhere? > > Thanks, Lorenzo > > [0]:https://docs.kernel.org/core-api/cachetlb.html > > ----8<---- > From 94989ab3d97f0cde0dcf59eba6466fee932ec4ba Mon Sep 17 00:00:00 2001 > From: "Lorenzo Stoakes (Oracle)" > Date: Tue, 17 Mar 2026 12:29:55 +0000 > Subject: [PATCH] fix > > Signed-off-by: Lorenzo Stoakes (Oracle) Reviewed-by: SeongJae Park Thanks, SJ [...]