[RFC PATCH 1/2] dma-fence: Avoid establishing a locking order between fence classes
Thomas Hellström
thomas.hellstrom at linux.intel.com
Tue Nov 30 12:56:13 UTC 2021
On 11/30/21 13:42, Christian König wrote:
> Am 30.11.21 um 13:31 schrieb Thomas Hellström:
>> [SNIP]
>>> Other than that, I didn't investigate the nesting fails enough to
>>> say I can accurately review this. :)
>>
>> Basically the problem is that within enable_signaling() which is
>> called with the dma_fence lock held, we take the dma_fence lock of
>> another fence. If that other fence is a dma_fence_array, or a
>> dma_fence_chain which in turn tries to lock a dma_fence_array we hit
>> a splat.
>
> Yeah, I already thought that you constructed something like that.
>
> You get the splat because what you do here is illegal, you can't mix
> dma_fence_array and dma_fence_chain like this or you can end up in a
> stack corruption.
Hmm. Ok, so what is the stack corruption, is it that the
enable_signaling() will end up with endless recursion? If so, wouldn't
it be more usable we break that recursion chain and allow a more general
use?
Also what are the mixing rules between these? Never use a
dma-fence-chain as one of the array fences and never use a
dma-fence-array as a dma-fence-chain fence?
/Thomas
>
> Regards,
> Christian.
>
>>
>> But I'll update the commit message with a typical splat.
>>
>> /Thomas
>
More information about the dri-devel
mailing list