linux-kernel - Re: [PATCH 0/3] More ARM DMA ops cleanup

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <Yw4wbMeQqpMbTwBw@shell.armlinux.org.uk>
Date:   Tue, 30 Aug 2022 16:44:44 +0100
From:   "Russell King (Oracle)" <linux@...linux.org.uk>
To:     Robin Murphy <robin.murphy@....com>
Cc:     Yongqin Liu <yongqin.liu@...aro.org>,
        Christoph Hellwig <hch@....de>,
        linux-arm-kernel@...ts.infradead.org, m.szyprowski@...sung.com,
        arnd@...nel.org, iommu@...ts.linux-foundation.org,
        linux-kernel@...r.kernel.org,
        "Bajjuri, Praneeth" <praneeth@...com>,
        Sumit Semwal <sumit.semwal@...aro.org>
Subject: Re: [PATCH 0/3] More ARM DMA ops cleanup

On Tue, Aug 30, 2022 at 04:36:19PM +0100, Robin Murphy wrote:
> On 2022-08-30 16:19, Yongqin Liu wrote:
> > Hi, Robin
> > 
> > Thanks for the kind reply!
> > 
> > On Tue, 30 Aug 2022 at 17:48, Robin Murphy <robin.murphy@....com> wrote:
> > > 
> > > On 2022-08-27 13:24, Yongqin Liu wrote:
> > > > Hi, Robin, Christoph
> > > > 
> > > > With the changes landed in the mainline kernel,
> > > > one problem is exposed with our out of tree pvr module.
> > > > Like the source here[1], arm_dma_ops.sync_single_for_cpu is called in
> > > > the format like the following:
> > > >       arm_dma_ops.sync_single_for_cpu(NULL, pStart, pEnd - pStart,
> > > > DMA_FROM_DEVICE);
> > > > 
> > > > Not sure if you could give some suggestions on what I should do next
> > > > to make the pvr module work again.
> > > 
> > > Wow, that driver reinvents so many standard APIs for no apparent reason
> > > it's not even funny.
> > > 
> > > Anyway, from a brief look it seemingly already knows how to call the DMA
> > > API semi-correctly, so WTF that's doing behind an #ifdef, who knows?
> > > However it's still so completely wrong in general - fundamentally broken
> > > AArch64 set/way cache maintenance!? - that it looks largely beyond help.
> > > "Throw CONFIG_DMA_API_DEBUG at it and cry" is about the extent of
> > > support I'm prepared to provide for that mess.
> > 
> > For the moment, I do not care about the AArch64 lines, like if we only
> > say the following two lines:
> >      arm_dma_ops.sync_single_for_device(NULL, pStart, pEnd - pStart,
> > DMA_TO_DEVICE);
> >      arm_dma_ops.sync_single_for_cpu(NULL, pStart, pEnd - pStart,
> > DMA_FROM_DEVICE);
> > 
> > Could you please give some suggestions for that?
> 
> Remove them. Then remove the #ifdef __arch64__ too, since the code under
> there is doing a passable impression of generic DMA API usage, as long as
> one ignores the bigger picture.
> 
> arm64 already uses dma-direct. To say you don't care about the arm64 code
> when asking how to deal with ARM having now been converted to use dma-direct
> as well is supremely missing the point.

It should also be pointed out that this culture of bodging around the
DMA API by graphics drivers is entirely their own problem. If they used
the proper interfaces that the kernel provides (like the DMA API) rather
than thinking "I need to flush the caches in such-and-such a way here"
so I need to find a function somewhere in the kernel's interfaces that
I can get to in order to achieve that, and I don't care how that's done
then maybe their code wouldn't keep breaking.

This is really not our problem to solve.

This is not limited to just PVR. I've seen it with other stuff as well,
and it's the reason I was not in favour of exposing the dmac_*
functions that we have in arch/arm/mm - which are part of the DMA API
implementation, being moved into a header file. One can see from PVR
that they also made use of these before I intentionally hid them from
driver modules.

Basically, out of tree graphics drivers will bodge around to get access
to the specific cache manangement that they want to use - even if it
means abusing stuff that may mean that their crappy drivers break when
we make later changes.

As I say, it's entirely _their_ problem to solve if they don't want to
use our official interfaces. Or, they can decide to use our official
interfaces, which would be nice.

-- 
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 40Mbps down 10Mbps up. Decent connectivity at last!