linux-kernel

Open Source and information security mailing list archives

Message-ID: <CAMSo37UUXd9FT1coAqgxU4urXi0NeCkONesmWqFfyrdDi+03dA@mail.gmail.com>
Date:   Thu, 1 Sep 2022 00:41:29 +0800
From:   Yongqin Liu <yongqin.liu@...aro.org>
To:     Robin Murphy <robin.murphy@....com>
Cc:     Christoph Hellwig <hch@....de>, linux@...linux.org.uk,
        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

Hi, Robin

On Tue, 30 Aug 2022 at 23:37, Robin Murphy <robin.murphy@....com> 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.

I tried with this method, and found that if I only update for the
pvr_flush_range
and the pvr_clean_range functions, the build still could boot to the
home screen.

but if I update all the pvr_flush_range, pvr_clean_range and
pvr_invalidate_range
functions with this method(remove the arm_dma_ops lines and the #ifdef
__arch64__ lines),
then a "Unable to handle kernel NULL pointer dereference at virtual
address 0000003c"
error is reported like here: http://ix.io/49gu

Not sure if you have any idea from the log, or could you please give
some suggestions
on how to debug it.

> 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.

Sorry for that, I am not familiar with the dma part, and just know
"dma-direct" from here,
will check how "dma-direct" should be used next, and check if there is
something wrong in
the pvr source code.
It would be appreciated if you could suggest some links on
"dma-direct" I can study with.

Thanks,
Yongqin Liu
> >
> >
> >>> Thanks in advance!
> >>>
> >>> [1]: https://android-git.linaro.org/kernel/omap-modules.git/tree/pvr/services4/srvkm/env/linux/osfunc.c?h=android-mainline#n4615
> >>>
> >>> Thanks,
> >>> Yongqin Liu
> >>>
> >>> On Thu, 21 Apr 2022 at 22:35, Robin Murphy <robin.murphy@....com> wrote:
> >>>>
> >>>> On 2022-04-21 15:13, Christoph Hellwig wrote:
> >>>>> On Thu, Apr 21, 2022 at 12:36:56PM +0100, Robin Murphy wrote:
> >>>>>> Hi all,
> >>>>>>
> >>>>>> Thanks to Christoph's latest series, I'm reminded that, if we're going
> >>>>>> to give the ARM DMA ops some cleanup this cycle, it's as good a time as
> >>>>>> any to dust off these old patches and add them on top as well. I've
> >>>>>> based these on the arm-dma-direct branch which I assume matches the
> >>>>>> patches posted at [1].
> >>>>>
> >>>>> All these do look sensible to me.  But weren't you working on replacing
> >>>>> the ARM iommu dma_ops with dma-іommu anyway?
> >>>>
> >>>> Yes, that's somewhat entangled with the IOMMU bus ops stuff, so I'll
> >>>> probably get to the point of having to revisit it in a couple of months
> >>>> or so. These patches are off the bottom of that stack from my first
> >>>> attempt, where the aim was to make the current ops the same shape first
> >>>> so that the switch is then easier to reason about (particularly in terms
> >>>> of sounding out any issues with the hooking up of dev->dma_coherent,
> >>>> although your series will now be taking most of the load off there).
> >>>>
> >>>> Cheers,
> >>>> Robin.
> >>>
> >>>
> >>>
> >
> >
> >

-- 
Best Regards,
Yongqin Liu
---------------------------------------------------------------
#mailing list
linaro-android@...ts.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-android

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