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 7B17EC433F5 for ; Thu, 24 Mar 2022 19:34:27 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1352969AbiCXTf5 (ORCPT ); Thu, 24 Mar 2022 15:35:57 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:60680 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1352964AbiCXTfy (ORCPT ); Thu, 24 Mar 2022 15:35:54 -0400 Received: from mail-ej1-x631.google.com (mail-ej1-x631.google.com [IPv6:2a00:1450:4864:20::631]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 859546321 for ; Thu, 24 Mar 2022 12:34:21 -0700 (PDT) Received: by mail-ej1-x631.google.com with SMTP id j15so11205506eje.9 for ; Thu, 24 Mar 2022 12:34:21 -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:content-transfer-encoding; bh=7ocr+zNBzLy/6V5R8wtgclLYODnbC8wqaRaDBOcpGsE=; b=WXJOxqP+A5zMAAeglXUwwXwm6CdqHnTIlvW7/xITHkfLm0l9NrhvUsL/He558mycRA VdKU9P7nwZJx35e0DULKlv5C9sFMFPTxUzNh9GE1D85zKtfkg1cfIBWUR6eKr8fMZSMt poa1NyRAI1YJ+p+Bz/tVZQpcDzOAbj8llkHVA= 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:content-transfer-encoding; bh=7ocr+zNBzLy/6V5R8wtgclLYODnbC8wqaRaDBOcpGsE=; b=FQLTN9m1svlg6WOtea7XcKPCQdZDTKGKy4ayC6ZFbBjMSgg02t/Z5rnS1MFK0f/OPQ TgJLOYrF+EosAFdW6ZFPehLhokuG6pYDgykO8MiYr5YBfmJJFE386u/lkRATxTUJ7kC2 cVEQwGvhFRcaTI4dTankucWfOsxa+wu/o1hYi3ASrTBdKiO31EPKCkPMSP2evXfpJ1gb 4Ov5s+Duk1ruziplJndfm/npFfV29MeaNPMQOHJc4LafrG+xhLs5Bmckzf1eYvHB8I6F JnMkOnuLHqvzaTsXoeSimYoobytntKCp3vwrgmnz09VAcTjHolKR5g2LzNseMMHEGl6b 1uZA== X-Gm-Message-State: AOAM531Q9aF9vYvm4fB5SZRdokFWJbBbyO/qm6L5S8EP0fgZa2jPeAbu ZCsii/7QE2Xa7oqrl9hmIYR8PFZn7COQeJsG0d0= X-Google-Smtp-Source: ABdhPJynXlrK8ENqN4LxiRbHONOjs5twDC3hR4hXeSDC1Q9J0Sr0b7QgGJl9cwfBr04t15bNIXWpzw== X-Received: by 2002:a17:906:3ec7:b0:6d6:e52b:b with SMTP id d7-20020a1709063ec700b006d6e52b000bmr7656187ejj.521.1648150459802; Thu, 24 Mar 2022 12:34:19 -0700 (PDT) Received: from mail-ej1-f44.google.com (mail-ej1-f44.google.com. [209.85.218.44]) by smtp.gmail.com with ESMTPSA id yy18-20020a170906dc1200b006d6e5c75029sm1462932ejb.187.2022.03.24.12.34.19 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 24 Mar 2022 12:34:19 -0700 (PDT) Received: by mail-ej1-f44.google.com with SMTP id bi12so11260525ejb.3 for ; Thu, 24 Mar 2022 12:34:19 -0700 (PDT) X-Received: by 2002:a05:6512:3055:b0:44a:3914:6603 with SMTP id b21-20020a056512305500b0044a39146603mr4836615lfb.435.1648150029811; Thu, 24 Mar 2022 12:27: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> In-Reply-To: <871qyr9t4e.fsf@toke.dk> From: Linus Torvalds Date: Thu, 24 Mar 2022 12:26:53 -0700 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [REGRESSION] Recent swiotlb DMA_FROM_DEVICE fixes break ath9k-based AP To: =?UTF-8?B?VG9rZSBIw7hpbGFuZC1Kw7hyZ2Vuc2Vu?= Cc: Robin Murphy , Christoph Hellwig , Maxime Bizon , Oleksandr Natalenko , Halil Pasic , 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" Content-Transfer-Encoding: quoted-printable Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Mar 24, 2022 at 10:07 AM Toke H=C3=B8iland-J=C3=B8rgensen wrote: > > Right, but is that sync_for_device call really needed? Well, imagine that you have a non-cache-coherent DMA (not bounce buffers - just bad hardware)... So the driver first does that dma_sync_single_for_cpu() for the CPU see the current state (for the non-cache-coherent case it would just invalidate caches). The driver then examines the command buffer state, sees that it's still in progress, and does that return -EINPROGRESS. 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. But it doesn't seem *required*, no. The CPU caches only have a copy of the data in them, no writeback needed (and writeback wouldn't work since DMA from the device may be in progress). So I don't think the dma_sync_single_for_device() is *wrong* per se, because the CPU didn't actually do any modifications. But yes, I think it's unnecessary - because any later CPU accesses would need that dma_sync_single_for_cpu() anyway, which should invalidate any stale caches. And it clearly doesn't work in a bounce-buffer situation, but honestly I don't think a "CPU modified buffers concurrently with DMA" can *ever* work in that situation, so I think it's wrong for a bounce buffer model to ever do anything in the dma_sync_single_for_device() situation. Does removing that dma_sync_single_for_device() actually fix the problem for the ath driver? There's a fair number of those dma_sync_single_for_device() things all over. Could we find mis-uses and warn about them some way? It seems to be a very natural thing to do in this context, but bounce buffering does make them very fragile. Linus