Re: [Linaro-mm-sig] [PATCH] RFC: dma-buf: Add an API for importing and exporting sync files
Am 26.02.20 um 17:46 schrieb Bas Nieuwenhuizen:
On Wed, Feb 26, 2020 at 4:29 PM Jason Ekstrand jason@jlekstrand.net wrote:
On Wed, Feb 26, 2020 at 4:05 AM Daniel Vetter daniel@ffwll.ch wrote:
On Wed, Feb 26, 2020 at 10:16:05AM +0100, Christian König wrote: [SNIP]
Just imagine that you access some DMA-buf with a shader and that operation is presented as a fence on the DMA-bufs reservation object. And now you can go ahead and replace that fence and free up the memory.
Tricking the Linux kernel into allocating page tables in that freed memory is trivial and that's basically it you can overwrite page tables with your shader and gain access to all of system memory :)
What we could do is to always make sure that the added fences will complete later than the already existing ones, but that is also rather tricky to get right. I wouldn't do that if we don't have a rather big use case for this.
Right. I thought about that but I'm still learning how dma_resv works. It'd be easy enough to make a fence array that contains both the old fence and the new fence and replace the old fence with that. What I don't know is the proper way to replace the exclusive fence safely. Some sort of atomic_cpxchg loop, perhaps? I presume there's some way of doing it properly because DRM drivers are doing it all the time.
First of all you need to grab the lock of the dma_resv object or you can't replace the exclusive nor the shared ones.
This way you don't need to do a atomic_cmpxchg or anything else and still guarantee correct ordering.
I think for an exclusive fence you may need to create a fence array that includes the existing exclusive and shared fences in the dma_resv combined with the added fence.
Yes, that at least gives us the correct synchronization.
However, I'm not sure what the best way is to do garbage collection on that so that we don't get an impossibly list of fence arrays.
Exactly yes. That's also the reason why the dma_fence_chain container I came up with for the sync timeline stuff has such a rather sophisticated garbage collection.
When some of the included fences signal you need to free up the array/chain and make sure that the memory for the container can be reused.
(Note the dma_resv has a lock that needs to be taken before adding an exclusive fence, might be useful). Some code that does a thing like this is __dma_resv_make_exclusive in drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.c
Wanted to move that into dma_resv.c for quite a while since there are quite a few other cases where we need this.
Regards, Christian.
The other piece of the puzzle is that on the submit path this would need something to ignore implicit fences. And there semantically the question comes up whether it is safe for a driver to ignore exclusive fences from another driver. (and then we have amdgpu which has its own rules on exclusiveness of its shared fences based on the context. e.g. the current option to ignore implicit fences for a buffer still syncs on exclusive fences on the buffer).
On Thu, Feb 27, 2020 at 2:28 AM Christian König christian.koenig@amd.com wrote:
Am 26.02.20 um 17:46 schrieb Bas Nieuwenhuizen:
On Wed, Feb 26, 2020 at 4:29 PM Jason Ekstrand jason@jlekstrand.net wrote:
On Wed, Feb 26, 2020 at 4:05 AM Daniel Vetter daniel@ffwll.ch wrote:
On Wed, Feb 26, 2020 at 10:16:05AM +0100, Christian König wrote: [SNIP]
Just imagine that you access some DMA-buf with a shader and that operation is presented as a fence on the DMA-bufs reservation object. And now you can go ahead and replace that fence and free up the memory.
Tricking the Linux kernel into allocating page tables in that freed memory is trivial and that's basically it you can overwrite page tables with your shader and gain access to all of system memory :)
What we could do is to always make sure that the added fences will complete later than the already existing ones, but that is also rather tricky to get right. I wouldn't do that if we don't have a rather big use case for this.
Right. I thought about that but I'm still learning how dma_resv works. It'd be easy enough to make a fence array that contains both the old fence and the new fence and replace the old fence with that. What I don't know is the proper way to replace the exclusive fence safely. Some sort of atomic_cpxchg loop, perhaps? I presume there's some way of doing it properly because DRM drivers are doing it all the time.
First of all you need to grab the lock of the dma_resv object or you can't replace the exclusive nor the shared ones.
This way you don't need to do a atomic_cmpxchg or anything else and still guarantee correct ordering.
Fixed in v3.
I think for an exclusive fence you may need to create a fence array that includes the existing exclusive and shared fences in the dma_resv combined with the added fence.
Yes, that at least gives us the correct synchronization.
Fixed in v2
However, I'm not sure what the best way is to do garbage collection on that so that we don't get an impossibly list of fence arrays.
Exactly yes. That's also the reason why the dma_fence_chain container I came up with for the sync timeline stuff has such a rather sophisticated garbage collection.
When some of the included fences signal you need to free up the array/chain and make sure that the memory for the container can be reused.
Currently (as of v2), I'm using dma_fence_array and being careful to not bother constructing one if there's only one fence in play. Is this insufficient? If so, maybe we should consider improving dma_fence_array.
(Note the dma_resv has a lock that needs to be taken before adding an exclusive fence, might be useful). Some code that does a thing like this is __dma_resv_make_exclusive in drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.c
Wanted to move that into dma_resv.c for quite a while since there are quite a few other cases where we need this.
I've roughly done that. The primary difference is that my version takes an optional additional fence to add to the array. This makes it a bit more complicated but I think I got it mostly right.
I've also written userspace code which exercises this and it seems to work. Hopefully, that will give a better idea of what I'm trying to accomplish.
https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/4037
--Jason
Am 03.03.20 um 20:10 schrieb Jason Ekstrand:
On Thu, Feb 27, 2020 at 2:28 AM Christian König christian.koenig@amd.com wrote:
[SNIP]
However, I'm not sure what the best way is to do garbage collection on that so that we don't get an impossibly list of fence arrays.
Exactly yes. That's also the reason why the dma_fence_chain container I came up with for the sync timeline stuff has such a rather sophisticated garbage collection.
When some of the included fences signal you need to free up the array/chain and make sure that the memory for the container can be reused.
Currently (as of v2), I'm using dma_fence_array and being careful to not bother constructing one if there's only one fence in play. Is this insufficient? If so, maybe we should consider improving dma_fence_array.
That still won't work correctly in all cases. See the problem is not only optimization, but also avoiding situations where userspace can abuse the interface to do nasty things.
For example if userspace just calls that function in a loop you can create a long chain of dma_fence_array objects.
If that chain is then suddenly released the recursive dropping of references can overwrite the kernel stack.
For reference see what dance is necessary in the dma_fence_chain_release function to avoid that:
/* Manually unlink the chain as much as possible to avoid recursion * and potential stack overflow. */ while ((prev = rcu_dereference_protected(chain->prev, true))) {
....
It took me quite a while to figure out how to do this without causing issues. But I don't see how this would be possible for dma_fence_array.
As far as I can see the only real option to implement this would be to change the dma_resv object container so that you can add fences without overriding existing ones.
For shared fences that can be done relative easily, but I absolutely don't see how to do this for exclusive ones without a larger rework.
(Note the dma_resv has a lock that needs to be taken before adding an exclusive fence, might be useful). Some code that does a thing like this is __dma_resv_make_exclusive in drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.c
Wanted to move that into dma_resv.c for quite a while since there are quite a few other cases where we need this.
I've roughly done that. The primary difference is that my version takes an optional additional fence to add to the array. This makes it a bit more complicated but I think I got it mostly right.
I've also written userspace code which exercises this and it seems to work. Hopefully, that will give a better idea of what I'm trying to accomplish.
Yes, that is indeed a really nice to have feature.
Regards, Christian.
On Wed, Mar 4, 2020 at 2:34 AM Christian König christian.koenig@amd.com wrote:
Am 03.03.20 um 20:10 schrieb Jason Ekstrand:
On Thu, Feb 27, 2020 at 2:28 AM Christian König christian.koenig@amd.com wrote:
[SNIP]
However, I'm not sure what the best way is to do garbage collection on that so that we don't get an impossibly list of fence arrays.
Exactly yes. That's also the reason why the dma_fence_chain container I came up with for the sync timeline stuff has such a rather sophisticated garbage collection.
When some of the included fences signal you need to free up the array/chain and make sure that the memory for the container can be reused.
Currently (as of v2), I'm using dma_fence_array and being careful to not bother constructing one if there's only one fence in play. Is this insufficient? If so, maybe we should consider improving dma_fence_array.
That still won't work correctly in all cases. See the problem is not only optimization, but also avoiding situations where userspace can abuse the interface to do nasty things.
For example if userspace just calls that function in a loop you can create a long chain of dma_fence_array objects.
If that chain is then suddenly released the recursive dropping of references can overwrite the kernel stack.
For reference see what dance is necessary in the dma_fence_chain_release function to avoid that:
/* Manually unlink the chain as much as possible to avoidrecursion * and potential stack overflow. */ while ((prev = rcu_dereference_protected(chain->prev, true))) {
....
It took me quite a while to figure out how to do this without causing issues. But I don't see how this would be possible for dma_fence_array.
Ah, I see the issue now! It hadn't even occurred to me that userspace could use this to build up an infinite recursion chain. That's nasty! I'll give this some more thought and see if can come up with something clever.
Here's one thought: We could make dma_fence_array automatically collapse any arrays it references and instead directly reference their fences. This way, no matter how much the client chains things, they will never get more than one dma_fence_array. Of course, the difficulty here (answering my own question) comes if they ping-pong back-and-forth between something which constructs a dma_fence_array and something which constructs a dma_fence_chain to get array-of-chain-of-array-of-chain-of-... More thought needed.
As far as I can see the only real option to implement this would be to change the dma_resv object container so that you can add fences without overriding existing ones.
For shared fences that can be done relative easily, but I absolutely don't see how to do this for exclusive ones without a larger rework.
Fair enough. Thanks for taking the time to explain the issue. I'll give this some more thought.
--Jason
(Note the dma_resv has a lock that needs to be taken before adding an exclusive fence, might be useful). Some code that does a thing like this is __dma_resv_make_exclusive in drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.c
Wanted to move that into dma_resv.c for quite a while since there are quite a few other cases where we need this.
I've roughly done that. The primary difference is that my version takes an optional additional fence to add to the array. This makes it a bit more complicated but I think I got it mostly right.
I've also written userspace code which exercises this and it seems to work. Hopefully, that will give a better idea of what I'm trying to accomplish.
Yes, that is indeed a really nice to have feature.
Regards, Christian.
On Wed, Mar 4, 2020 at 10:27 AM Jason Ekstrand jason@jlekstrand.net wrote:
On Wed, Mar 4, 2020 at 2:34 AM Christian König christian.koenig@amd.com wrote:
Am 03.03.20 um 20:10 schrieb Jason Ekstrand:
On Thu, Feb 27, 2020 at 2:28 AM Christian König christian.koenig@amd.com wrote:
[SNIP]
However, I'm not sure what the best way is to do garbage collection on that so that we don't get an impossibly list of fence arrays.
Exactly yes. That's also the reason why the dma_fence_chain container I came up with for the sync timeline stuff has such a rather sophisticated garbage collection.
When some of the included fences signal you need to free up the array/chain and make sure that the memory for the container can be reused.
Currently (as of v2), I'm using dma_fence_array and being careful to not bother constructing one if there's only one fence in play. Is this insufficient? If so, maybe we should consider improving dma_fence_array.
That still won't work correctly in all cases. See the problem is not only optimization, but also avoiding situations where userspace can abuse the interface to do nasty things.
For example if userspace just calls that function in a loop you can create a long chain of dma_fence_array objects.
If that chain is then suddenly released the recursive dropping of references can overwrite the kernel stack.
For reference see what dance is necessary in the dma_fence_chain_release function to avoid that:
/* Manually unlink the chain as much as possible to avoidrecursion * and potential stack overflow. */ while ((prev = rcu_dereference_protected(chain->prev, true))) {
....
It took me quite a while to figure out how to do this without causing issues. But I don't see how this would be possible for dma_fence_array.
Ah, I see the issue now! It hadn't even occurred to me that userspace could use this to build up an infinite recursion chain. That's nasty! I'll give this some more thought and see if can come up with something clever.
Here's one thought: We could make dma_fence_array automatically collapse any arrays it references and instead directly reference their fences. This way, no matter how much the client chains things, they will never get more than one dma_fence_array. Of course, the difficulty here (answering my own question) comes if they ping-pong back-and-forth between something which constructs a dma_fence_array and something which constructs a dma_fence_chain to get array-of-chain-of-array-of-chain-of-... More thought needed.
Answering my own questions again... I think the array-of-chain-of-array case is also solvable.
For array-of-chain, we can simply add all unsignaled dma_fences in the chain to the array. The array won't signal until all of them have which is exactly the same behavior as if we'd added the chain itself.
For chain-of-array, we can add all unsignaled dma_fences in the array to the same point in the chain. There may be some fiddling with the chain numbering required here but I think we can get it so the chain won't signal until everything in the array has signaled and we get the same behavior as if we'd added the dma_fence_array to the chain.
In both cases, we end up with either a single array or a single and destruction doesn't require recursion. Thoughts?
--Jason
Am 04.03.20 um 17:41 schrieb Jason Ekstrand:
On Wed, Mar 4, 2020 at 10:27 AM Jason Ekstrand jason@jlekstrand.net wrote:
On Wed, Mar 4, 2020 at 2:34 AM Christian König christian.koenig@amd.com wrote:
Am 03.03.20 um 20:10 schrieb Jason Ekstrand:
On Thu, Feb 27, 2020 at 2:28 AM Christian König christian.koenig@amd.com wrote: [SNIP]
For reference see what dance is necessary in the dma_fence_chain_release function to avoid that:
/* Manually unlink the chain as much as possible to avoidrecursion * and potential stack overflow. */ while ((prev = rcu_dereference_protected(chain->prev, true))) {
....
It took me quite a while to figure out how to do this without causing issues. But I don't see how this would be possible for dma_fence_array.
Ah, I see the issue now! It hadn't even occurred to me that userspace could use this to build up an infinite recursion chain. That's nasty!
Yeah, when I first stumbled over it it was like why the heck is my code crashing in an interrupt handler?
Realizing that this is stack corruption because of the long chain we constructed was quite an enlightenment.
And then it took me even longer to fix it :)
I'll give this some more thought and see if can come up with something clever.
Here's one thought: We could make dma_fence_array automatically collapse any arrays it references and instead directly reference their fences. This way, no matter how much the client chains things, they will never get more than one dma_fence_array. Of course, the difficulty here (answering my own question) comes if they ping-pong back-and-forth between something which constructs a dma_fence_array and something which constructs a dma_fence_chain to get array-of-chain-of-array-of-chain-of-... More thought needed.
Condensing the fences into a larger array can certainly work, yes.
Answering my own questions again... I think the array-of-chain-of-array case is also solvable.
For array-of-chain, we can simply add all unsignaled dma_fences in the chain to the array. The array won't signal until all of them have which is exactly the same behavior as if we'd added the chain itself.
Yeah, that should work. Probably best to implement something like a cursor to walk all fences in the data structure.
For chain-of-array, we can add all unsignaled dma_fences in the array to the same point in the chain. There may be some fiddling with the chain numbering required here but I think we can get it so the chain won't signal until everything in the array has signaled and we get the same behavior as if we'd added the dma_fence_array to the chain.
Well as far as I can see this won't work because it would break the semantics of the timeline sync.
But I think I know a different way which should work: A dma_fence_chain can still contain a dma_fence_array, only the other way around is forbidden. Then we create the cursor functionality in such a way that it allows us to deep dive into the data structure and return all containing fences one by one.
I can prototype that if you want, shouldn't be more than a few hours of hacking anyway.
Regards, Christian.
In both cases, we end up with either a single array or a single and destruction doesn't require recursion. Thoughts?
--Jason
On Thu, Mar 5, 2020 at 7:06 AM Christian König christian.koenig@amd.com wrote:
Am 04.03.20 um 17:41 schrieb Jason Ekstrand:
On Wed, Mar 4, 2020 at 10:27 AM Jason Ekstrand jason@jlekstrand.net wrote:
On Wed, Mar 4, 2020 at 2:34 AM Christian König christian.koenig@amd.com wrote:
Am 03.03.20 um 20:10 schrieb Jason Ekstrand:
On Thu, Feb 27, 2020 at 2:28 AM Christian König christian.koenig@amd.com wrote: [SNIP]
For reference see what dance is necessary in the dma_fence_chain_release function to avoid that:
/* Manually unlink the chain as much as possible to avoidrecursion * and potential stack overflow. */ while ((prev = rcu_dereference_protected(chain->prev, true))) {
....
It took me quite a while to figure out how to do this without causing issues. But I don't see how this would be possible for dma_fence_array.
Ah, I see the issue now! It hadn't even occurred to me that userspace could use this to build up an infinite recursion chain. That's nasty!
Yeah, when I first stumbled over it it was like why the heck is my code crashing in an interrupt handler?
Realizing that this is stack corruption because of the long chain we constructed was quite an enlightenment.
And then it took me even longer to fix it :)
Fun....
I'll give this some more thought and see if can come up with something clever.
Here's one thought: We could make dma_fence_array automatically collapse any arrays it references and instead directly reference their fences. This way, no matter how much the client chains things, they will never get more than one dma_fence_array. Of course, the difficulty here (answering my own question) comes if they ping-pong back-and-forth between something which constructs a dma_fence_array and something which constructs a dma_fence_chain to get array-of-chain-of-array-of-chain-of-... More thought needed.
Condensing the fences into a larger array can certainly work, yes.
Answering my own questions again... I think the array-of-chain-of-array case is also solvable.
For array-of-chain, we can simply add all unsignaled dma_fences in the chain to the array. The array won't signal until all of them have which is exactly the same behavior as if we'd added the chain itself.
Yeah, that should work. Probably best to implement something like a cursor to walk all fences in the data structure.
For chain-of-array, we can add all unsignaled dma_fences in the array to the same point in the chain. There may be some fiddling with the chain numbering required here but I think we can get it so the chain won't signal until everything in the array has signaled and we get the same behavior as if we'd added the dma_fence_array to the chain.
Well as far as I can see this won't work because it would break the semantics of the timeline sync.
I'm not 100% convinced it has to. We already have support for the seqno regressing and we ensure that we still wait for all the fences. I thought maybe we could use that but I haven't spent enough time looking at the details to be sure. I may be missing something.
But I think I know a different way which should work: A dma_fence_chain can still contain a dma_fence_array, only the other way around is forbidden. Then we create the cursor functionality in such a way that it allows us to deep dive into the data structure and return all containing fences one by one.
Agreed. As long as one container is able to consume the other, it's fine.
I can prototype that if you want, shouldn't be more than a few hours of hacking anyway.
If you'd like to, go for it. I'd be happy to give it a go as well but if you already know what you want, it may be easier for you to just write the patch for the cursor.
Two more questions:
1. Do you want this collapsing to happen every time we create a dma_fence_array or should it be a special entrypoint? Collapsing all the time likely means doing extra array calculations instead of the dma_fence_array taking ownership of the array that's passed in. My gut says that cost is ok; but my gut doesn't spend much time in kernel space.
2. When we do the collapsing, should we call dma_fence_is_signaled() to avoid adding signaled fences to the array? It seems like avoiding adding references to fences that are already signaled would let the kernel clean them up faster and reduce the likelihood that a fence will hang around forever because it keeps getting added to arrays with other unsignaled fences.
--Jason
Am 05.03.20 um 16:54 schrieb Jason Ekstrand:
On Thu, Mar 5, 2020 at 7:06 AM Christian König christian.koenig@amd.com wrote:
[SNIP] Well as far as I can see this won't work because it would break the semantics of the timeline sync.
I'm not 100% convinced it has to. We already have support for the seqno regressing and we ensure that we still wait for all the fences. I thought maybe we could use that but I haven't spent enough time looking at the details to be sure. I may be missing something.
That won't work. The seqno regression works by punishing userspace for doing something stupid and undefined.
Be we can't do that under normal circumstances.
I can prototype that if you want, shouldn't be more than a few hours of hacking anyway.
If you'd like to, go for it. I'd be happy to give it a go as well but if you already know what you want, it may be easier for you to just write the patch for the cursor.
Send you two patches for that a few minutes ago. But keep in mind that those are completely untested.
Two more questions:
- Do you want this collapsing to happen every time we create a
dma_fence_array or should it be a special entrypoint? Collapsing all the time likely means doing extra array calculations instead of the dma_fence_array taking ownership of the array that's passed in. My gut says that cost is ok; but my gut doesn't spend much time in kernel space.
In my prototype implementation that is a dma_resv function you call and get either a single fence or a dma_fence_array with the collapsed fences in return.
But I wouldn't add that to the general dma_fence_array_init function since this is still a rather special case. Well see the patches, they should be pretty self explaining.
- When we do the collapsing, should we call dma_fence_is_signaled()
to avoid adding signaled fences to the array? It seems like avoiding adding references to fences that are already signaled would let the kernel clean them up faster and reduce the likelihood that a fence will hang around forever because it keeps getting added to arrays with other unsignaled fences.
I think so. Can't think of a good reason why we would want to add already signaled fences to the array.
Christian.
--Jason
On Mon, Mar 9, 2020 at 11:21 AM Christian König christian.koenig@amd.com wrote:
Am 05.03.20 um 16:54 schrieb Jason Ekstrand:
On Thu, Mar 5, 2020 at 7:06 AM Christian König christian.koenig@amd.com wrote:
[SNIP] Well as far as I can see this won't work because it would break the semantics of the timeline sync.
I'm not 100% convinced it has to. We already have support for the seqno regressing and we ensure that we still wait for all the fences. I thought maybe we could use that but I haven't spent enough time looking at the details to be sure. I may be missing something.
That won't work. The seqno regression works by punishing userspace for doing something stupid and undefined.
Be we can't do that under normal circumstances.
I can prototype that if you want, shouldn't be more than a few hours of hacking anyway.
If you'd like to, go for it. I'd be happy to give it a go as well but if you already know what you want, it may be easier for you to just write the patch for the cursor.
Send you two patches for that a few minutes ago. But keep in mind that those are completely untested.
No worries. They were full of bugs but I think I've got them sorted out now. The v2's I'm about to send seem to work. I'm going to leave a Vulkan demo running all night long just to make sure I'm not leaking memory like mad.
--Jason
Two more questions:
- Do you want this collapsing to happen every time we create a
dma_fence_array or should it be a special entrypoint? Collapsing all the time likely means doing extra array calculations instead of the dma_fence_array taking ownership of the array that's passed in. My gut says that cost is ok; but my gut doesn't spend much time in kernel space.
In my prototype implementation that is a dma_resv function you call and get either a single fence or a dma_fence_array with the collapsed fences in return.
But I wouldn't add that to the general dma_fence_array_init function since this is still a rather special case. Well see the patches, they should be pretty self explaining.
- When we do the collapsing, should we call dma_fence_is_signaled()
to avoid adding signaled fences to the array? It seems like avoiding adding references to fences that are already signaled would let the kernel clean them up faster and reduce the likelihood that a fence will hang around forever because it keeps getting added to arrays with other unsignaled fences.
I think so. Can't think of a good reason why we would want to add already signaled fences to the array.
Christian.
--Jason
linaro-mm-sig@lists.linaro.org
-
Christian König -
Jason Ekstrand