linux-kernel - Re: [PATCH] dma-buf: refcount the attachment for cache_sgt

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]

Message-ID: <20190612082549.GA9072@Asurada>
Date:   Wed, 12 Jun 2019 01:25:49 -0700
From:   Nicolin Chen <nicoleotsuka@...il.com>
To:     "Koenig, Christian" <Christian.Koenig@....com>
Cc:     "sumit.semwal@...aro.org" <sumit.semwal@...aro.org>,
        "linux-media@...r.kernel.org" <linux-media@...r.kernel.org>,
        "dri-devel@...ts.freedesktop.org" <dri-devel@...ts.freedesktop.org>,
        "linaro-mm-sig@...ts.linaro.org" <linaro-mm-sig@...ts.linaro.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "daniel.vetter@...ll.ch" <daniel.vetter@...ll.ch>
Subject: Re: [PATCH] dma-buf: refcount the attachment for cache_sgt_mapping

On Wed, Jun 12, 2019 at 08:20:41AM +0000, Koenig, Christian wrote:
> Am 12.06.19 um 10:15 schrieb Nicolin Chen:
> > Hi Christian,
> >
> > On Wed, Jun 12, 2019 at 08:05:53AM +0000, Koenig, Christian wrote:
> >> Am 12.06.19 um 10:02 schrieb Nicolin Chen:
> >> [SNIP]
> >>> We haven't used DRM/GRM_PRIME yet but I am also curious would it
> >>> benefit DRM also if we reduce this overhead in the dma_buf?
> >> No, not at all.
> >  From you replies, in a summary, does it means that there won't be a case
> > of DRM having a dma_buf attaching to the same device, i.e. multiple calls
> > of drm_gem_prime_import() function with same parameters of dev + dma_buf?
> 
> Well, there are some cases where this happens. But in those cases we 
> intentionally want to get a new attachment :)

Got it.

> So thinking more about it you would actually break those and that is not 
> something we can do.

That's true...

> > If so, we can just ignore/drop this patch. Sorry for the misunderstanding.
> 
> It might be interesting for things like P2P, but even then it might be 
> better to just cache the P2P settings instead of the full attachment.

I see. Thank you for the answers!