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 mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id EEA67C433EF for ; Thu, 4 Nov 2021 16:54:33 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id D6D32611EE for ; Thu, 4 Nov 2021 16:54:33 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231867AbhKDQ5L (ORCPT ); Thu, 4 Nov 2021 12:57:11 -0400 Received: from mail.kernel.org ([198.145.29.99]:58888 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231543AbhKDQ5F (ORCPT ); Thu, 4 Nov 2021 12:57:05 -0400 Received: by mail.kernel.org (Postfix) with ESMTPSA id AA27461183; Thu, 4 Nov 2021 16:54:25 +0000 (UTC) Date: Thu, 4 Nov 2021 16:54:22 +0000 From: Catalin Marinas To: Linus Torvalds Cc: Matthew Wilcox , Christoph Hellwig , linux-arch , Ira Weiny , Andrew Morton , Linux Kernel Mailing List , Thomas Gleixner Subject: Re: flush_dcache_page vs kunmap_local Message-ID: References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Nov 04, 2021 at 08:30:55AM -0700, Linus Torvalds wrote: > On Thu, Nov 4, 2021 at 8:03 AM Matthew Wilcox wrote: > > Linus offers the opinion that kunmap calls should imply a > > flush_dcache_page(). Christoph added calls to flush_dcache_page() > > in commit 8dad53a11f8d. Was this "voodoo programming", or was there > > a real problem being addressed? > > I don't think anybody actually uses/cares about flush_dcache_page() at > all, and pretty much all uses are random and voodoo. We do. flush_dcache_page() is not just about virtual caches. On arm32/64 (and powerpc), even with PIPT-like caches, we use it to flag a page's D-cache as no longer clean. Subsequently in set_pte_at(), if the mapping is executable, we do the cache maintenance to ensure the I and D caches are coherent with each other. I wouldn't add this call to kmap/kunmap_local(), it would be a slight unnecessary overhead (we had a customer complaining about kmap_atomic() breaking write-streaming, I think the new kmap_local() solved this problem, if in the right context). -- Catalin