Received-SPF: pass (google.com: domain of linux-wireless-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Date:   Wed, 30 Mar 2022 14:11:54 +0200
From:   Halil Pasic <pasic@linux.ibm.com>
To:     Christoph Hellwig <hch@lst.de>
Cc:     Linus Torvalds <torvalds@linux-foundation.org>,
        Robin Murphy <robin.murphy@arm.com>,
        Toke =?UTF-8?B?SMO4aWxhbmQtSsO4cmdlbnNlbg==?= <toke@toke.dk>,
        Oleksandr Natalenko <oleksandr@natalenko.name>,
        Marek Szyprowski <m.szyprowski@samsung.com>,
        Kalle Valo <kvalo@kernel.org>,
        "David S. Miller" <davem@davemloft.net>,
        Jakub Kicinski <kuba@kernel.org>,
        Paolo Abeni <pabeni@redhat.com>,
        Olha Cherevyk <olha.cherevyk@gmail.com>,
        iommu <iommu@lists.linux-foundation.org>,
        linux-wireless <linux-wireless@vger.kernel.org>,
        Netdev <netdev@vger.kernel.org>,
        Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
        Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
        stable <stable@vger.kernel.org>,
        Halil Pasic <pasic@linux.ibm.com>
Subject: Re: [REGRESSION] Recent swiotlb DMA_FROM_DEVICE fixes break
 ath9k-based AP
Message-ID: <20220330141154.2ed284f1.pasic@linux.ibm.com>
In-Reply-To: <20220328063723.GA29405@lst.de>
References: <1812355.tdWV9SEqCh@natalenko.name>
        <CAHk-=wiwz+Z2MaP44h086jeniG-OpK3c=FywLsCwXV7Crvadrg@mail.gmail.com>
        <27b5a287-7a33-9a8b-ad6d-04746735fb0c@arm.com>
        <CAHk-=wip7TCD_+2STTepuEZvGMg6wcz+o=kyFUvHjuKziTMixw@mail.gmail.com>
        <f88ca616-96d1-82dc-1bc8-b17480e937dd@arm.com>
        <20220324190216.0efa067f.pasic@linux.ibm.com>
        <20220325163204.GB16426@lst.de>
        <87y20x7vaz.fsf@toke.dk>
        <e077b229-c92b-c9a6-3581-61329c4b4a4b@arm.com>
        <CAHk-=wgKF5GfLXyVGDQDifh0MpMccDdmBvJBG3dt2+idCa5DzQ@mail.gmail.com>
        <20220328063723.GA29405@lst.de>
Organization: IBM
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 8bit
Precedence: bulk

On Mon, 28 Mar 2022 08:37:23 +0200
Christoph Hellwig <hch@lst.de> wrote:

> On Fri, Mar 25, 2022 at 11:46:09AM -0700, Linus Torvalds wrote:
> > I think my list of three different sync cases (not just two! It's not
> > just about whether to sync for the CPU or the device, it's also about
> > what direction the data itself is taking) is correct.
> > 
> > But maybe I'm wrong.  
> 
> At the high level you are correct.  It is all about which direction
> the data is taking.  That is the direction argument that all the
> map/unmap/sync call take.  The sync calls then just toggle the ownership.
> You seem to hate that ownership concept, but I don't see how things
> could work without that ownership concept as we're going to be in
> trouble without having that.  And yes, a peek operation could work in
> some cases, but it would have to be at the cache line granularity.
> 
> arch/arc/mm/dma.c has a really good comment how these transfers relate
> to actual cache operations btw>
> 
>  *
>  *          |   map          ==  for_device     |   unmap     ==  for_cpu
>  *          |----------------------------------------------------------------
>  * TO_DEV   |   writeback        writeback      |   none          none
>  * FROM_DEV |   invalidate       invalidate     |   invalidate*	  invalidate*

Very interesting! Does that mean that

memset(buf, 0, size);
dma_map(buf, size, FROM_DEVICE)
device does a partial write
dma_unmap(buf, size, FROM_DEVICE)

may boil down to being the same as without the memset(), because the
effect of the memset() may get thrown away by the cache invalidate?

That is in this scenario we could actually leak the original content of
the buffer if we have a non-dma-coherent cache?

Regards,
Halil 

>  * BIDIR    |   writeback+inv    writeback+inv  |   invalidate    invalidate
>  *
>  *     [*] needed for CPU speculative prefetches