; ; open list:DMA BUFFER SHARING FRAMEWORK
>> ; DRI mailing list > de...@lists.freedesktop.org>
>> Cc: Linaro MM SIG ;
>> vinme...@codeaurora.org; LKML ;
>> sta...@vger.kernel.org
>> Subject: Re: [PATCH] dmabuf: use spinlock to access dmabuf->name
>>
On 6/17/2020 1:51 PM, David Laight wrote:
> From: Charan Teja Kalla
>> Sent: 17 June 2020 07:29
> ...
If name is freed you will copy garbage, but the only way
for that to happen is that _set_name or _release have to be called
at just the right time.
And the above would p
From: Charan Teja Kalla
> Sent: 17 June 2020 07:29
...
> >> If name is freed you will copy garbage, but the only way
> >> for that to happen is that _set_name or _release have to be called
> >> at just the right time.
> >>
> >> And the above would probably only be an issue if the set_name
> >> was
.org>
>Cc: Linaro MM SIG ;
>vinme...@codeaurora.org; LKML ;
>sta...@vger.kernel.org
>Subject: Re: [PATCH] dmabuf: use spinlock to access dmabuf->name
>
>Thanks Michael for the comments..
>
>On 6/16/2020 7:29 PM, Ruhl, Michael J wrote:
>>> -Original Mes
MA BUFFER SHARING FRAMEWORK
>> ; DRI mailing list > de...@lists.freedesktop.org>
>> Cc: Linaro MM SIG ;
>> vinme...@codeaurora.org; LKML ;
>> sta...@vger.kernel.org
>> Subject: RE: [PATCH] dmabuf: use spinlock to access dmabuf->name
>>
>>> -
;vinme...@codeaurora.org; LKML ;
>sta...@vger.kernel.org
>Subject: RE: [PATCH] dmabuf: use spinlock to access dmabuf->name
>
>>-Original Message-
>>From: dri-devel On Behalf Of
>>Charan Teja Kalla
>>Sent: Thursday, June 11, 2020 9:40 AM
>>To: Sumit
>-Original Message-
>From: dri-devel On Behalf Of
>Charan Teja Kalla
>Sent: Thursday, June 11, 2020 9:40 AM
>To: Sumit Semwal ; open list:DMA BUFFER
>SHARING FRAMEWORK ; DRI mailing list de...@lists.freedesktop.org>
>Cc: Linaro MM SIG ;
>vinme...@codeaurora.org; LKML ;
>sta...@vger.kernel.
Hi Daniel, Chris,
On Thu, 11 Jun 2020 at 19:10, Charan Teja Kalla wrote:
>
> There exists a sleep-while-atomic bug while accessing the dmabuf->name
> under mutex in the dmabuffs_dname(). This is caused from the SELinux
> permissions checks on a process where it tries to validate the inherited
> f
