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 25840C433EF for ; Fri, 25 Mar 2022 22:41:12 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp3.osuosl.org (Postfix) with ESMTP id B089260B64; Fri, 25 Mar 2022 22:41:11 +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 gFQw354BYmXR; Fri, 25 Mar 2022 22:41:10 +0000 (UTC) Received: from lists.linuxfoundation.org (lf-lists.osuosl.org [IPv6:2605:bc80:3010:104::8cd3:938]) by smtp3.osuosl.org (Postfix) with ESMTPS id 623BB60A89; Fri, 25 Mar 2022 22:41:10 +0000 (UTC) Received: from lf-lists.osuosl.org (localhost [127.0.0.1]) by lists.linuxfoundation.org (Postfix) with ESMTP id 1D87CC002C; Fri, 25 Mar 2022 22:41:10 +0000 (UTC) Received: from smtp4.osuosl.org (smtp4.osuosl.org [140.211.166.137]) by lists.linuxfoundation.org (Postfix) with ESMTP id 1290AC0012 for ; Fri, 25 Mar 2022 22:41:09 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp4.osuosl.org (Postfix) with ESMTP id 0E5C94059D for ; Fri, 25 Mar 2022 22:41:09 +0000 (UTC) X-Virus-Scanned: amavisd-new at osuosl.org Received: from smtp4.osuosl.org ([127.0.0.1]) by localhost (smtp4.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5elcq_FVqj5g for ; Fri, 25 Mar 2022 22:41:07 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.8.0 Received: from eu-smtp-delivery-151.mimecast.com (eu-smtp-delivery-151.mimecast.com [185.58.85.151]) by smtp4.osuosl.org (Postfix) with ESMTPS id 763F44050F for ; Fri, 25 Mar 2022 22:41:07 +0000 (UTC) Received: from AcuMS.aculab.com (156.67.243.121 [156.67.243.121]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id uk-mta-132-bzPiuRSPOXqPuBduQ2feJg-1; Fri, 25 Mar 2022 22:41:04 +0000 X-MC-Unique: bzPiuRSPOXqPuBduQ2feJg-1 Received: from AcuMS.Aculab.com (fd9f:af1c:a25b:0:994c:f5c2:35d6:9b65) by AcuMS.aculab.com (fd9f:af1c:a25b:0:994c:f5c2:35d6:9b65) with Microsoft SMTP Server (TLS) id 15.0.1497.32; Fri, 25 Mar 2022 22:41:02 +0000 Received: from AcuMS.Aculab.com ([fe80::994c:f5c2:35d6:9b65]) by AcuMS.aculab.com ([fe80::994c:f5c2:35d6:9b65%12]) with mapi id 15.00.1497.033; Fri, 25 Mar 2022 22:41:01 +0000 From: David Laight To: 'Linus Torvalds' , Johannes Berg Subject: RE: [REGRESSION] Recent swiotlb DMA_FROM_DEVICE fixes break ath9k-based AP Thread-Topic: [REGRESSION] Recent swiotlb DMA_FROM_DEVICE fixes break ath9k-based AP Thread-Index: AQHYQJM6K/9JYQDqEEKfLChLw6SC36zQrLFA Date: Fri, 25 Mar 2022 22:41:01 +0000 Message-ID: <273dec6267b249ca941558c268390fbc@AcuMS.aculab.com> 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> <298f4f9ccad7c3308d3a1fd8b4b4740571305204.camel@sipsolutions.net> In-Reply-To: Accept-Language: en-GB, en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.202.205.107] MIME-Version: 1.0 Authentication-Results: relay.mimecast.com; auth=pass smtp.auth=C51A453 smtp.mailfrom=david.laight@aculab.com X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: aculab.com Content-Language: en-US Cc: =?utf-8?B?VG9rZSBIw7hpbGFuZC1Kw7hyZ2Vuc2Vu?= , Greg Kroah-Hartman , Netdev , Kalle Valo , linux-wireless , Oleksandr Natalenko , stable , "David S. Miller" , Halil Pasic , iommu , Olha Cherevyk , Jakub Kicinski , Maxime Bizon , 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: iommu-bounces@lists.linux-foundation.org Sender: "iommu" From: Linus Torvalds > Sent: 25 March 2022 21:57 > > On Fri, Mar 25, 2022 at 2:13 PM Johannes Berg wrote: > > > > Well I see now that you said 'cache "writeback"' in (1), and 'flush' in > > (2), so perhaps you were thinking of the same, and I'm just calling it > > "flush" and "invalidate" respectively? > > Yeah, so I mentally tend to think of the operations as just > "writeback" (which doesn't invalidate) and "flush" (which is a > writeback-invalidate). It almost certainly doesn't matter whether the "writeback" invalidates or not. You have to assume that all sorts of operations might cause the cpu to read in a cacheline. This includes, but is not limited to, speculative execution and cache line prefetch. But you definitely need an "invalidate" to force a cache line be read after the hardware has accessed it. Now such lines must not be dirty; because the cpu can write back a dirty cache line at any time - which would break things. So this can also be "write back if dirty" and "invalidate". Bounce buffers and cache probably work much the same way. But for bounce buffers I guess you want to ensure the initially allocated buffer doesn't contain old data (belonging to someone else). So you might decide to zero them on allocation or always copy from the driver buffer on the first request. Then you get the really annoying cpu that don't have a "write back dirty line and invalidate" opcode. And the only way is to read enough other memory areas to displace all the existing cache line data. You probably might as well give up and use PIO :-) David - Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK Registration No: 1397386 (Wales) _______________________________________________ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu