The kernel code will create a new gem handle for SHARED handle every
time, see code here:
https://github.com/torvalds/linux/blob/master/drivers/gpu/drm/drm_gem.c#L796
On Mon, Apr 8, 2019 at 11:12 AM Chia-I Wu wrote:
>
>
>
> On Wed, Apr 3, 2019 at 8:17 PM Dave Airlie wrote:
>>
>> On Thu, 4 Apr
On Wed, Apr 3, 2019 at 8:17 PM Dave Airlie wrote:
> On Thu, 4 Apr 2019 at 06:54, Chia-I Wu wrote:
> >
> > You could end up having two virgl_hw_res with two different GEM handles
> pointing to the same kernel GEM object. That might break some assumptions
> about dependency tracking.
> >
> > For
On Thu, 4 Apr 2019 at 06:54, Chia-I Wu wrote:
>
> You could end up having two virgl_hw_res with two different GEM handles
> pointing to the same kernel GEM object. That might break some assumptions
> about dependency tracking.
>
> For example, when the cmdbuf being built uses a buffer and you
You could end up having two virgl_hw_res with two different GEM handles
pointing to the same kernel GEM object. That might break some assumptions
about dependency tracking.
For example, when the cmdbuf being built uses a buffer and you want to
transfer some more data into the buffer, you
On Wed, Mar 20, 2019 at 3:03 PM Chia-I Wu wrote:
> On Mon, Mar 18, 2019 at 2:22 PM Lepton Wu wrote:
>
>> The old code could use gem name as key when inserting it to bo_handles
>> hash table while trying to remove it from hash table with bo_handle as
>> key in virgl_hw_res_destroy. This triggers
On Mon, Mar 18, 2019 at 2:22 PM Lepton Wu wrote:
> The old code could use gem name as key when inserting it to bo_handles
> hash table while trying to remove it from hash table with bo_handle as
> key in virgl_hw_res_destroy. This triggers use after free. Also, we
> should only reuse resource
The old code could use gem name as key when inserting it to bo_handles
hash table while trying to remove it from hash table with bo_handle as
key in virgl_hw_res_destroy. This triggers use after free. Also, we
should only reuse resource from bo_handle hash when the handle type is
FD.
