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 vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 51FA0C433EF for ; Sun, 27 Mar 2022 20:05:27 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S236618AbiC0UHE (ORCPT ); Sun, 27 Mar 2022 16:07:04 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:56810 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232186AbiC0UG6 (ORCPT ); Sun, 27 Mar 2022 16:06:58 -0400 Received: from mail-lj1-x22c.google.com (mail-lj1-x22c.google.com [IPv6:2a00:1450:4864:20::22c]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 1403C4FC42 for ; Sun, 27 Mar 2022 13:05:19 -0700 (PDT) Received: by mail-lj1-x22c.google.com with SMTP id bn33so16644969ljb.6 for ; Sun, 27 Mar 2022 13:05:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux-foundation.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=wob/7GSQVIpO7i1InQcutyEWYgbvdwTICG96D7RFBB8=; b=MBKpZ1UtrtPBVIHqjdSKYB/rkJWZ1f0vdHzhtdISyO5M6IfCasC0hYp5oS9+XwcX2g onX3toZbyl+fJ/Tk2m9EN2QoWGToeUma4YxombZeY5ZkW09xgeyTm/fWrkUSPf9q19W+ djbSzf2EiLGwXDF9V4ce2XqsgWTUpumTDa/0Q= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=wob/7GSQVIpO7i1InQcutyEWYgbvdwTICG96D7RFBB8=; b=POmAIKWHlKjiDsMeaFYjnwUNIaYBA3e0Lc1ETHksdku3FTd2A6TVuOqIKpvkrW0xaK LAB5+NXGdiJXbFe85NSfP+vjripq8EiZRHhC03j/Q3J4ispikbM0VWpMFFul4ITBfeou n59RYmSTCtDNbsN7gdbabLf4ar67mghI9M8LCQfwm2xugWbzd5f9J9oP05appkzW/Y+r f3wM4a6wHCGzLiZFad0odyDp5P5l+0M7LuS65YXgMIX5kpCVijlmM0/rVtiEeETxY7+t Nu9EtPseBXqoKOVUgOZoOPEhq85yiP0YwZBC+V56lfT9nfyI2fg9MN3wBAcEblxEbH7o rXQA== X-Gm-Message-State: AOAM5300p8yPBKidJ8OQu2jts7WrTabTRpyDIK3LC7R4+9+qhc/lPDc2 k96/IaKHsqDDzfg1tp1mCDTfesKZMOKQeceJENs= X-Google-Smtp-Source: ABdhPJyCLJRIUVxmPMB4uwikqSt+3jmlKZ1bb4qL5guKuAa0Sj3PCZe5rN1G7rFBM8qM3WvZBlPFyA== X-Received: by 2002:a2e:8648:0:b0:24a:cedf:54c3 with SMTP id i8-20020a2e8648000000b0024acedf54c3mr1997985ljj.384.1648411517050; Sun, 27 Mar 2022 13:05:17 -0700 (PDT) Received: from mail-lj1-f175.google.com (mail-lj1-f175.google.com. [209.85.208.175]) by smtp.gmail.com with ESMTPSA id a20-20020a194f54000000b0044a9afab7e7sm67911lfk.290.2022.03.27.13.05.11 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sun, 27 Mar 2022 13:05:13 -0700 (PDT) Received: by mail-lj1-f175.google.com with SMTP id c15so16618109ljr.9 for ; Sun, 27 Mar 2022 13:05:11 -0700 (PDT) X-Received: by 2002:a2e:9b10:0:b0:247:f28c:ffd3 with SMTP id u16-20020a2e9b10000000b00247f28cffd3mr16821393lji.152.1648411509868; Sun, 27 Mar 2022 13:05:09 -0700 (PDT) MIME-Version: 1.0 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> <20220327054848.1a545b12.pasic@linux.ibm.com> <0745b44456d44d1e9fc364e5a3780d9a@AcuMS.aculab.com> In-Reply-To: From: Linus Torvalds Date: Sun, 27 Mar 2022 13:04:53 -0700 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [REGRESSION] Recent swiotlb DMA_FROM_DEVICE fixes break ath9k-based AP To: David Laight Cc: Halil Pasic , =?UTF-8?B?VG9rZSBIw7hpbGFuZC1Kw7hyZ2Vuc2Vu?= , Robin Murphy , Christoph Hellwig , Maxime Bizon , Oleksandr Natalenko , Marek Szyprowski , Kalle Valo , "David S. Miller" , Jakub Kicinski , Paolo Abeni , Olha Cherevyk , iommu , linux-wireless , Netdev , Linux Kernel Mailing List , Greg Kroah-Hartman , stable Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Sun, Mar 27, 2022 at 12:23 PM Linus Torvalds wrote: > > So I will propose that we really make it very much about practical > concerns, and we document things as > > (a) the "sync" operation has by definition a "whose _future_ access > do we sync for" notion. > > So "dma_sync_single_for_cpu()" says that the future accesses to > this dma area is for the CPU. > > Note how it does *NOT* say that the "CPU owns the are". That's > bullsh*t, and we now know it's BS. > > (b) but the sync operation also has a "who wrote the data we're syncing" > > Note that this is *not* "who accessed or owned it last", because > that's nonsensical: if we're syncing for the CPU, then the only reason > to do so is because we expect that the last access was by the device, > so specifying that separately would just be redundant and stupid. > > But specifying who *wrote* to the area is meaningful and matters. We could also simply require that the bounce buffer code *remember* who wrote to it last. So when the ath9k driver does - setup: bf->bf_buf_addr = dma_map_single(sc->dev, skb->data, common->rx_bufsize, DMA_FROM_DEVICE); we clear the bounce buffer and remember that the state of the bounce buffer is "device wrote to it" (because DMA_FROM_DEVICE). Then, we have an interrupt or other event, and ath9k does - rc event: dma_sync_single_for_cpu(sc->dev, bf->bf_buf_addr, common->rx_bufsize, DMA_FROM_DEVICE); ret = ath9k_hw_process_rxdesc_edma(ah, rs, skb->data); if (ret == -EINPROGRESS) { /*let device gain the buffer again*/ dma_sync_single_for_device(sc->dev, bf->bf_buf_addr, common->rx_bufsize, DMA_FROM_DEVICE); return false; } and the first dma_sync_single_for_cpu() now sees "Ok, I want the CPU buffer, and I remember that the device wrote to it, so I will copy from the bounce buffer". It's still DMA_FROM_DEVICE, so that "the device wrote to it" doesn't change. When the CPU then decides "ok, that wasn't it", and does that dma_sync_single_for_device(), the bounce buffer code goes "Ok, the last operation was that the device wrote to the buffer, so the bounce buffer is still valid and I should do nothing". Voila, no ath9k breakage, and it all still makes perfect sense. And that sounds like an even more logical model than the one where we tell the bounce buffer code what the previous operation was, but it involves basically the DMA mapping code remembering what the last direction was. That makes perfect sense to me, but it's certainly not what the DMA mapping code has traditionally done, which makes me nervous that it would just expose a _lot_ of other drivers that do odd things. The "good news" (if there is such a thing) is that usually the direction doesn't actually change. So if you use DMA_FROM_DEVICE initially, you'll continue to use that. So there is probably basically never any difference between "what was the previous operation" and "what is the next operation". So maybe practically speaking, we don't care. Anyway, I do think we have choices here on how to describe things. I do think that the "DMA code doesn't have to remember" model has the advantage that remembering is always an added complexity, and operations that behave differently depending on previous history are always a bit harder to think about because of that. Which is why I think that model I outlined in the previous email is probably the most straightforward one. Linus