Am 24.08.19 um 21:12 schrieb Chris Wilson: > Quoting Koenig, Christian (2019-08-24 20:04:43) >> Am 24.08.19 um 15:58 schrieb Chris Wilson: >>> In order to allow dma-fence-array as a generic container for fences, we >>> need to allow for it to contain other dma-fence-arrays. By giving each >>> dma-fence-array construction their own lockclass, we allow different >>> types of dma-fence-array to nest, but still do not allow on class of >>> dma-fence-array to contain itself (even though they have distinct >>> locks). >>> >>> In practice, this means that each subsystem gets its own dma-fence-array >>> class and we can freely use dma-fence-arrays as containers within the >>> dmabuf core without angering lockdep. >> I've considered this for as well. E.g. to use the dma_fence_array >> implementation instead of coming up with the dma_fence_chain container. >> >> But as it turned out when userspace can control nesting, it is trivial >> to chain enough dma_fence_arrays together to cause an in kernel stack >> overflow. Which in turn creates a really nice attack vector. >> >> So as long as userspace has control over dma_fence_array nesting this is >> a clear NAK and actually extremely dangerous. > You are proposing to use recursive dma_fence_array containers for > dma_resv... Hui? Where? I've tried rather hard to avoid that. That was certainly not intentional, Christian. > >> It actually took me quite a while to get the dma_fence_chain container >> recursion less to avoid stuff like this. > Sure, we've been avoiding recursion for years. > -Chris _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
