linux-kernel - Re: [git pull] drm tree for 5.4-rc1

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] [day] [month] [year] [list]

Date:   Fri, 20 Sep 2019 08:12:29 +0200
From:   Daniel Vetter <daniel.vetter@...ll.ch>
To:     Dave Airlie <airlied@...il.com>
Cc:     Linus Torvalds <torvalds@...ux-foundation.org>,
        Alexandre Courbot <acourbot@...omium.org>,
        dri-devel <dri-devel@...ts.freedesktop.org>,
        LKML <linux-kernel@...r.kernel.org>
Subject: Re: [git pull] drm tree for 5.4-rc1

On Fri, Sep 20, 2019 at 2:11 AM Dave Airlie <airlied@...il.com> wrote:
> > Hmm. My merge isn't identical to that. It's close though. Different
> > order for one #define which might be just from you and me merging
> > different directions.
> >
> > But I also ended up removing the .gem_prime_export initialization to
> > drm_gem_prime_export, because it's the default if none exists. That's
> > the left-over from
> >
> >     3baeeb21983a ("drm/mtk: Drop drm_gem_prime_export/import")
> >
> > after the import stayed around because it got turned into an actually
> > non-default one.
> >
> > I think that both of our merges are right - equivalent but just
> > slightly different.
> >
> > But the reason I'm pointing this out is that I also get the feeling
> > that if it needs that dev->dev_private difference from the default
> > function in prime_import(), wouldn't it need the same for prime_export
> > too?
> >
> > I don't know the code, and I don't know the hardware, but just from a
> > "pattern matching" angle I just wanted to check whether maybe there's
> > need for a mtk_drm_gem_prime_export() wrapper that does that same
> > thing with
> >
> >         struct mtk_drm_private *private = dev->dev_private;
> >
> >         .. use private->dev  instead of dev->dev ..
> >
> > So I'm just asking that somebody that knows that drm/mtk code should
> > double-check that oddity.
>
> I've cc'ed Alexandre who wrote the import half of this code to look into it.
>
> I've looked at the other results and it all seems fine to me.

(pre-coffee, but let's hope the brain is awake enough)

This asymmetry in prime import/export is somewhat common for devices
with funky dma requirements/setup in the dt/soc world.

- on export we need to use the "official" struct device, so that when
we re-import (i.e. userspace just shared a buffer across process
through fd-passing, not across device-drivers) the common helpers
realize "ah this is ours, let me just grab the underlying buffer
object", instead of creating a full new buffer object handle like it
does for a real import of a dma-buf from a different device driver.
Because having 2 buffer object handles pointing at the same underlying
buffer objects tends to not go well.

- on import otoh we need to pass the struct device we actually need
for dma (which for reasons that I don't fully grok isn't the same, I
got it explained once by dt/soc folks and forgot again why exactly),
so that dma_map_sg and friends dtrt.

So that part should be all fine.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch