[Intel-gfx] [PATCH 20/45] drm/i915: Apply an execution_mask to the virtual_engine

Tvrtko Ursulin tvrtko.ursulin at linux.intel.com
Wed May 8 08:48:41 UTC 2019


On 07/05/2019 17:59, Chris Wilson wrote:
> Quoting Tvrtko Ursulin (2019-04-29 15:12:23)
>>
>> On 25/04/2019 10:19, Chris Wilson wrote:
>>>    static void virtual_submission_tasklet(unsigned long data)
>>>    {
>>>        struct virtual_engine * const ve = (struct virtual_engine *)data;
>>>        const int prio = ve->base.execlists.queue_priority_hint;
>>> +     intel_engine_mask_t mask;
>>>        unsigned int n;
>>>    
>>> +     rcu_read_lock();
>>> +     mask = virtual_submission_mask(ve);
>>> +     rcu_read_unlock();
>>> +     if (unlikely(!mask))
>>
>> Is the rcu_lock think solely for the same protection against wedging in
>> submit_notify?
> 
> No. We may still be in the rbtree of the physical engines and
> ve->request may be plucked out from underneath us as we read it. And in
> the time it takes to tracek, that request may have been executed,
> retired and freed. To prevent the dangling stale dereference, we use
> rcu_read_lock() here as we peek into the request, and spinlocks around
> the actual transfer to the execution backend.

So it's not actually about ve->request as s member pointer, but the 
request object itself. That could make sense, but then wouldn't you need 
to hold the rcu_read_lock over the whole tasklet? There is another 
ve->request read in the for loop just below, although not an actual 
dereference. I guess I just answered it to myself. Okay, looks good then.

Regards,

Tvrtko


More information about the Intel-gfx mailing list