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 smtp3.osuosl.org (smtp3.osuosl.org [140.211.166.136]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id B45FBC433F5 for ; Fri, 25 Mar 2022 16:25:29 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp3.osuosl.org (Postfix) with ESMTP id 5C9EC60AE5; Fri, 25 Mar 2022 16:25:29 +0000 (UTC) X-Virus-Scanned: amavisd-new at osuosl.org Received: from smtp3.osuosl.org ([127.0.0.1]) by localhost (smtp3.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ik70relhvF5r; Fri, 25 Mar 2022 16:25:28 +0000 (UTC) Received: from lists.linuxfoundation.org (lf-lists.osuosl.org [140.211.9.56]) by smtp3.osuosl.org (Postfix) with ESMTPS id 4784460FFB; Fri, 25 Mar 2022 16:25:28 +0000 (UTC) Received: from lf-lists.osuosl.org (localhost [127.0.0.1]) by lists.linuxfoundation.org (Postfix) with ESMTP id 22F90C002C; Fri, 25 Mar 2022 16:25:28 +0000 (UTC) Received: from smtp2.osuosl.org (smtp2.osuosl.org [140.211.166.133]) by lists.linuxfoundation.org (Postfix) with ESMTP id 72834C0012 for ; Fri, 25 Mar 2022 16:25:27 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp2.osuosl.org (Postfix) with ESMTP id 518204027F for ; Fri, 25 Mar 2022 16:25:27 +0000 (UTC) X-Virus-Scanned: amavisd-new at osuosl.org Authentication-Results: smtp2.osuosl.org (amavisd-new); dkim=pass (2048-bit key) header.d=toke.dk Received: from smtp2.osuosl.org ([127.0.0.1]) by localhost (smtp2.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZEiPW-ahEWdW for ; Fri, 25 Mar 2022 16:25:25 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.8.0 Received: from mail.toke.dk (mail.toke.dk [45.145.95.4]) by smtp2.osuosl.org (Postfix) with ESMTPS id 9DE40401D5 for ; Fri, 25 Mar 2022 16:25:25 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=toke.dk; s=20161023; t=1648225521; bh=CQVTQ0YWUyVqJTQIKyyy3fv+ewiFx6OvdfGg4mW6pTQ=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=dY6s8FZcGbx4M3Ov5kHFWbz37pKFj65G1OC6fBB8z/tVV+am88ZfoF14ED65xxRfy fOLQlXZTlO9XnrrFbC9jdp9qP8CzWxIoIJ9tmfXHq2P/R5yHN396bTH6CKZYI5a8WW DD3bdPHqaN8gCGW78pwoabnJBY2snukIyApgMIoAqaA9Vdl2OUjDqBtuq40B49gIBc w+FVDx4iSZKjE/araq8XXw8Ex3/qMIjxUaNZ8Exy3fR+fRHCPfJikWMxuYW7fVYSRZ iv5BKTJDyv5nkS+fmdfKnF9fqjQ8Q5kgi4mjFJqFWUv15ynkDAsA+TI670+ZfI4GOK IWwWkpT3eVt0w== To: mbizon@freebox.fr, Linus Torvalds Subject: Re: [REGRESSION] Recent swiotlb DMA_FROM_DEVICE fixes break ath9k-based AP In-Reply-To: <31434708dcad126a8334c99ee056dcce93e507f1.camel@freebox.fr> References: <1812355.tdWV9SEqCh@natalenko.name> <20220324055732.GB12078@lst.de> <4386660.LvFx2qVVIh@natalenko.name> <81ffc753-72aa-6327-b87b-3f11915f2549@arm.com> <878rsza0ih.fsf@toke.dk> <4be26f5d8725cdb016c6fdd9d05cfeb69cdd9e09.camel@freebox.fr> <20220324163132.GB26098@lst.de> <871qyr9t4e.fsf@toke.dk> <31434708dcad126a8334c99ee056dcce93e507f1.camel@freebox.fr> Date: Fri, 25 Mar 2022 17:25:21 +0100 X-Clacks-Overhead: GNU Terry Pratchett Message-ID: <87a6de80em.fsf@toke.dk> MIME-Version: 1.0 Cc: Netdev , Kalle Valo , linux-wireless , Oleksandr Natalenko , stable , "David S. Miller" , Halil Pasic , iommu , Olha Cherevyk , Greg Kroah-Hartman , Jakub Kicinski , Paolo Abeni , Robin Murphy , Christoph Hellwig , Linux Kernel Mailing List X-BeenThere: iommu@lists.linux-foundation.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Development issues for Linux IOMMU support List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , From: Toke =?utf-8?Q?H=C3=B8iland-J=C3=B8rgensen?= via iommu Reply-To: Toke =?utf-8?Q?H=C3=B8iland-J=C3=B8rgensen?= Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: iommu-bounces@lists.linux-foundation.org Sender: "iommu" Maxime Bizon writes: > On Thu, 2022-03-24 at 12:26 -0700, Linus Torvalds wrote: > >> >> It's actually very natural in that situation to flush the caches from >> the CPU side again. And so dma_sync_single_for_device() is a fairly >> reasonable thing to do in that situation. >> > > In the non-cache-coherent scenario, and assuming dma_map() did an > initial cache invalidation, you can write this: > > rx_buffer_complete_1(buf) > { > invalidate_cache(buf, size) > if (!is_ready(buf)) > return; > > } > > or > > rx_buffer_complete_2(buf) > { > if (!is_ready(buf)) { > invalidate_cache(buf, size) > return; > } > > } > > The latter is preferred for performance because dma_map() did the > initial invalidate. > > Of course you could write: > > rx_buffer_complete_3(buf) > { > invalidate_cache(buf, size) > if > (!is_ready(buf)) { > invalidate_cache(buf, size) > return; > } > > > } > > > but it's a waste of CPU cycles > > So I'd be very cautious assuming sync_for_cpu() and sync_for_device() > are both doing invalidation in existing implementation of arch DMA ops, > implementers may have taken some liberty around DMA-API to avoid > unnecessary cache operation (not to blame them). I sense an implicit "and the driver can't (or shouldn't) influence this" here, right? > For example looking at arch/arm/mm/dma-mapping.c, for DMA_FROM_DEVICE > > sync_single_for_device() > => __dma_page_cpu_to_dev() > => dma_cache_maint_page(op=dmac_map_area) > => cpu_cache.dma_map_area() > > sync_single_for_cpu() > => __dma_page_dev_to_cpu() > => > __dma_page_cpu_to_dev(op=dmac_unmap_area) > => > cpu_cache.dma_unmap_area() > > dma_map_area() always does cache invalidate. > > But for a couple of CPU variant, dma_unmap_area() is a noop, so > sync_for_cpu() does nothing. > > Toke's patch will break ath9k on those platforms (mostly silent > breakage, rx corruption leading to bad performance) Okay, so that would be bad obviously. So if I'm reading you correctly (cf my question above), we can't fix this properly from the driver side, and we should go with the partial SWIOTLB revert instead? -Toke _______________________________________________ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu