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 ABD2AC433FE for ; Mon, 28 Mar 2022 00:30:29 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230503AbiC1AcH (ORCPT ); Sun, 27 Mar 2022 20:32:07 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:39208 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230373AbiC1AcE (ORCPT ); Sun, 27 Mar 2022 20:32:04 -0400 Received: from mail-lj1-x229.google.com (mail-lj1-x229.google.com [IPv6:2a00:1450:4864:20::229]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 0BC2048897 for ; Sun, 27 Mar 2022 17:30:23 -0700 (PDT) Received: by mail-lj1-x229.google.com with SMTP id c15so17085362ljr.9 for ; Sun, 27 Mar 2022 17:30:22 -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=LsBHPoKRCtwDOMc2JT/S0rILfVAOjOsIUEg1vfmMk0I=; b=KTuL8s82i3Mk75qC61EFLCdxdodMcKaC6rZIGrZq6pH27ySo4Ut4D253RZhCx2Apft KLydbkrKIkIu40UMY0bDeeXNtbHp0U0TEYaRj4iCgCkdnXvAOxzWT119PcO/nwUvO8MP RszsIWAmBGdjtyiwR7qPFzhdNHOMzILrN1FLM= 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=LsBHPoKRCtwDOMc2JT/S0rILfVAOjOsIUEg1vfmMk0I=; b=yRtwKxPMFzYtOKhuH5gi1MKByxOaj7qy/gG3PevLqAbRjXTVAnj7Q3Ndc/2rbHjJ92 9ub88hlr2zpfCvP44NF4ZtpHRUv6k12/50YY6XHSvGjf6FbsZFkV0M6VpMxdZX23v8B8 Br9WGs1ZoyKfBLbBgvdzXdMU1SE0qwpOr+0GoSWw4tPzC4T9Kb9Axft5jwl3eJjz30oj w7UFO7iUUwYaU69IS/dAZ0hUyTz1eBwN0a8IEI4ca9DCb/zHd5ziGcJ9A+INLMmfdK98 755tJwp3fLm0LTeIatCZI+rNPW9DMkUwPUVwtBCcvSMa25x0wKW0oQmzPpLM3O9iNVV6 PBXQ== X-Gm-Message-State: AOAM531hBX9e49b2CktsdVaviHuC4NBNzLxQ5ub/tGpkxsTSIW5R1tFQ /0ZsEpBefg4JUVpMOPAtdH864KyJg11g6fO5BZI= X-Google-Smtp-Source: ABdhPJxOLWomrFecUuyXWm5MP5UH8HzCWa7C9R83ot1QWtqqEi9ykVx4ywWQ9XG4wVKFfSfjUqkJPA== X-Received: by 2002:a2e:9149:0:b0:249:84ee:23fa with SMTP id q9-20020a2e9149000000b0024984ee23famr17358175ljg.196.1648427421098; Sun, 27 Mar 2022 17:30:21 -0700 (PDT) Received: from mail-lj1-f182.google.com (mail-lj1-f182.google.com. [209.85.208.182]) by smtp.gmail.com with ESMTPSA id n12-20020a19ef0c000000b0044a2aea14bdsm1484130lfh.277.2022.03.27.17.30.18 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sun, 27 Mar 2022 17:30:20 -0700 (PDT) Received: by mail-lj1-f182.google.com with SMTP id 17so17117046lji.1 for ; Sun, 27 Mar 2022 17:30:18 -0700 (PDT) X-Received: by 2002:a2e:a549:0:b0:249:9ec3:f2b with SMTP id e9-20020a2ea549000000b002499ec30f2bmr4449509ljn.358.1648427417735; Sun, 27 Mar 2022 17:30:17 -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> <20220328015211.296739a4.pasic@linux.ibm.com> In-Reply-To: <20220328015211.296739a4.pasic@linux.ibm.com> From: Linus Torvalds Date: Sun, 27 Mar 2022 17:30:01 -0700 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [REGRESSION] Recent swiotlb DMA_FROM_DEVICE fixes break ath9k-based AP To: Halil Pasic Cc: =?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 4:52 PM Halil Pasic wrote: > > I have no intention of pursuing this. When fixing the information leak, > I happened to realize, that a somewhat similar situation can emerge when > mappings are reused. It seemed like an easy fix, so I asked the swiotlb > maintainers, and they agreed. It ain't my field of expertise, and the > drivers I'm interested in don't need this functionality. Ok. That said, I think you are putting yourself down when you said in an earlier email that you aren't veryt knowledgeable in this area. I think the fact that you *did* think of this other similar situation is actually very interesting, and it's something people probably _haven't_ been thinking about. So I think your first commit fixes the straightforward and common case where you do that "map / partial dma / unmap" case. And that straightforward case is probably all that the disk IO case ever really triggers, which is presumably why those "drivers I'm interested in don't need this functionality" don't need anything else? And yes, your second commit didn't work, but hey, whatever. The whole "multiple operations on the same double buffering allocation" situation is something I don't think people have necessarily thought about enough. And by that I don't mean you. I mean very much the whole history of our dma mapping code. I then get opinionated and probably too forceful, but please don't take it as being about you - it's about just my frustration with that code - and if it comes off too negative then please accept my apologies. Linus