- Linaro-mm-sig - lists.linaro.org

Re: [Linaro-mm-sig] [PATCH] dma-fence: Document recoverable page fault implications

by Daniel Vetter

On Wed, Feb 24, 2021 at 12:22 PM Thomas Hellström (Intel) <thomas_os(a)shipmail.org> wrote: > > > On 2/24/21 10:26 AM, Daniel Vetter wrote: > > On Wed, Feb 24, 2021 at 9:47 AM Thomas Hellström (Intel) > > <thomas_os(a)shipmail.org> wrote: > >> > >> On 2/3/21 4:29 PM, Daniel Vetter wrote: > >>> Recently there was a fairly long thread about recoreable hardware page > >>> faults, how they can deadlock, and what to do about that. > >>> > >>> While the discussion is still fresh I figured good time to try and > >>> document the conclusions a bit. This documentation section explains > >>> what's the potential problem, and the remedies we've discussed, > >>> roughly ordered from best to worst. > >>> > >>> v2: Linus -> Linux typoe (Dave) > >>> > >>> v3: > >>> - Make it clear drivers only need to implement one option (Christian) > >>> - Make it clearer that implicit sync is out the window with exclusive > >>> fences (Christian) > >>> - Add the fairly theoretical option of segementing the memory (either > >>> statically or through dynamic checks at runtime for which piece of > >>> memory is managed how) and explain why it's not a great idea (Felix) > >>> > >>> References: https://lore.kernel.org/dri-devel/20210107030127.20393-1-Felix.Kuehling@amd… > >>> Cc: Dave Airlie <airlied(a)gmail.com> > >>> Cc: Maarten Lankhorst <maarten.lankhorst(a)linux.intel.com> > >>> Cc: Thomas Hellström <thomas.hellstrom(a)intel.com> > >>> Cc: "Christian König" <christian.koenig(a)amd.com> > >>> Cc: Jerome Glisse <jglisse(a)redhat.com> > >>> Cc: Felix Kuehling <felix.kuehling(a)amd.com> > >>> Signed-off-by: Daniel Vetter <daniel.vetter(a)intel.com> > >>> Cc: Sumit Semwal <sumit.semwal(a)linaro.org> > >>> Cc: linux-media(a)vger.kernel.org > >>> Cc: linaro-mm-sig(a)lists.linaro.org > >>> --- > >>> Documentation/driver-api/dma-buf.rst | 76 ++++++++++++++++++++++++++++ > >>> 1 file changed, 76 insertions(+) > >>> > >>> diff --git a/Documentation/driver-api/dma-buf.rst b/Documentation/driver-api/dma-buf.rst > >>> index a2133d69872c..7f37ec30d9fd 100644 > >>> --- a/Documentation/driver-api/dma-buf.rst > >>> +++ b/Documentation/driver-api/dma-buf.rst > >>> @@ -257,3 +257,79 @@ fences in the kernel. This means: > >>> userspace is allowed to use userspace fencing or long running compute > >>> workloads. This also means no implicit fencing for shared buffers in these > >>> cases. > >>> + > >>> +Recoverable Hardware Page Faults Implications > >>> +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > >>> + > >>> +Modern hardware supports recoverable page faults, which has a lot of > >>> +implications for DMA fences. > >>> + > >>> +First, a pending page fault obviously holds up the work that's running on the > >>> +accelerator and a memory allocation is usually required to resolve the fault. > >>> +But memory allocations are not allowed to gate completion of DMA fences, which > >>> +means any workload using recoverable page faults cannot use DMA fences for > >>> +synchronization. Synchronization fences controlled by userspace must be used > >>> +instead. > >>> + > >>> +On GPUs this poses a problem, because current desktop compositor protocols on > >>> +Linux rely on DMA fences, which means without an entirely new userspace stack > >>> +built on top of userspace fences, they cannot benefit from recoverable page > >>> +faults. Specifically this means implicit synchronization will not be possible. > >>> +The exception is when page faults are only used as migration hints and never to > >>> +on-demand fill a memory request. For now this means recoverable page > >>> +faults on GPUs are limited to pure compute workloads. > >>> + > >>> +Furthermore GPUs usually have shared resources between the 3D rendering and > >>> +compute side, like compute units or command submission engines. If both a 3D > >>> +job with a DMA fence and a compute workload using recoverable page faults are > >>> +pending they could deadlock: > >>> + > >>> +- The 3D workload might need to wait for the compute job to finish and release > >>> + hardware resources first. > >>> + > >>> +- The compute workload might be stuck in a page fault, because the memory > >>> + allocation is waiting for the DMA fence of the 3D workload to complete. > >>> + > >>> +There are a few options to prevent this problem, one of which drivers need to > >>> +ensure: > >>> + > >>> +- Compute workloads can always be preempted, even when a page fault is pending > >>> + and not yet repaired. Not all hardware supports this. > >>> + > >>> +- DMA fence workloads and workloads which need page fault handling have > >>> + independent hardware resources to guarantee forward progress. This could be > >>> + achieved through e.g. through dedicated engines and minimal compute unit > >>> + reservations for DMA fence workloads. > >>> + > >>> +- The reservation approach could be further refined by only reserving the > >>> + hardware resources for DMA fence workloads when they are in-flight. This must > >>> + cover the time from when the DMA fence is visible to other threads up to > >>> + moment when fence is completed through dma_fence_signal(). > >>> + > >>> +- As a last resort, if the hardware provides no useful reservation mechanics, > >>> + all workloads must be flushed from the GPU when switching between jobs > >>> + requiring DMA fences or jobs requiring page fault handling: This means all DMA > >>> + fences must complete before a compute job with page fault handling can be > >>> + inserted into the scheduler queue. And vice versa, before a DMA fence can be > >>> + made visible anywhere in the system, all compute workloads must be preempted > >>> + to guarantee all pending GPU page faults are flushed. > >>> + > >>> +- Only a fairly theoretical option would be to untangle these dependencies when > >>> + allocating memory to repair hardware page faults, either through separate > >>> + memory blocks or runtime tracking of the full dependency graph of all DMA > >>> + fences. This results very wide impact on the kernel, since resolving the page > >>> + on the CPU side can itself involve a page fault. It is much more feasible and > >>> + robust to limit the impact of handling hardware page faults to the specific > >>> + driver. > >>> + > >>> +Note that workloads that run on independent hardware like copy engines or other > >>> +GPUs do not have any impact. This allows us to keep using DMA fences internally > >>> +in the kernel even for resolving hardware page faults, e.g. by using copy > >>> +engines to clear or copy memory needed to resolve the page fault. > >>> + > >>> +In some ways this page fault problem is a special case of the `Infinite DMA > >>> +Fences` discussions: Infinite fences from compute workloads are allowed to > >>> +depend on DMA fences, but not the other way around. And not even the page fault > >>> +problem is new, because some other CPU thread in userspace might > >>> +hit a page fault which holds up a userspace fence - supporting page faults on > >>> +GPUs doesn't anything fundamentally new. > >> To me, in general this looks good. One thing, though is that for a first > >> time reader it might not be totally clear what's special with a compute > >> workload. Perhaps some clarification? > > In the docs this new section is right after the infinite fence > > section, which goes through this kind of stuff. So it's not so much > > "compute workloads" but "infinite fences", which I think is explained > > plenty enough. > > > OK, > >> Also since the current cross-driver dma_fence locking order is > >> > >> 1) dma_resv -> > >> 2) memory_allocation / reclaim -> > >> 3) dma_fence_wait/critical > >> > >> And the locking order required for recoverable pagefault is > >> > >> a) dma_resv -> > >> b) fence_wait/critical -> > >> c) memory_allocation / reclaim > >> > >> (Possibly with a) and b) interchanged above, Is it possible to service a > >> recoverable pagefault without taking the dma_resv lock?) > > It's worse, since the lock order we care about is: > > 1) mmap_sem > > 2) dma_resv > > 3) reclaim > > 4) dma_fence_wait > > > > And for this nice brave new world of unified shared memory/hmm, we > > really need to be able to resolve arbitrary cpu side page faults (with > > fixup_user_fault() like the iommu driver does too for PASID mode) to > > be able to serve gpu page faults. So even if we take dma_resv > > completely out of the system we still have: > > > > 1) mmap_sem > > 2) reclaim > > 3) dma_fence_wait > > > > So we'd also need to throw out dma_fence_wait, and at that point we're > > looking at a new gpu driver stack. > > > Meaning that the locking order for workloads with recoverable page > faults becomes: > > a) dma_fence_wait/critical > b) mmap_sem > c) dma_resv > d) reclaim > > which I agree we can't really use with the current stack whatever we do > with dma_fence_wait vs reclaim. > > > >> It's clear that the fence critical section in b) is not compatible with > >> the dma_fence wait in 3) and thus the memory restrictions are needed. > >> But I think given the memory allocation restrictions for recoverable > >> pagefaults I guess at some point we must ask ourselves why are they > >> necessary and what's the price to be paid for getting rid of them, and > >> document also that. *If* it's the case that it all boils down to the 2) > >> -> 3) locking order above, and that's mandated *only* by the dma_fence > >> wait in the userptr mmu notifiers, I think these restrictions are a > >> pretty high price to pay. Wouldn't it be possible now to replace that > >> fence wait with either page pinning (which now is coherent since 5.9) or > >> preempt-ctx fences + unpinned pages if available and thus invert the 2) > >> -> 3) locking order? > > It's not just userptr, it's also shrinkers. mmap_sem requires > > GFP_KERNEL allocations, so that already excludes our shrinkers if we > > want this. That means gpu memory becomes pinned when it's managed with > > dma_fence. Christian König just reworked ttm to stop doing that, to > > remove the hard and fairly arbitrary "max 50% of system memory" limit. > > Even with shrinkers, and assuming there is no guarantee we can preempt, > one could tag memory / bos for release on next reservation / dma_fence > signal whatever happens first, which would not give memory back on > direct reclaim, but will eventually release it. Will not help with the > mmap_sem issue, though. > > > > > > > > Note that just preempt-ctx fences alone isn't enough, since you could > > end up with something like this: > > - compute workload using gpu page faults hangs a all of the > > compute/shadercores on page faults, we can't preempt > > - concurrently there's a 3d workload running, which because fixed > > function, and only preempt between draw calls. it is stuck waiting for > > some shader cores to become avaiable. this is possible because most > > gpus nowadays have separate command queues for compute/3d workloads > > - our kernel page fault handler for the compute job wants to preempt > > the 3d workload, which wont happen > > - everyone is firmly stuck and the user gets angry > Yes, preempt-ctx fences would indeed have to be guaranteed to be able to > preempt to work, using one of the options described above, But in > general, inverting reclaim and dma_fence_wait would actually resolve > this particular situation, even if it doesn't help with recoverable > pagefaults due to mmap_sem: > > - kernel page fault handler ends up in shrinker tagging 3D workload > resources for release > - Moves on to another shrinker that succeeds to release enough memory > - Compute workload proceeds > - 3D workload proceeds. > > ..But just wanting to get the full picture of what the tradeoffs of this > really are. The trouble with this is that we still need to guarantee forward progress. That means we must have enough memory available in other shrinkers/page-cache which is not hogged by the gpu in any way. E.g. just removing the dma_fence_wait from the mmu notifier wont help if we still hold the page refcounts at large. There's roughly two options: - Lots of local caches for memory allocations which are sized to contain the max in-flight working set. This is essentially what the block layer uses for GFP_NOIO inversions. Problem is you must guarantee that everyone goes through these mempools, and that they're actually sized for the worst case. Since we're talking about fixing up userspace page faults that's pretty much the entire kernel which needs to be switched over to accurate memory reservation and accounting. - Other option is what essentially shrinkers/filesystems do with GFP_NOFS: You hard-limit them to something that's small enough overall and make sure you still have enough other memory (like normal page cache, which can be evicted with GFP_NOFS generally) to guarantee forward progress. Since shrinkers keep looping even when there's fairly minimal forward progress you should be able to get out of things again. Problem for us is that we don't just have shrinkers, but also love to consume arbitrary pagecache with get_user_pages/userptr, so this is tricky to guarantee. The big hammer approach here what ttm has done thus far with a hard limit to 50% and a best-effort kthread that tries to balance things in the background, outside of reclaim. The other problem I'm seeing is that core kernel is building ever more features on top of page migration, and there's a fairly constant flow of work to get to a point where page migration can be guaranteed. Stuff like get_user_pages vs. pin_user_pages, recent work (I think not yet merged) to move pages out of ZONE_MOVEABLE if their pinned. This is because hugepages have become rather critical for performance, and contiguous memory allocator really has to guarantee it can find its large blocks (I think there's people looking into using CMA for giant pages, since you're not going to ever get 1gb pages out of the buddy allocator). GPUs hogging arbitrary amounts of these pages through userptr, without being able to release them in a timely manner, does not look like a design with a bright future. But yeah if we could just wish away the dma_fence_wait from reclaim context, all these problems would go away. -Daniel > /Thomas > > > > So just requiring that everything uses preempt-ctx fences isn't enough > > due to shared resources possible blocking preemption even across > > engines. Plus we'd still have the problem that dma_fence_wait from > > reclaim isn't allowed, pinning all the 3d workload memory for good. > > > > Aside: This means that for compute workloads using page faults we > > cannot use preempt-ctx fences either, but instead memory reclaim has > > to exclusively use pte zapping (both shrinker and mmu notifier). > > > > Cheers, Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch

4 years, 9 months

1
0
0 0

Re: [Linaro-mm-sig] [PATCH] dma-fence: Document recoverable page fault implications

by Daniel Vetter

On Wed, Feb 24, 2021 at 9:47 AM Thomas Hellström (Intel) <thomas_os(a)shipmail.org> wrote: > > > On 2/3/21 4:29 PM, Daniel Vetter wrote: > > Recently there was a fairly long thread about recoreable hardware page > > faults, how they can deadlock, and what to do about that. > > > > While the discussion is still fresh I figured good time to try and > > document the conclusions a bit. This documentation section explains > > what's the potential problem, and the remedies we've discussed, > > roughly ordered from best to worst. > > > > v2: Linus -> Linux typoe (Dave) > > > > v3: > > - Make it clear drivers only need to implement one option (Christian) > > - Make it clearer that implicit sync is out the window with exclusive > > fences (Christian) > > - Add the fairly theoretical option of segementing the memory (either > > statically or through dynamic checks at runtime for which piece of > > memory is managed how) and explain why it's not a great idea (Felix) > > > > References: https://lore.kernel.org/dri-devel/20210107030127.20393-1-Felix.Kuehling@amd… > > Cc: Dave Airlie <airlied(a)gmail.com> > > Cc: Maarten Lankhorst <maarten.lankhorst(a)linux.intel.com> > > Cc: Thomas Hellström <thomas.hellstrom(a)intel.com> > > Cc: "Christian König" <christian.koenig(a)amd.com> > > Cc: Jerome Glisse <jglisse(a)redhat.com> > > Cc: Felix Kuehling <felix.kuehling(a)amd.com> > > Signed-off-by: Daniel Vetter <daniel.vetter(a)intel.com> > > Cc: Sumit Semwal <sumit.semwal(a)linaro.org> > > Cc: linux-media(a)vger.kernel.org > > Cc: linaro-mm-sig(a)lists.linaro.org > > --- > > Documentation/driver-api/dma-buf.rst | 76 ++++++++++++++++++++++++++++ > > 1 file changed, 76 insertions(+) > > > > diff --git a/Documentation/driver-api/dma-buf.rst b/Documentation/driver-api/dma-buf.rst > > index a2133d69872c..7f37ec30d9fd 100644 > > --- a/Documentation/driver-api/dma-buf.rst > > +++ b/Documentation/driver-api/dma-buf.rst > > @@ -257,3 +257,79 @@ fences in the kernel. This means: > > userspace is allowed to use userspace fencing or long running compute > > workloads. This also means no implicit fencing for shared buffers in these > > cases. > > + > > +Recoverable Hardware Page Faults Implications > > +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > > + > > +Modern hardware supports recoverable page faults, which has a lot of > > +implications for DMA fences. > > + > > +First, a pending page fault obviously holds up the work that's running on the > > +accelerator and a memory allocation is usually required to resolve the fault. > > +But memory allocations are not allowed to gate completion of DMA fences, which > > +means any workload using recoverable page faults cannot use DMA fences for > > +synchronization. Synchronization fences controlled by userspace must be used > > +instead. > > + > > +On GPUs this poses a problem, because current desktop compositor protocols on > > +Linux rely on DMA fences, which means without an entirely new userspace stack > > +built on top of userspace fences, they cannot benefit from recoverable page > > +faults. Specifically this means implicit synchronization will not be possible. > > +The exception is when page faults are only used as migration hints and never to > > +on-demand fill a memory request. For now this means recoverable page > > +faults on GPUs are limited to pure compute workloads. > > + > > +Furthermore GPUs usually have shared resources between the 3D rendering and > > +compute side, like compute units or command submission engines. If both a 3D > > +job with a DMA fence and a compute workload using recoverable page faults are > > +pending they could deadlock: > > + > > +- The 3D workload might need to wait for the compute job to finish and release > > + hardware resources first. > > + > > +- The compute workload might be stuck in a page fault, because the memory > > + allocation is waiting for the DMA fence of the 3D workload to complete. > > + > > +There are a few options to prevent this problem, one of which drivers need to > > +ensure: > > + > > +- Compute workloads can always be preempted, even when a page fault is pending > > + and not yet repaired. Not all hardware supports this. > > + > > +- DMA fence workloads and workloads which need page fault handling have > > + independent hardware resources to guarantee forward progress. This could be > > + achieved through e.g. through dedicated engines and minimal compute unit > > + reservations for DMA fence workloads. > > + > > +- The reservation approach could be further refined by only reserving the > > + hardware resources for DMA fence workloads when they are in-flight. This must > > + cover the time from when the DMA fence is visible to other threads up to > > + moment when fence is completed through dma_fence_signal(). > > + > > +- As a last resort, if the hardware provides no useful reservation mechanics, > > + all workloads must be flushed from the GPU when switching between jobs > > + requiring DMA fences or jobs requiring page fault handling: This means all DMA > > + fences must complete before a compute job with page fault handling can be > > + inserted into the scheduler queue. And vice versa, before a DMA fence can be > > + made visible anywhere in the system, all compute workloads must be preempted > > + to guarantee all pending GPU page faults are flushed. > > + > > +- Only a fairly theoretical option would be to untangle these dependencies when > > + allocating memory to repair hardware page faults, either through separate > > + memory blocks or runtime tracking of the full dependency graph of all DMA > > + fences. This results very wide impact on the kernel, since resolving the page > > + on the CPU side can itself involve a page fault. It is much more feasible and > > + robust to limit the impact of handling hardware page faults to the specific > > + driver. > > + > > +Note that workloads that run on independent hardware like copy engines or other > > +GPUs do not have any impact. This allows us to keep using DMA fences internally > > +in the kernel even for resolving hardware page faults, e.g. by using copy > > +engines to clear or copy memory needed to resolve the page fault. > > + > > +In some ways this page fault problem is a special case of the `Infinite DMA > > +Fences` discussions: Infinite fences from compute workloads are allowed to > > +depend on DMA fences, but not the other way around. And not even the page fault > > +problem is new, because some other CPU thread in userspace might > > +hit a page fault which holds up a userspace fence - supporting page faults on > > +GPUs doesn't anything fundamentally new. > > To me, in general this looks good. One thing, though is that for a first > time reader it might not be totally clear what's special with a compute > workload. Perhaps some clarification? In the docs this new section is right after the infinite fence section, which goes through this kind of stuff. So it's not so much "compute workloads" but "infinite fences", which I think is explained plenty enough. > Also since the current cross-driver dma_fence locking order is > > 1) dma_resv -> > 2) memory_allocation / reclaim -> > 3) dma_fence_wait/critical > > And the locking order required for recoverable pagefault is > > a) dma_resv -> > b) fence_wait/critical -> > c) memory_allocation / reclaim > > (Possibly with a) and b) interchanged above, Is it possible to service a > recoverable pagefault without taking the dma_resv lock?) It's worse, since the lock order we care about is: 1) mmap_sem 2) dma_resv 3) reclaim 4) dma_fence_wait And for this nice brave new world of unified shared memory/hmm, we really need to be able to resolve arbitrary cpu side page faults (with fixup_user_fault() like the iommu driver does too for PASID mode) to be able to serve gpu page faults. So even if we take dma_resv completely out of the system we still have: 1) mmap_sem 2) reclaim 3) dma_fence_wait So we'd also need to throw out dma_fence_wait, and at that point we're looking at a new gpu driver stack. > It's clear that the fence critical section in b) is not compatible with > the dma_fence wait in 3) and thus the memory restrictions are needed. > But I think given the memory allocation restrictions for recoverable > pagefaults I guess at some point we must ask ourselves why are they > necessary and what's the price to be paid for getting rid of them, and > document also that. *If* it's the case that it all boils down to the 2) > -> 3) locking order above, and that's mandated *only* by the dma_fence > wait in the userptr mmu notifiers, I think these restrictions are a > pretty high price to pay. Wouldn't it be possible now to replace that > fence wait with either page pinning (which now is coherent since 5.9) or > preempt-ctx fences + unpinned pages if available and thus invert the 2) > -> 3) locking order? It's not just userptr, it's also shrinkers. mmap_sem requires GFP_KERNEL allocations, so that already excludes our shrinkers if we want this. That means gpu memory becomes pinned when it's managed with dma_fence. Christian König just reworked ttm to stop doing that, to remove the hard and fairly arbitrary "max 50% of system memory" limit. The only option that would work is if we throw out dma_fence out and exclusively manage memory with gpu page faults only. Even across the gpus that do support page faults that's not true for all workloads, e.g. nvidia only supports page faults on compute engines, not on any of the 3d fixed function stuff or media codecs (to my knowledge). So not going to happen. In addition, this plan requires that we stop using dma_fence for sync (otherwise you can't use preempt-ctx fences). That's the "10 year plan to rev the ecosystem" problem, although with lots of discussions with Christian and Jason from mesa I think we've boiled this down to a more minimal task list by now: - vk driver mode that users userspace fences. There's a somewhat nasty problem here because you can only decide which mode to use when you know which winsys to use. And with vk that's created after the render pipeline (unlike gl). Plus it's dynamic, e.g. if you run on X or wayland without the below stuff support, but then use direct display and the kernel already has timeline syncobj support, you should probably use userspace fencing. - new wayland/x protocol to pass timeline drm_syncob around as syncobj - drm_syncobj support in atomic ioctl - compositors switching over to vk + using timeline syncobj for fencing - new drm_syncobj mode where we wrap a userspace fence: new userspace would pull the userspace fence out, any legacy drivers would have to block until the fence has signalled. This sucks compared to current timeline syncobj, where we just wait for the dma_fence to materialize, but since it can use the same paths/ioctls it would at least give us a smooth upgrade path. Inclusive allowing both old and new userspace to co-exist on the same compositor session. Note that just preempt-ctx fences alone isn't enough, since you could end up with something like this: - compute workload using gpu page faults hangs a all of the compute/shadercores on page faults, we can't preempt - concurrently there's a 3d workload running, which because fixed function, and only preempt between draw calls. it is stuck waiting for some shader cores to become avaiable. this is possible because most gpus nowadays have separate command queues for compute/3d workloads - our kernel page fault handler for the compute job wants to preempt the 3d workload, which wont happen - everyone is firmly stuck and the user gets angry So just requiring that everything uses preempt-ctx fences isn't enough due to shared resources possible blocking preemption even across engines. Plus we'd still have the problem that dma_fence_wait from reclaim isn't allowed, pinning all the 3d workload memory for good. Aside: This means that for compute workloads using page faults we cannot use preempt-ctx fences either, but instead memory reclaim has to exclusively use pte zapping (both shrinker and mmu notifier). Cheers, Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch

4 years, 9 months

1
0
0 0

Re: [Linaro-mm-sig] [PATCH] drm/ttm/ttm_bo: make ttm_bo_glob_use_count static

by Christian König

Am 23.02.21 um 09:54 schrieb Jiapeng Chong: > Fix the following sparse warning: > > drivers/gpu/drm/ttm/ttm_bo.c:53:10: warning: symbol > 'ttm_bo_glob_use_count' was not declared. Should it be static? IIRC we already have a patch for this on the mailing list and the mutex can be static as well. Christian. > > Reported-by: Abaci Robot <abaci(a)linux.alibaba.com> > Signed-off-by: Jiapeng Chong <jiapeng.chong(a)linux.alibaba.com> > --- > drivers/gpu/drm/ttm/ttm_bo.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c > index b65f4b1..107dd13 100644 > --- a/drivers/gpu/drm/ttm/ttm_bo.c > +++ b/drivers/gpu/drm/ttm/ttm_bo.c > @@ -50,7 +50,7 @@ > * ttm_global_mutex - protecting the global BO state > */ > DEFINE_MUTEX(ttm_global_mutex); > -unsigned ttm_bo_glob_use_count; > +static unsigned ttm_bo_glob_use_count; > struct ttm_bo_global ttm_bo_glob; > EXPORT_SYMBOL(ttm_bo_glob); >

4 years, 9 months

1
0
0 0

Re: [Linaro-mm-sig] [PATCH] drm/amdgpu/sdma5.2: Remove unnecessary conversion to bool

by Alex Deucher

Applied. Thanks! Alex On Sat, Feb 20, 2021 at 3:35 AM Jiapeng Chong <jiapeng.chong(a)linux.alibaba.com> wrote: > > Fix the following coccicheck warnings: > > ./drivers/gpu/drm/amd/amdgpu/sdma_v5_2.c:1621:40-45: WARNING: conversion > to bool not needed here. > > ./drivers/gpu/drm/amd/amdgpu/sdma_v5_2.c:1619:40-45: WARNING: conversion > to bool not needed here. > > Reported-by: Abaci Robot <abaci(a)linux.alibaba.com> > Signed-off-by: Jiapeng Chong <jiapeng.chong(a)linux.alibaba.com> > --- > drivers/gpu/drm/amd/amdgpu/sdma_v5_2.c | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/drivers/gpu/drm/amd/amdgpu/sdma_v5_2.c b/drivers/gpu/drm/amd/amdgpu/sdma_v5_2.c > index f1ba36a..9ed79a9 100644 > --- a/drivers/gpu/drm/amd/amdgpu/sdma_v5_2.c > +++ b/drivers/gpu/drm/amd/amdgpu/sdma_v5_2.c > @@ -1616,9 +1616,9 @@ static int sdma_v5_2_set_clockgating_state(void *handle, > case CHIP_VANGOGH: > case CHIP_DIMGREY_CAVEFISH: > sdma_v5_2_update_medium_grain_clock_gating(adev, > - state == AMD_CG_STATE_GATE ? true : false); > + state == AMD_CG_STATE_GATE); > sdma_v5_2_update_medium_grain_light_sleep(adev, > - state == AMD_CG_STATE_GATE ? true : false); > + state == AMD_CG_STATE_GATE); > break; > default: > break; > -- > 1.8.3.1 > > _______________________________________________ > dri-devel mailing list > dri-devel(a)lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/dri-devel

4 years, 9 months

1
0
0 0

Re: [Linaro-mm-sig] [PATCH v2 0/3] drm/prime: Only call dma_map_sgtable() for devices with DMA support

by Daniel Vetter

On Mon, Feb 22, 2021 at 05:25:46PM +0100, Thomas Zimmermann wrote: > Hi > > Am 22.02.21 um 17:10 schrieb Daniel Vetter: > > On Mon, Feb 22, 2021 at 2:24 PM Thomas Zimmermann <tzimmermann(a)suse.de> wrote: > > > > > > Hi > > > > > > Am 22.02.21 um 14:09 schrieb Christian König: > > > > > > > > > > > > Am 22.02.21 um 13:43 schrieb Thomas Zimmermann: > > > > > USB-based drivers cannot use DMA, so the importing of dma-buf attachments > > > > > currently fails for udl and gm12u320. This breaks joining/mirroring of > > > > > displays. > > > > > > > > > > The fix is now a little series. To solve the issue on the importer > > > > > side (i.e., the affected USB-based driver), patch 1 introduces a new > > > > > PRIME callback, struct drm_driver.gem_prime_create_object, which creates > > > > > an object and gives more control to the importing driver. Specifically, > > > > > udl and gm12u320 can now avoid the creation of a scatter/gather table > > > > > for the imported pages. Patch 1 is self-contained in the sense that it > > > > > can be backported into older kernels. > > > > > > > > Mhm, that sounds like a little overkill to me. > > > > > > > > Drivers can already import the DMA-bufs all by them selves without the > > > > help of the DRM functions. See amdgpu for an example. > > > > > > > > Daniel also already noted to me that he sees the DRM helper as a bit > > > > questionable middle layer. > > > > > > And this bug proves that it is. :) > > > > The trouble here is actually gem_bo->import_attach, which isn't really > > part of the questionable midlayer, but fairly mandatory (only > > exception is vmwgfx because not using gem) caching to make sure we > > don't end up with duped imports and fun stuff like that. > > > > And dma_buf_attach now implicitly creates the sg table already, so > > we're already in game over land. I think we'd need to make > > import_attach a union with import_buf or something like that, so that > > you can do attachment-less importing. > > Creating the sg table is not the problem; mapping it is. So dma_buf_attach > shouldn't be a problem. dma_buf_attach will create a cached sg-mapping for you if the exporter is dynamic. Currently that's only the case for amdgpu, I guess you didn't test with that. So yeah dma_buf_attach is a problem already. And if we can't attach, the entire obj->import_attach logic in drm_prime.c falls over, and we get all kinds of fun with double import and re-export. > > > > Have you thought about doing that instead? > > > > > > There appears to be some useful code in drm_gem_prime_import_dev(). But > > > if the general sentiment goes towards removing > > > gem_prime_import_sg_table, we can work towards that as well. > > > > I still think this part is a bit a silly midlayer for no good reason, > > but I think that's orthogonal to the issue at hand here. > > > > I'd suggest we first try to paper over the issue by using > > prime_import_dev with the host controller (which hopefully is > > dma-capable for most systems). And then, at leisure, try to untangle > > the obj->import_attach issue. > > I really don't want to do this. My time is also limited, and I''ll spend > time papering over the thing. And then more time for the real fix. I'd > rather pull drm_gem_prime_import_dev() in to USB drivers and avoid the > dma_buf_map(). Yeah I understand, it's just (as usual :-/) more complex than it seems ... -Daniel > > Best regard > Thomas > > > -Daniel > > > > > > > > Best regards > > > Thomas > > > > > > > > > > > Christian. > > > > > > > > > > > > > > Patches 2 and 3 update SHMEM and CMA helpers to use the new callback. > > > > > Effectively this moves the sg table setup from the PRIME helpers into > > > > > the memory managers. SHMEM now supports devices without DMA support, > > > > > so custom code can be removed from udl and g12u320. > > > > > > > > > > Tested by joining/mirroring displays of udl and radeon under Gnome/X11. > > > > > > > > > > v2: > > > > > * move fix to importer side (Christian, Daniel) > > > > > * update SHMEM and CMA helpers for new PRIME callbacks > > > > > > > > > > Thomas Zimmermann (3): > > > > > drm: Support importing dmabufs into drivers without DMA > > > > > drm/shmem-helper: Implement struct drm_driver.gem_prime_create_object > > > > > drm/cma-helper: Implement struct drm_driver.gem_prime_create_object > > > > > > > > > > drivers/gpu/drm/drm_gem_cma_helper.c | 62 ++++++++++++++----------- > > > > > drivers/gpu/drm/drm_gem_shmem_helper.c | 38 ++++++++++----- > > > > > drivers/gpu/drm/drm_prime.c | 43 +++++++++++------ > > > > > drivers/gpu/drm/lima/lima_drv.c | 2 +- > > > > > drivers/gpu/drm/panfrost/panfrost_drv.c | 2 +- > > > > > drivers/gpu/drm/panfrost/panfrost_gem.c | 6 +-- > > > > > drivers/gpu/drm/panfrost/panfrost_gem.h | 4 +- > > > > > drivers/gpu/drm/pl111/pl111_drv.c | 8 ++-- > > > > > drivers/gpu/drm/v3d/v3d_bo.c | 6 +-- > > > > > drivers/gpu/drm/v3d/v3d_drv.c | 2 +- > > > > > drivers/gpu/drm/v3d/v3d_drv.h | 5 +- > > > > > include/drm/drm_drv.h | 12 +++++ > > > > > include/drm/drm_gem_cma_helper.h | 12 ++--- > > > > > include/drm/drm_gem_shmem_helper.h | 6 +-- > > > > > 14 files changed, 120 insertions(+), 88 deletions(-) > > > > > > > > > > -- > > > > > 2.30.1 > > > > > > > > > > > > > > > -- > > > Thomas Zimmermann > > > Graphics Driver Developer > > > SUSE Software Solutions Germany GmbH > > > Maxfeldstr. 5, 90409 Nürnberg, Germany > > > (HRB 36809, AG Nürnberg) > > > Geschäftsführer: Felix Imendörffer > > > > > > > > > -- > Thomas Zimmermann > Graphics Driver Developer > SUSE Software Solutions Germany GmbH > Maxfeldstr. 5, 90409 Nürnberg, Germany > (HRB 36809, AG Nürnberg) > Geschäftsführer: Felix Imendörffer > -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch

4 years, 9 months

1
0
0 0

Re: [Linaro-mm-sig] [PATCH v2 1/3] drm: Support importing dmabufs into drivers without DMA

by Daniel Vetter

On Mon, Feb 22, 2021 at 01:43:26PM +0100, Thomas Zimmermann wrote: > USB devices cannot perform DMA and hence have no dma_mask set in their > device structure. Importing dmabuf into a USB-based driver fails, which > break joining and mirroring of display in X11. A corresponding error > message is shown below. > > [ 60.050199] ------------[ cut here ]------------ > [ 60.055092] WARNING: CPU: 0 PID: 1403 at kernel/dma/mapping.c:190 dma_map_sg_attrs+0x8f/0xc0 > [ 60.064331] Modules linked in: af_packet(E) rfkill(E) dmi_sysfs(E) intel_rapl_msr(E) intel_rapl_common(E) snd_hda_codec_realtek(E) snd_hda_codec_generic(E) ledtrig_audio(E) snd_hda_codec_hdmi(E) x86_pkg_temp_thermal(E) intel_powerclam) > [ 60.064801] wmi(E) video(E) btrfs(E) blake2b_generic(E) libcrc32c(E) crc32c_intel(E) xor(E) raid6_pq(E) sg(E) dm_multipath(E) dm_mod(E) scsi_dh_rdac(E) scsi_dh_emc(E) scsi_dh_alua(E) msr(E) efivarfs(E) > [ 60.170778] CPU: 0 PID: 1403 Comm: Xorg.bin Tainted: G E 5.11.0-rc5-1-default+ #747 > [ 60.179841] Hardware name: Dell Inc. OptiPlex 9020/0N4YC8, BIOS A24 10/24/2018 > [ 60.187145] RIP: 0010:dma_map_sg_attrs+0x8f/0xc0 > [ 60.191822] Code: 4d 85 ff 75 2b 49 89 d8 44 89 e1 44 89 f2 4c 89 ee 48 89 ef e8 62 30 00 00 85 c0 78 36 5b 5d 41 5c 41 5d 41 5e 41 5f c3 0f 0b <0f> 0b 31 c0 eb ed 49 8d 7f 50 e8 72 f5 2a 00 49 8b 47 50 49 89 d8 > [ 60.210770] RSP: 0018:ffffc90001d6fc18 EFLAGS: 00010246 > [ 60.216062] RAX: 0000000000000000 RBX: 0000000000000020 RCX: ffffffffb31e677b > [ 60.223274] RDX: dffffc0000000000 RSI: ffff888212c10600 RDI: ffff8881b08a9488 > [ 60.230501] RBP: ffff8881b08a9030 R08: 0000000000000020 R09: ffff888212c10600 > [ 60.237710] R10: ffffed10425820df R11: 0000000000000001 R12: 0000000000000000 > [ 60.244939] R13: ffff888212c10600 R14: 0000000000000008 R15: 0000000000000000 > [ 60.252155] FS: 00007f08ac2b2f00(0000) GS:ffff8887cbe00000(0000) knlGS:0000000000000000 > [ 60.260333] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 > [ 60.266150] CR2: 000055831c899be8 CR3: 000000015372e006 CR4: 00000000001706f0 > [ 60.273369] Call Trace: > [ 60.275845] drm_gem_map_dma_buf+0xb4/0x120 > [ 60.280089] dma_buf_map_attachment+0x15d/0x1e0 > [ 60.284688] drm_gem_prime_import_dev.part.0+0x5d/0x140 > [ 60.289984] drm_gem_prime_fd_to_handle+0x213/0x280 > [ 60.294931] ? drm_prime_destroy_file_private+0x30/0x30 > [ 60.300224] drm_ioctl_kernel+0x131/0x180 > [ 60.304291] ? drm_setversion+0x230/0x230 > [ 60.308366] ? drm_prime_destroy_file_private+0x30/0x30 > [ 60.313659] drm_ioctl+0x2f1/0x500 > [ 60.317118] ? drm_version+0x150/0x150 > [ 60.320903] ? lock_downgrade+0xa0/0xa0 > [ 60.324806] ? do_vfs_ioctl+0x5f4/0x680 > [ 60.328694] ? __fget_files+0x13e/0x210 > [ 60.332591] ? ioctl_fiemap.isra.0+0x1a0/0x1a0 > [ 60.337102] ? __fget_files+0x15d/0x210 > [ 60.340990] __x64_sys_ioctl+0xb9/0xf0 > [ 60.344795] do_syscall_64+0x33/0x80 > [ 60.348427] entry_SYSCALL_64_after_hwframe+0x44/0xa9 > [ 60.353542] RIP: 0033:0x7f08ac7b53cb > [ 60.357168] Code: 89 d8 49 8d 3c 1c 48 f7 d8 49 39 c4 72 b5 e8 1c ff ff ff 85 c0 78 ba 4c 89 e0 5b 5d 41 5c c3 f3 0f 1e fa b8 10 00 00 00 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d 75 ba 0c 00 f7 d8 64 89 01 48 > [ 60.376108] RSP: 002b:00007ffeabc89fc8 EFLAGS: 00000246 ORIG_RAX: 0000000000000010 > [ 60.383758] RAX: ffffffffffffffda RBX: 00007ffeabc8a00c RCX: 00007f08ac7b53cb > [ 60.390970] RDX: 00007ffeabc8a00c RSI: 00000000c00c642e RDI: 000000000000000d > [ 60.398221] RBP: 00000000c00c642e R08: 000055831c691d00 R09: 000055831b2ec010 > [ 60.405446] R10: 00007f08acf6ada0 R11: 0000000000000246 R12: 000055831c691d00 > [ 60.412667] R13: 000000000000000d R14: 00000000007e9000 R15: 0000000000000000 > [ 60.419903] irq event stamp: 672893 > [ 60.423441] hardirqs last enabled at (672913): [<ffffffffb31b796d>] console_unlock+0x44d/0x500 > [ 60.432230] hardirqs last disabled at (672922): [<ffffffffb31b7963>] console_unlock+0x443/0x500 > [ 60.441021] softirqs last enabled at (672940): [<ffffffffb46003dd>] __do_softirq+0x3dd/0x554 > [ 60.449634] softirqs last disabled at (672931): [<ffffffffb44010f2>] asm_call_irq_on_stack+0x12/0x20 > [ 60.458871] ---[ end trace f2f88696eb17806c ]--- > > This patch introduces struct drm_driver.gem_prime_create_object, which > creates a GEM object during the import. Drivers should implement this > callback and handle DMA S/G table support by themselves. For USB-based > drivers, the patch adds an implementation without DMA-related code. > > The original interface struct drm_driver.gem_prime_import_sg_table > is deprecated. All drivers should switch over. > > Tested by joining/mirroring displays of udl and radeon un der Gnome/X11. > > Signed-off-by: Thomas Zimmermann <tzimmermann(a)suse.de> > Fixes: 6eb0233ec2d0 ("usb: don't inherity DMA properties for USB devices") > Cc: Christoph Hellwig <hch(a)lst.de> > Cc: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> > Cc: Alan Stern <stern(a)rowland.harvard.edu> > Cc: Johan Hovold <johan(a)kernel.org> > Cc: Andy Shevchenko <andriy.shevchenko(a)linux.intel.com> > Cc: Sebastian Andrzej Siewior <bigeasy(a)linutronix.de> > Cc: Mathias Nyman <mathias.nyman(a)linux.intel.com> > Cc: "Ahmed S. Darwish" <a.darwish(a)linutronix.de> > Cc: Oliver Neukum <oneukum(a)suse.com> > Cc: Thomas Gleixner <tglx(a)linutronix.de> > Cc: Felipe Balbi <balbi(a)kernel.org> > Cc: <stable(a)vger.kernel.org> # v5.10+ > --- > drivers/gpu/drm/drm_prime.c | 43 +++++++++++++++++++++------------ > drivers/gpu/drm/tiny/gm12u320.c | 7 ++++++ > drivers/gpu/drm/udl/udl_drv.c | 7 ++++++ > include/drm/drm_drv.h | 12 +++++++++ > 4 files changed, 54 insertions(+), 15 deletions(-) > > diff --git a/drivers/gpu/drm/drm_prime.c b/drivers/gpu/drm/drm_prime.c > index 2a54f86856af..9bb30e843a44 100644 > --- a/drivers/gpu/drm/drm_prime.c > +++ b/drivers/gpu/drm/drm_prime.c > @@ -923,7 +923,8 @@ struct drm_gem_object *drm_gem_prime_import_dev(struct drm_device *dev, > } > } > > - if (!dev->driver->gem_prime_import_sg_table) > + if (!dev->driver->gem_prime_import_sg_table && > + !dev->driver->gem_prime_create_object) > return ERR_PTR(-EINVAL); > > attach = dma_buf_attach(dma_buf, attach_dev); > @@ -932,25 +933,37 @@ struct drm_gem_object *drm_gem_prime_import_dev(struct drm_device *dev, > > get_dma_buf(dma_buf); > > - sgt = dma_buf_map_attachment(attach, DMA_BIDIRECTIONAL); > - if (IS_ERR(sgt)) { > - ret = PTR_ERR(sgt); > - goto fail_detach; > - } > + if (dev->driver->gem_prime_create_object) { > + obj = dev->driver->gem_prime_create_object(dev, attach); > + if (IS_ERR(obj)) { > + ret = PTR_ERR(obj); > + goto fail_detach; > + } > > - obj = dev->driver->gem_prime_import_sg_table(dev, attach, sgt); > - if (IS_ERR(obj)) { > - ret = PTR_ERR(obj); > - goto fail_unmap; > - } > + if (!obj->import_attach) > + obj->import_attach = attach; If you don't set import_attach then the refcounting and double-import prevention goes all kinds of wrong. So unfortunately it's not that easy. -Daniel > + if (!obj->resv) > + obj->resv = dma_buf->resv; > + } else { > + sgt = dma_buf_map_attachment(attach, DMA_BIDIRECTIONAL); > + if (IS_ERR(sgt)) { > + ret = PTR_ERR(sgt); > + goto fail_detach; > + } > > - obj->import_attach = attach; > - obj->resv = dma_buf->resv; > + obj = dev->driver->gem_prime_import_sg_table(dev, attach, sgt); > + if (IS_ERR(obj)) { > + ret = PTR_ERR(obj); > + dma_buf_unmap_attachment(attach, sgt, DMA_BIDIRECTIONAL); > + goto fail_detach; > + } > + > + obj->import_attach = attach; > + obj->resv = dma_buf->resv; > + } > > return obj; > > -fail_unmap: > - dma_buf_unmap_attachment(attach, sgt, DMA_BIDIRECTIONAL); > fail_detach: > dma_buf_detach(dma_buf, attach); > dma_buf_put(dma_buf); > diff --git a/drivers/gpu/drm/tiny/gm12u320.c b/drivers/gpu/drm/tiny/gm12u320.c > index 0b4f4f2af1ef..9f13a7c7c2da 100644 > --- a/drivers/gpu/drm/tiny/gm12u320.c > +++ b/drivers/gpu/drm/tiny/gm12u320.c > @@ -601,6 +601,12 @@ static const uint64_t gm12u320_pipe_modifiers[] = { > > DEFINE_DRM_GEM_FOPS(gm12u320_fops); > > +static struct drm_gem_object *gm12u320_gem_prime_create_object(struct drm_device *dev, > + struct dma_buf_attachment *attach) > +{ > + return drm_gem_shmem_prime_import_sg_table(dev, attach, NULL); > +} > + > static const struct drm_driver gm12u320_drm_driver = { > .driver_features = DRIVER_MODESET | DRIVER_GEM | DRIVER_ATOMIC, > > @@ -612,6 +618,7 @@ static const struct drm_driver gm12u320_drm_driver = { > > .fops = &gm12u320_fops, > DRM_GEM_SHMEM_DRIVER_OPS, > + .gem_prime_create_object = gm12u320_gem_prime_create_object, > }; > > static const struct drm_mode_config_funcs gm12u320_mode_config_funcs = { > diff --git a/drivers/gpu/drm/udl/udl_drv.c b/drivers/gpu/drm/udl/udl_drv.c > index 9269092697d8..fdf37b44a956 100644 > --- a/drivers/gpu/drm/udl/udl_drv.c > +++ b/drivers/gpu/drm/udl/udl_drv.c > @@ -34,12 +34,19 @@ static int udl_usb_resume(struct usb_interface *interface) > > DEFINE_DRM_GEM_FOPS(udl_driver_fops); > > +static struct drm_gem_object *udl_gem_prime_create_object(struct drm_device *dev, > + struct dma_buf_attachment *attach) > +{ > + return drm_gem_shmem_prime_import_sg_table(dev, attach, NULL); > +} > + > static const struct drm_driver driver = { > .driver_features = DRIVER_ATOMIC | DRIVER_GEM | DRIVER_MODESET, > > /* GEM hooks */ > .fops = &udl_driver_fops, > DRM_GEM_SHMEM_DRIVER_OPS, > + .gem_prime_create_object = udl_gem_prime_create_object, > > .name = DRIVER_NAME, > .desc = DRIVER_DESC, > diff --git a/include/drm/drm_drv.h b/include/drm/drm_drv.h > index 827838e0a97e..77657d649ca6 100644 > --- a/include/drm/drm_drv.h > +++ b/include/drm/drm_drv.h > @@ -369,11 +369,23 @@ struct drm_driver { > */ > struct drm_gem_object * (*gem_prime_import)(struct drm_device *dev, > struct dma_buf *dma_buf); > + /** > + * @gem_prime_create_object: > + * > + * Optional hook used by the PRIME helper functions > + * drm_gem_prime_import() respectively drm_gem_prime_import_dev(). > + */ > + struct drm_gem_object *(*gem_prime_create_object)( > + struct drm_device *dev, > + struct dma_buf_attachment *attach); > /** > * @gem_prime_import_sg_table: > * > * Optional hook used by the PRIME helper functions > * drm_gem_prime_import() respectively drm_gem_prime_import_dev(). > + * > + * TODO: This function is deprecated in favor of @drm_driver.gem_prime_create_object. > + * Drivers should switch over and implement SG-table support by themselves. > */ > struct drm_gem_object *(*gem_prime_import_sg_table)( > struct drm_device *dev, > -- > 2.30.1 > -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch

4 years, 9 months

1
0
0 0

Re: [Linaro-mm-sig] [PATCH v2 0/3] drm/prime: Only call dma_map_sgtable() for devices with DMA support

by Daniel Vetter

On Mon, Feb 22, 2021 at 2:24 PM Thomas Zimmermann <tzimmermann(a)suse.de> wrote: > > Hi > > Am 22.02.21 um 14:09 schrieb Christian König: > > > > > > Am 22.02.21 um 13:43 schrieb Thomas Zimmermann: > >> USB-based drivers cannot use DMA, so the importing of dma-buf attachments > >> currently fails for udl and gm12u320. This breaks joining/mirroring of > >> displays. > >> > >> The fix is now a little series. To solve the issue on the importer > >> side (i.e., the affected USB-based driver), patch 1 introduces a new > >> PRIME callback, struct drm_driver.gem_prime_create_object, which creates > >> an object and gives more control to the importing driver. Specifically, > >> udl and gm12u320 can now avoid the creation of a scatter/gather table > >> for the imported pages. Patch 1 is self-contained in the sense that it > >> can be backported into older kernels. > > > > Mhm, that sounds like a little overkill to me. > > > > Drivers can already import the DMA-bufs all by them selves without the > > help of the DRM functions. See amdgpu for an example. > > > > Daniel also already noted to me that he sees the DRM helper as a bit > > questionable middle layer. > > And this bug proves that it is. :) The trouble here is actually gem_bo->import_attach, which isn't really part of the questionable midlayer, but fairly mandatory (only exception is vmwgfx because not using gem) caching to make sure we don't end up with duped imports and fun stuff like that. And dma_buf_attach now implicitly creates the sg table already, so we're already in game over land. I think we'd need to make import_attach a union with import_buf or something like that, so that you can do attachment-less importing. > > Have you thought about doing that instead? > > There appears to be some useful code in drm_gem_prime_import_dev(). But > if the general sentiment goes towards removing > gem_prime_import_sg_table, we can work towards that as well. I still think this part is a bit a silly midlayer for no good reason, but I think that's orthogonal to the issue at hand here. I'd suggest we first try to paper over the issue by using prime_import_dev with the host controller (which hopefully is dma-capable for most systems). And then, at leisure, try to untangle the obj->import_attach issue. -Daniel > > Best regards > Thomas > > > > > Christian. > > > >> > >> Patches 2 and 3 update SHMEM and CMA helpers to use the new callback. > >> Effectively this moves the sg table setup from the PRIME helpers into > >> the memory managers. SHMEM now supports devices without DMA support, > >> so custom code can be removed from udl and g12u320. > >> > >> Tested by joining/mirroring displays of udl and radeon under Gnome/X11. > >> > >> v2: > >> * move fix to importer side (Christian, Daniel) > >> * update SHMEM and CMA helpers for new PRIME callbacks > >> > >> Thomas Zimmermann (3): > >> drm: Support importing dmabufs into drivers without DMA > >> drm/shmem-helper: Implement struct drm_driver.gem_prime_create_object > >> drm/cma-helper: Implement struct drm_driver.gem_prime_create_object > >> > >> drivers/gpu/drm/drm_gem_cma_helper.c | 62 ++++++++++++++----------- > >> drivers/gpu/drm/drm_gem_shmem_helper.c | 38 ++++++++++----- > >> drivers/gpu/drm/drm_prime.c | 43 +++++++++++------ > >> drivers/gpu/drm/lima/lima_drv.c | 2 +- > >> drivers/gpu/drm/panfrost/panfrost_drv.c | 2 +- > >> drivers/gpu/drm/panfrost/panfrost_gem.c | 6 +-- > >> drivers/gpu/drm/panfrost/panfrost_gem.h | 4 +- > >> drivers/gpu/drm/pl111/pl111_drv.c | 8 ++-- > >> drivers/gpu/drm/v3d/v3d_bo.c | 6 +-- > >> drivers/gpu/drm/v3d/v3d_drv.c | 2 +- > >> drivers/gpu/drm/v3d/v3d_drv.h | 5 +- > >> include/drm/drm_drv.h | 12 +++++ > >> include/drm/drm_gem_cma_helper.h | 12 ++--- > >> include/drm/drm_gem_shmem_helper.h | 6 +-- > >> 14 files changed, 120 insertions(+), 88 deletions(-) > >> > >> -- > >> 2.30.1 > >> > > > > -- > Thomas Zimmermann > Graphics Driver Developer > SUSE Software Solutions Germany GmbH > Maxfeldstr. 5, 90409 Nürnberg, Germany > (HRB 36809, AG Nürnberg) > Geschäftsführer: Felix Imendörffer > -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch

4 years, 9 months

1
0
0 0

Re: [Linaro-mm-sig] [PATCH v2 0/3] drm/prime: Only call dma_map_sgtable() for devices with DMA support

by Christian König

Am 22.02.21 um 13:43 schrieb Thomas Zimmermann: > USB-based drivers cannot use DMA, so the importing of dma-buf attachments > currently fails for udl and gm12u320. This breaks joining/mirroring of > displays. > > The fix is now a little series. To solve the issue on the importer > side (i.e., the affected USB-based driver), patch 1 introduces a new > PRIME callback, struct drm_driver.gem_prime_create_object, which creates > an object and gives more control to the importing driver. Specifically, > udl and gm12u320 can now avoid the creation of a scatter/gather table > for the imported pages. Patch 1 is self-contained in the sense that it > can be backported into older kernels. Mhm, that sounds like a little overkill to me. Drivers can already import the DMA-bufs all by them selves without the help of the DRM functions. See amdgpu for an example. Daniel also already noted to me that he sees the DRM helper as a bit questionable middle layer. Have you thought about doing that instead? Christian. > > Patches 2 and 3 update SHMEM and CMA helpers to use the new callback. > Effectively this moves the sg table setup from the PRIME helpers into > the memory managers. SHMEM now supports devices without DMA support, > so custom code can be removed from udl and g12u320. > > Tested by joining/mirroring displays of udl and radeon under Gnome/X11. > > v2: > * move fix to importer side (Christian, Daniel) > * update SHMEM and CMA helpers for new PRIME callbacks > > Thomas Zimmermann (3): > drm: Support importing dmabufs into drivers without DMA > drm/shmem-helper: Implement struct drm_driver.gem_prime_create_object > drm/cma-helper: Implement struct drm_driver.gem_prime_create_object > > drivers/gpu/drm/drm_gem_cma_helper.c | 62 ++++++++++++++----------- > drivers/gpu/drm/drm_gem_shmem_helper.c | 38 ++++++++++----- > drivers/gpu/drm/drm_prime.c | 43 +++++++++++------ > drivers/gpu/drm/lima/lima_drv.c | 2 +- > drivers/gpu/drm/panfrost/panfrost_drv.c | 2 +- > drivers/gpu/drm/panfrost/panfrost_gem.c | 6 +-- > drivers/gpu/drm/panfrost/panfrost_gem.h | 4 +- > drivers/gpu/drm/pl111/pl111_drv.c | 8 ++-- > drivers/gpu/drm/v3d/v3d_bo.c | 6 +-- > drivers/gpu/drm/v3d/v3d_drv.c | 2 +- > drivers/gpu/drm/v3d/v3d_drv.h | 5 +- > include/drm/drm_drv.h | 12 +++++ > include/drm/drm_gem_cma_helper.h | 12 ++--- > include/drm/drm_gem_shmem_helper.h | 6 +-- > 14 files changed, 120 insertions(+), 88 deletions(-) > > -- > 2.30.1 >

4 years, 9 months

1
0
0 0

[PATCH] drm-buf: Add debug option

by Daniel Vetter

We have too many people abusing the struct page they can get at but really shouldn't in importers. Aside from that the backing page might simply not exist (for dynamic p2p mappings) looking at it and using it e.g. for mmap can also wreak the page handling of the exporter completely. Importers really must go through the proper interface like dma_buf_mmap for everything. Just an RFC to see whether this idea has some stickiness. default y for now to make sure intel-gfx-ci picks it up too. I'm semi-tempted to enforce this for dynamic importers since those really have no excuse at all to break the rules. Unfortuantely we can't store the right pointers somewhere safe to make sure we oops on something recognizable, so best is to just wrangle them a bit by flipping all the bits. At least on x86 kernel addresses have all their high bits sets and the struct page array is fairly low in the kernel mapping, so flipping all the bits gives us a very high pointer in userspace and hence excellent chances for an invalid dereference. Signed-off-by: Daniel Vetter <daniel.vetter(a)intel.com> Cc: Sumit Semwal <sumit.semwal(a)linaro.org> Cc: "Christian König" <christian.koenig(a)amd.com> Cc: David Stevens <stevensd(a)chromium.org> Cc: linux-media(a)vger.kernel.org Cc: linaro-mm-sig(a)lists.linaro.org --- drivers/dma-buf/Kconfig | 8 +++++++ drivers/dma-buf/dma-buf.c | 49 +++++++++++++++++++++++++++++++++++---- 2 files changed, 53 insertions(+), 4 deletions(-) diff --git a/drivers/dma-buf/Kconfig b/drivers/dma-buf/Kconfig index 4f8224a6ac95..cddb549e5e59 100644 --- a/drivers/dma-buf/Kconfig +++ b/drivers/dma-buf/Kconfig @@ -50,6 +50,14 @@ config DMABUF_MOVE_NOTIFY This is marked experimental because we don't yet have a consistent execution context and memory management between drivers. +config DMABUF_DEBUG + bool "DMA-BUF debug checks" + default y + help + This option enables additional checks for DMA-BUF importers and + exporters. Specifically it validates that importers do not peek at the + underlying struct page when they import a buffer. + config DMABUF_SELFTESTS tristate "Selftests for the dma-buf interfaces" default n diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c index 1c9bd51db110..6e4725f7dfde 100644 --- a/drivers/dma-buf/dma-buf.c +++ b/drivers/dma-buf/dma-buf.c @@ -666,6 +666,30 @@ void dma_buf_put(struct dma_buf *dmabuf) } EXPORT_SYMBOL_GPL(dma_buf_put); +static struct sg_table * __map_dma_buf(struct dma_buf_attachment *attach, + enum dma_data_direction direction) +{ + struct sg_table *sg_table; + + sg_table = attach->dmabuf->ops->map_dma_buf(attach, direction); + +#if CONFIG_DMABUF_DEBUG + if (sg_table) { + int i; + struct scatterlist *sg; + + /* To catch abuse of the underlying struct page by importers mix + * up the bits, but take care to preserve the low SG_ bits to + * not corrupt the sgt. The mixing is undone in __unmap_dma_buf + * before passing the sgt back to the exporter. */ + for_each_sgtable_sg(sg_table, sg, i) + sg->page_link ^= ~0xffUL; + } +#endif + + return sg_table; +} + /** * dma_buf_dynamic_attach - Add the device to dma_buf's attachments list * @dmabuf: [in] buffer to attach device to. @@ -737,7 +761,7 @@ dma_buf_dynamic_attach(struct dma_buf *dmabuf, struct device *dev, goto err_unlock; } - sgt = dmabuf->ops->map_dma_buf(attach, DMA_BIDIRECTIONAL); + sgt = __map_dma_buf(attach, DMA_BIDIRECTIONAL); if (!sgt) sgt = ERR_PTR(-ENOMEM); if (IS_ERR(sgt)) { @@ -784,6 +808,23 @@ struct dma_buf_attachment *dma_buf_attach(struct dma_buf *dmabuf, } EXPORT_SYMBOL_GPL(dma_buf_attach); +static void __unmap_dma_buf(struct dma_buf_attachment *attach, + struct sg_table *sg_table, + enum dma_data_direction direction) +{ + +#if CONFIG_DMABUF_DEBUG + if (sg_table) { + int i; + struct scatterlist *sg; + + for_each_sgtable_sg(sg_table, sg, i) + sg->page_link ^= ~0xffUL; + } +#endif + attach->dmabuf->ops->unmap_dma_buf(attach, sg_table, direction); +} + /** * dma_buf_detach - Remove the given attachment from dmabuf's attachments list * @dmabuf: [in] buffer to detach from. @@ -802,7 +843,7 @@ void dma_buf_detach(struct dma_buf *dmabuf, struct dma_buf_attachment *attach) if (dma_buf_is_dynamic(attach->dmabuf)) dma_resv_lock(attach->dmabuf->resv, NULL); - dmabuf->ops->unmap_dma_buf(attach, attach->sgt, attach->dir); + __unmap_dma_buf(attach, attach->sgt, attach->dir); if (dma_buf_is_dynamic(attach->dmabuf)) { dma_buf_unpin(attach); @@ -924,7 +965,7 @@ struct sg_table *dma_buf_map_attachment(struct dma_buf_attachment *attach, } } - sg_table = attach->dmabuf->ops->map_dma_buf(attach, direction); + sg_table = __map_dma_buf(attach, direction); if (!sg_table) sg_table = ERR_PTR(-ENOMEM); @@ -987,7 +1028,7 @@ void dma_buf_unmap_attachment(struct dma_buf_attachment *attach, if (dma_buf_is_dynamic(attach->dmabuf)) dma_resv_assert_held(attach->dmabuf->resv); - attach->dmabuf->ops->unmap_dma_buf(attach, sg_table, direction); + __unmap_dma_buf(attach, sg_table, direction); if (dma_buf_is_dynamic(attach->dmabuf) && !IS_ENABLED(CONFIG_DMABUF_MOVE_NOTIFY)) -- 2.29.2

4 years, 10 months

3
5
0 0

Re: [Linaro-mm-sig] DMA-buf and uncached system memory

by Christian König

Am 15.02.21 um 10:06 schrieb Simon Ser: > On Monday, February 15th, 2021 at 9:58 AM, Christian König <christian.koenig(a)amd.com> wrote: > >> we are currently working an Freesync and direct scan out from system >> memory on AMD APUs in A+A laptops. >> >> On problem we stumbled over is that our display hardware needs to scan >> out from uncached system memory and we currently don't have a way to >> communicate that through DMA-buf. >> >> For our specific use case at hand we are going to implement something >> driver specific, but the question is should we have something more >> generic for this? >> >> After all the system memory access pattern is a PCIe extension and as >> such something generic. > Intel also needs uncached system memory if I'm not mistaken? No idea, that's why I'm asking. Could be that this is also interesting for I+A systems. > Where are the buffers allocated? If GBM, then it needs to allocate memory that > can be scanned out if the USE_SCANOUT flag is set or if a scanout-capable > modifier is picked. > > If this is about communicating buffer constraints between different components > of the stack, there were a few proposals about it. The most recent one is [1]. Well the problem here is on a different level of the stack. See resolution, pitch etc:.. can easily communicated in userspace without involvement of the kernel. The worst thing which can happen is that you draw garbage into your own application window. But if you get the caching attributes in the page tables (both CPU as well as IOMMU, device etc...) wrong then ARM for example has the tendency to just spontaneously reboot X86 is fortunately a bit more gracefully and you only end up with random data corruption, but that is only marginally better. So to sum it up that is not something which we can leave in the hands of userspace. I think that exporters in the DMA-buf framework should have the ability to tell importers if the system memory snooping is necessary or not. Userspace components can then of course tell the exporter what the importer needs, but validation if that stuff is correct and doesn't crash the system must happen in the kernel. Regards, Christian. > > Simon > > [1]: https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fxdc2020.x…

4 years, 10 months

4
6
0 0

Re: [Linaro-mm-sig] DMA-buf and uncached system memory

by Christian König

Am 15.02.21 um 13:00 schrieb Thomas Zimmermann: > Hi > > Am 15.02.21 um 10:49 schrieb Thomas Zimmermann: >> Hi >> >> Am 15.02.21 um 09:58 schrieb Christian König: >>> Hi guys, >>> >>> we are currently working an Freesync and direct scan out from system >>> memory on AMD APUs in A+A laptops. >>> >>> On problem we stumbled over is that our display hardware needs to >>> scan out from uncached system memory and we currently don't have a >>> way to communicate that through DMA-buf. > > Re-reading this paragrah, it sounds more as if you want to let the > exporter know where to move the buffer. Is this another case of the > missing-pin-flag problem? No, your original interpretation was correct. Maybe my writing is a bit unspecific. The real underlying issue is that our display hardware has a problem with latency when accessing system memory. So the question is if that also applies to for example Intel hardware or other devices as well or if it is just something AMD specific? Regards, Christian. > > Best regards > Thomas > >>> >>> For our specific use case at hand we are going to implement >>> something driver specific, but the question is should we have >>> something more generic for this? >> >> For vmap operations, we return the address as struct dma_buf_map, >> which contains additional information about the memory buffer. In >> vram helpers, we have the interface drm_gem_vram_offset() that >> returns the offset of the GPU device memory. >> >> Would it be feasible to combine both concepts into a dma-buf >> interface that returns the device-memory offset plus the additional >> caching flag? >> >> There'd be a structure and a getter function returning the structure. >> >> struct dma_buf_offset { >> bool cached; >> u64 address; >> }; >> >> // return offset in *off >> int dma_buf_offset(struct dma_buf *buf, struct dma_buf_off *off); >> >> Whatever settings are returned by dma_buf_offset() are valid while >> the dma_buf is pinned. >> >> Best regards >> Thomas >> >>> >>> After all the system memory access pattern is a PCIe extension and >>> as such something generic. >>> >>> Regards, >>> Christian. >>> _______________________________________________ >>> dri-devel mailing list >>> dri-devel(a)lists.freedesktop.org >>> https://lists.freedesktop.org/mailman/listinfo/dri-devel >> >> >> _______________________________________________ >> dri-devel mailing list >> dri-devel(a)lists.freedesktop.org >> https://lists.freedesktop.org/mailman/listinfo/dri-devel >> >

4 years, 10 months

1
0
0 0

Re: [Linaro-mm-sig] [PATCH] RFC: dma-fence: Document recoverable page fault implications

by Daniel Vetter

On Tue, Feb 9, 2021 at 4:13 AM Bas Nieuwenhuizen <bas(a)basnieuwenhuizen.nl> wrote: > > On Thu, Jan 28, 2021 at 4:40 PM Felix Kuehling <felix.kuehling(a)amd.com> wrote: > > > > Am 2021-01-28 um 2:39 a.m. schrieb Christian König: > > > Am 27.01.21 um 23:00 schrieb Felix Kuehling: > > >> Am 2021-01-27 um 7:16 a.m. schrieb Christian König: > > >>> Am 27.01.21 um 13:11 schrieb Maarten Lankhorst: > > >>>> Op 27-01-2021 om 01:22 schreef Felix Kuehling: > > >>>>> Am 2021-01-21 um 2:40 p.m. schrieb Daniel Vetter: > > >>>>>> Recently there was a fairly long thread about recoreable hardware > > >>>>>> page > > >>>>>> faults, how they can deadlock, and what to do about that. > > >>>>>> > > >>>>>> While the discussion is still fresh I figured good time to try and > > >>>>>> document the conclusions a bit. > > >>>>>> > > >>>>>> References: > > >>>>>> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Flore.kern… > > >>>>>> > > >>>>>> Cc: Maarten Lankhorst <maarten.lankhorst(a)linux.intel.com> > > >>>>>> Cc: Thomas Hellström <thomas.hellstrom(a)intel.com> > > >>>>>> Cc: "Christian König" <christian.koenig(a)amd.com> > > >>>>>> Cc: Jerome Glisse <jglisse(a)redhat.com> > > >>>>>> Cc: Felix Kuehling <felix.kuehling(a)amd.com> > > >>>>>> Signed-off-by: Daniel Vetter <daniel.vetter(a)intel.com> > > >>>>>> Cc: Sumit Semwal <sumit.semwal(a)linaro.org> > > >>>>>> Cc: linux-media(a)vger.kernel.org > > >>>>>> Cc: linaro-mm-sig(a)lists.linaro.org > > >>>>>> -- > > >>>>>> I'll be away next week, but figured I'll type this up quickly for > > >>>>>> some > > >>>>>> comments and to check whether I got this all roughly right. > > >>>>>> > > >>>>>> Critique very much wanted on this, so that we can make sure hw which > > >>>>>> can't preempt (with pagefaults pending) like gfx10 has a clear > > >>>>>> path to > > >>>>>> support page faults in upstream. So anything I missed, got wrong or > > >>>>>> like that would be good. > > >>>>>> -Daniel > > >>>>>> --- > > >>>>>> Documentation/driver-api/dma-buf.rst | 66 > > >>>>>> ++++++++++++++++++++++++++++ > > >>>>>> 1 file changed, 66 insertions(+) > > >>>>>> > > >>>>>> diff --git a/Documentation/driver-api/dma-buf.rst > > >>>>>> b/Documentation/driver-api/dma-buf.rst > > >>>>>> index a2133d69872c..e924c1e4f7a3 100644 > > >>>>>> --- a/Documentation/driver-api/dma-buf.rst > > >>>>>> +++ b/Documentation/driver-api/dma-buf.rst > > >>>>>> @@ -257,3 +257,69 @@ fences in the kernel. This means: > > >>>>>> userspace is allowed to use userspace fencing or long running > > >>>>>> compute > > >>>>>> workloads. This also means no implicit fencing for shared > > >>>>>> buffers in these > > >>>>>> cases. > > >>>>>> + > > >>>>>> +Recoverable Hardware Page Faults Implications > > >>>>>> +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > > >>>>>> + > > >>>>>> +Modern hardware supports recoverable page faults, which has a > > >>>>>> lot of > > >>>>>> +implications for DMA fences. > > >>>>>> + > > >>>>>> +First, a pending page fault obviously holds up the work that's > > >>>>>> running on the > > >>>>>> +accelerator and a memory allocation is usually required to resolve > > >>>>>> the fault. > > >>>>>> +But memory allocations are not allowed to gate completion of DMA > > >>>>>> fences, which > > >>>>>> +means any workload using recoverable page faults cannot use DMA > > >>>>>> fences for > > >>>>>> +synchronization. Synchronization fences controlled by userspace > > >>>>>> must be used > > >>>>>> +instead. > > >>>>>> + > > >>>>>> +On GPUs this poses a problem, because current desktop compositor > > >>>>>> protocols on > > >>>>>> +Linus rely on DMA fences, which means without an entirely new > > >>>>>> userspace stack > > >>>>>> +built on top of userspace fences, they cannot benefit from > > >>>>>> recoverable page > > >>>>>> +faults. The exception is when page faults are only used as > > >>>>>> migration hints and > > >>>>>> +never to on-demand fill a memory request. For now this means > > >>>>>> recoverable page > > >>>>>> +faults on GPUs are limited to pure compute workloads. > > >>>>>> + > > >>>>>> +Furthermore GPUs usually have shared resources between the 3D > > >>>>>> rendering and > > >>>>>> +compute side, like compute units or command submission engines. If > > >>>>>> both a 3D > > >>>>>> +job with a DMA fence and a compute workload using recoverable page > > >>>>>> faults are > > >>>>>> +pending they could deadlock: > > >>>>>> + > > >>>>>> +- The 3D workload might need to wait for the compute job to finish > > >>>>>> and release > > >>>>>> + hardware resources first. > > >>>>>> + > > >>>>>> +- The compute workload might be stuck in a page fault, because the > > >>>>>> memory > > >>>>>> + allocation is waiting for the DMA fence of the 3D workload to > > >>>>>> complete. > > >>>>>> + > > >>>>>> +There are a few ways to prevent this problem: > > >>>>>> + > > >>>>>> +- Compute workloads can always be preempted, even when a page > > >>>>>> fault is pending > > >>>>>> + and not yet repaired. Not all hardware supports this. > > >>>>>> + > > >>>>>> +- DMA fence workloads and workloads which need page fault handling > > >>>>>> have > > >>>>>> + independent hardware resources to guarantee forward progress. > > >>>>>> This could be > > >>>>>> + achieved through e.g. through dedicated engines and minimal > > >>>>>> compute unit > > >>>>>> + reservations for DMA fence workloads. > > >>>>>> + > > >>>>>> +- The reservation approach could be further refined by only > > >>>>>> reserving the > > >>>>>> + hardware resources for DMA fence workloads when they are > > >>>>>> in-flight. This must > > >>>>>> + cover the time from when the DMA fence is visible to other > > >>>>>> threads up to > > >>>>>> + moment when fence is completed through dma_fence_signal(). > > >>>>>> + > > >>>>>> +- As a last resort, if the hardware provides no useful reservation > > >>>>>> mechanics, > > >>>>>> + all workloads must be flushed from the GPU when switching > > >>>>>> between jobs > > >>>>>> + requiring DMA fences or jobs requiring page fault handling: This > > >>>>>> means all DMA > > >>>>>> + fences must complete before a compute job with page fault > > >>>>>> handling can be > > >>>>>> + inserted into the scheduler queue. And vice versa, before a DMA > > >>>>>> fence can be > > >>>>>> + made visible anywhere in the system, all compute workloads must > > >>>>>> be preempted > > >>>>>> + to guarantee all pending GPU page faults are flushed. > > >>>>> I thought of another possible workaround: > > >>>>> > > >>>>> * Partition the memory. Servicing of page faults will use a > > >>>>> separate > > >>>>> memory pool that can always be allocated from without > > >>>>> waiting for > > >>>>> fences. This includes memory for page tables and memory for > > >>>>> migrating data to. You may steal memory from other processes > > >>>>> that > > >>>>> can page fault, so no fence waiting is necessary. Being able to > > >>>>> steal memory at any time also means there are basically no > > >>>>> out-of-memory situations you need to worry about. Even page > > >>>>> tables > > >>>>> (except the root page directory of each process) can be > > >>>>> stolen in > > >>>>> the worst case. > > >>>> I think 'overcommit' would be a nice way to describe this. But I'm not > > >>>> sure how easy this is to implement in practice. You would basically > > >>>> need > > >>>> to create your own memory manager for this. > > >>> Well you would need a completely separate pool for both device as well > > >>> as system memory. > > >>> > > >>> E.g. on boot we say we steal X GB system memory only for HMM. > > >> Why? The GPU driver doesn't need to allocate system memory for HMM. > > >> Migrations to system memory are handled by the kernel's handle_mm_fault > > >> and page allocator and swap logic. > > > > > > And that one depends on dma_fence completion because you can easily > > > need to wait for an MMU notifier callback. > > > > I see, the GFX MMU notifier for userpointers in amdgpu currently waits > > for fences. For the KFD MMU notifier I am planning to fix this by > > causing GPU page faults instead of preempting the queues. Can we limit > > userptrs in amdgpu to engines that can page fault. Basically make it > > illegal to attach userptr BOs to graphics CS BO lists, so they can only > > be used in user mode command submissions, which can page fault. Then the > > GFX MMU notifier could invalidate PTEs and would not have to wait for > > fences. > > sadly graphics + userptr is already exposed via Mesa. This is not about userptr, we fake userptr entirely in software. It's about exposing recoverable gpu page faults (which would make userptr maybe more efficient since we could do on-demand paging). userptr itself isn't a problem, but it is part of the reasons why this is tricky. Christian/Felix, I think for kernel folks this is clear enough that I don't need to clarify this in the text? -Daniel > > > > > > > > > > > As Maarten wrote when you want to go down this route you need a > > > complete separate memory management parallel to the one of the kernel. > > > > Not really. I'm trying to make the GPU memory management more similar to > > what the kernel does for system memory. > > > > I understood Maarten's comment as "I'm creating a new memory manager and > > not using TTM any more". This is true. The idea is that this portion of > > VRAM would be managed more like system memory. > > > > Regards, > > Felix > > > > > > > > > > Regards, > > > Christian. > > > > > >> It doesn't depend on any fences, so > > >> it cannot deadlock with any GPU driver-managed memory. The GPU driver > > >> gets involved in the MMU notifier to invalidate device page tables. But > > >> that also doesn't need to wait for any fences. > > >> > > >> And if the kernel runs out of pageable memory, you're in trouble anyway. > > >> The OOM killer will step in, nothing new there. > > >> > > >> Regards, > > >> Felix > > >> > > >> > > >>>> But from a design point of view, definitely a valid solution. > > >>> I think the restriction above makes it pretty much unusable. > > >>> > > >>>> But this looks good, those solutions are definitely the valid > > >>>> options we > > >>>> can choose from. > > >>> It's certainly worth noting, yes. And just to make sure that nobody > > >>> has the idea to reserve only device memory. > > >>> > > >>> Christian. > > >>> > > >>>> ~Maarten > > >>>> > > >> _______________________________________________ > > >> Linaro-mm-sig mailing list > > >> Linaro-mm-sig(a)lists.linaro.org > > >> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.lin… > > >> > > > > > _______________________________________________ > > dri-devel mailing list > > dri-devel(a)lists.freedesktop.org > > https://lists.freedesktop.org/mailman/listinfo/dri-devel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch

4 years, 10 months

2
3
0 0

[PATCH v4 0/4] Chunk Heap Support on DMA-HEAP

by Minchan Kim

This patchset introduces a new dma heap, "chunk-heap" that makes it easy to perform the bulk allocation of high order pages. It has been created to help optimize the 4K/8K HDR video playback with secure DRM HW to protect contents on memory. The HW needs physically contiguous memory chunks(e.g, 64K) up to several hundred MB memory. To make such high-order big bulk allocations work, chunk-heap uses CMA area. To avoid CMA allocation long stall on blocking pages(e.g., page writeback and/or page locking), it uses failfast mode of the CMA API(i.e., __GFP_NORETRY) so it will continue to find easy migratable pages in different pageblocks without stalling. At last resort, it will allow the blocking only if it couldn't find the available memory in the end. First two patches introduces the failfast mode as __GFP_NORETRY in alloc_contig_range and the allow to use it from the CMA API. Third patch introduces device tree syntax for chunk-heap to bind the specific CMA area with chunk-heap. Finally, last patch implements chunk-heap as dma-buf heap. * since v3 - https://lore.kernel.org/linux-mm/20210113012143.1201105-1-minchan@kernel.or… * use prefix for chunk-name - John * fix yamllint error - Rob * add reviewed-by - Suren * since v2 - https://lore.kernel.org/linux-mm/20201201175144.3996569-1-minchan@kernel.or… * introduce gfp_mask with __GFP_NORETRY on cma_alloc - Michal * do not expoert CMA APIs - Christoph * use compatible string for DT instead of dma-heap specific property - Hridya * Since v1 - https://lore.kernel.org/linux-mm/20201117181935.3613581-1-minchan@kernel.or… * introduce alloc_contig_mode - David * use default CMA instead of device tree - John Hyesoo Yu (2): dt-bindings: reserved-memory: Make DMA-BUF CMA heap DT-configurable dma-buf: heaps: add chunk heap to dmabuf heaps Minchan Kim (2): mm: cma: introduce gfp flag in cma_alloc instead of no_warn mm: failfast mode with __GFP_NORETRY in alloc_contig_range .../reserved-memory/dma_heap_chunk.yaml | 56 ++ drivers/dma-buf/heaps/Kconfig | 8 + drivers/dma-buf/heaps/Makefile | 1 + drivers/dma-buf/heaps/chunk_heap.c | 492 ++++++++++++++++++ drivers/dma-buf/heaps/cma_heap.c | 2 +- drivers/s390/char/vmcp.c | 2 +- include/linux/cma.h | 2 +- kernel/dma/contiguous.c | 3 +- mm/cma.c | 12 +- mm/cma_debug.c | 2 +- mm/hugetlb.c | 6 +- mm/page_alloc.c | 8 +- mm/secretmem.c | 3 +- 13 files changed, 581 insertions(+), 16 deletions(-) create mode 100644 Documentation/devicetree/bindings/reserved-memory/dma_heap_chunk.yaml create mode 100644 drivers/dma-buf/heaps/chunk_heap.c -- 2.30.0.296.g2bfb1c46d8-goog

4 years, 10 months

6
13
0 0

Re: [Linaro-mm-sig] [PATCH v3 2/2] dmabuf: Add dmabuf inode number to /proc/*/fdinfo

by Christian König

Am 05.02.21 um 03:23 schrieb Kalesh Singh: > If a FD refers to a DMA buffer add the DMA buffer inode number to > /proc/<pid>/fdinfo/<FD> and /proc/<pid>/task/<tid>/fdindo/<FD>. > > The dmabuf inode number allows userspace to uniquely identify the buffer > and avoids a dependency on /proc/<pid>/fd/* when accounting per-process > DMA buffer sizes. BTW: Why do we make this DMA-buf specific? Couldn't we always print the inode number for all fds? Regards, Christian. > > Signed-off-by: Kalesh Singh <kaleshsingh(a)google.com> > --- > Changes in v3: > - Add documentation in proc.rst > Changes in v2: > - Update patch description > > Documentation/filesystems/proc.rst | 17 +++++++++++++++++ > drivers/dma-buf/dma-buf.c | 1 + > 2 files changed, 18 insertions(+) > > diff --git a/Documentation/filesystems/proc.rst b/Documentation/filesystems/proc.rst > index 2fa69f710e2a..fdd38676f57f 100644 > --- a/Documentation/filesystems/proc.rst > +++ b/Documentation/filesystems/proc.rst > @@ -2031,6 +2031,23 @@ details]. 'it_value' is remaining time until the timer expiration. > with TIMER_ABSTIME option which will be shown in 'settime flags', but 'it_value' > still exhibits timer's remaining time. > > +DMA Buffer files > +~~~~~~~~~~~~~~~~ > + > +:: > + > + pos: 0 > + flags: 04002 > + mnt_id: 9 > + dmabuf_inode_no: 63107 > + size: 32768 > + count: 2 > + exp_name: system-heap > + > +where 'dmabuf_inode_no' is the unique inode number of the DMA buffer file. > +'size' is the size of the DMA buffer in bytes. 'count' is the file count of > +the DMA buffer file. 'exp_name' is the name of the DMA buffer exporter. > + > 3.9 /proc/<pid>/map_files - Information about memory mapped files > --------------------------------------------------------------------- > This directory contains symbolic links which represent memory mapped files > diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c > index 9ad6397aaa97..d869099ede83 100644 > --- a/drivers/dma-buf/dma-buf.c > +++ b/drivers/dma-buf/dma-buf.c > @@ -414,6 +414,7 @@ static void dma_buf_show_fdinfo(struct seq_file *m, struct file *file) > { > struct dma_buf *dmabuf = file->private_data; > > + seq_printf(m, "dmabuf_inode_no:\t%lu\n", file_inode(file)->i_ino); > seq_printf(m, "size:\t%zu\n", dmabuf->size); > /* Don't count the temporary reference taken inside procfs seq_show */ > seq_printf(m, "count:\t%ld\n", file_count(dmabuf->file) - 1);

4 years, 10 months

2
1
0 0

[PATCH] RFC: dma-buf: Require VM_SPECIAL vma for mmap

by Daniel Vetter

tldr; DMA buffers aren't normal memory, expecting that you can use them like that (like calling get_user_pages works, or that they're accounting like any other normal memory) cannot be guaranteed. Since some userspace only runs on integrated devices, where all buffers are actually all resident system memory, there's a huge temptation to assume that a struct page is always present and useable like for any more pagecache backed mmap. This has the potential to result in a uapi nightmare. To stop this gap require that DMA buffer mmaps are VM_SPECIAL, which blocks get_user_pages and all the other struct page based infrastructure for everyone. In spirit this is the uapi counterpart to the kernel-internal CONFIG_DMABUF_DEBUG. Motivated by a recent patch which wanted to swich the system dma-buf heap to vm_insert_page instead of vm_insert_pfn. References: https://lore.kernel.org/lkml/CAKMK7uHi+mG0z0HUmNt13QCCvutuRVjpcR0NjRL12k-Wb… Cc: Jason Gunthorpe <jgg(a)ziepe.ca> Cc: Suren Baghdasaryan <surenb(a)google.com> Cc: Matthew Wilcox <willy(a)infradead.org> Cc: John Stultz <john.stultz(a)linaro.org> Signed-off-by: Daniel Vetter <daniel.vetter(a)intel.com> Cc: Sumit Semwal <sumit.semwal(a)linaro.org> Cc: "Christian König" <christian.koenig(a)amd.com> Cc: linux-media(a)vger.kernel.org Cc: linaro-mm-sig(a)lists.linaro.org --- drivers/dma-buf/dma-buf.c | 15 +++++++++++++-- 1 file changed, 13 insertions(+), 2 deletions(-) diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c index f264b70c383e..d3081fc07056 100644 --- a/drivers/dma-buf/dma-buf.c +++ b/drivers/dma-buf/dma-buf.c @@ -127,6 +127,7 @@ static struct file_system_type dma_buf_fs_type = { static int dma_buf_mmap_internal(struct file *file, struct vm_area_struct *vma) { struct dma_buf *dmabuf; + int ret; if (!is_dma_buf_file(file)) return -EINVAL; @@ -142,7 +143,11 @@ static int dma_buf_mmap_internal(struct file *file, struct vm_area_struct *vma) dmabuf->size >> PAGE_SHIFT) return -EINVAL; - return dmabuf->ops->mmap(dmabuf, vma); + ret = dmabuf->ops->mmap(dmabuf, vma); + + WARN_ON(!(vma->vm_flags & VM_SPECIAL)); + + return ret; } static loff_t dma_buf_llseek(struct file *file, loff_t offset, int whence) @@ -1244,6 +1249,8 @@ EXPORT_SYMBOL_GPL(dma_buf_end_cpu_access); int dma_buf_mmap(struct dma_buf *dmabuf, struct vm_area_struct *vma, unsigned long pgoff) { + int ret; + if (WARN_ON(!dmabuf || !vma)) return -EINVAL; @@ -1264,7 +1271,11 @@ int dma_buf_mmap(struct dma_buf *dmabuf, struct vm_area_struct *vma, vma_set_file(vma, dmabuf->file); vma->vm_pgoff = pgoff; - return dmabuf->ops->mmap(dmabuf, vma); + ret = dmabuf->ops->mmap(dmabuf, vma); + + WARN_ON(!(vma->vm_flags & VM_SPECIAL)); + + return ret; } EXPORT_SYMBOL_GPL(dma_buf_mmap); -- 2.30.0

4 years, 10 months

3
11
0 0

[PATCH 1/2] mm: replace BUG_ON in vm_insert_page with a return of an error

by Suren Baghdasaryan

Replace BUG_ON(vma->vm_flags & VM_PFNMAP) in vm_insert_page with WARN_ON_ONCE and returning an error. This is to ensure users of the vm_insert_page that set VM_PFNMAP are notified of the wrong flag usage and get an indication of an error without panicing the kernel. This will help identifying drivers that need to clear VM_PFNMAP before using dmabuf system heap which is moving to use vm_insert_page. Suggested-by: Christoph Hellwig <hch(a)infradead.org> Signed-off-by: Suren Baghdasaryan <surenb(a)google.com> --- mm/memory.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/mm/memory.c b/mm/memory.c index feff48e1465a..e503c9801cd9 100644 --- a/mm/memory.c +++ b/mm/memory.c @@ -1827,7 +1827,8 @@ int vm_insert_page(struct vm_area_struct *vma, unsigned long addr, return -EINVAL; if (!(vma->vm_flags & VM_MIXEDMAP)) { BUG_ON(mmap_read_trylock(vma->vm_mm)); - BUG_ON(vma->vm_flags & VM_PFNMAP); + if (WARN_ON_ONCE(vma->vm_flags & VM_PFNMAP)) + return -EINVAL; vma->vm_flags |= VM_MIXEDMAP; } return insert_page(vma, addr, page, vma->vm_page_prot); -- 2.30.0.365.g02bc693789-goog

4 years, 10 months

9
21
0 0

[PATCH v2 1/2] procfs: Allow reading fdinfo with PTRACE_MODE_READ

by Kalesh Singh

Android captures per-process system memory state when certain low memory events (e.g a foreground app kill) occur, to identify potential memory hoggers. In order to measure how much memory a process actually consumes, it is necessary to include the DMA buffer sizes for that process in the memory accounting. Since the handle to DMA buffers are raw FDs, it is important to be able to identify which processes have FD references to a DMA buffer. Currently, DMA buffer FDs can be accounted using /proc/<pid>/fd/* and /proc/<pid>/fdinfo -- both are only readable by the process owner, as follows: 1. Do a readlink on each FD. 2. If the target path begins with "/dmabuf", then the FD is a dmabuf FD. 3. stat the file to get the dmabuf inode number. 4. Read/ proc/<pid>/fdinfo/<fd>, to get the DMA buffer size. Accessing other processes’ fdinfo requires root privileges. This limits the use of the interface to debugging environments and is not suitable for production builds. Granting root privileges even to a system process increases the attack surface and is highly undesirable. Since fdinfo doesn't permit reading process memory and manipulating process state, allow accessing fdinfo under PTRACE_MODE_READ_FSCRED. Suggested-by: Jann Horn <jannh(a)google.com> Signed-off-by: Kalesh Singh <kaleshsingh(a)google.com> --- Changes in v2: - Update patch desciption fs/proc/base.c | 4 ++-- fs/proc/fd.c | 15 ++++++++++++++- 2 files changed, 16 insertions(+), 3 deletions(-) diff --git a/fs/proc/base.c b/fs/proc/base.c index b3422cda2a91..a37f9de7103f 100644 --- a/fs/proc/base.c +++ b/fs/proc/base.c @@ -3160,7 +3160,7 @@ static const struct pid_entry tgid_base_stuff[] = { DIR("task", S_IRUGO|S_IXUGO, proc_task_inode_operations, proc_task_operations), DIR("fd", S_IRUSR|S_IXUSR, proc_fd_inode_operations, proc_fd_operations), DIR("map_files", S_IRUSR|S_IXUSR, proc_map_files_inode_operations, proc_map_files_operations), - DIR("fdinfo", S_IRUSR|S_IXUSR, proc_fdinfo_inode_operations, proc_fdinfo_operations), + DIR("fdinfo", S_IRUGO|S_IXUGO, proc_fdinfo_inode_operations, proc_fdinfo_operations), DIR("ns", S_IRUSR|S_IXUGO, proc_ns_dir_inode_operations, proc_ns_dir_operations), #ifdef CONFIG_NET DIR("net", S_IRUGO|S_IXUGO, proc_net_inode_operations, proc_net_operations), @@ -3504,7 +3504,7 @@ static const struct inode_operations proc_tid_comm_inode_operations = { */ static const struct pid_entry tid_base_stuff[] = { DIR("fd", S_IRUSR|S_IXUSR, proc_fd_inode_operations, proc_fd_operations), - DIR("fdinfo", S_IRUSR|S_IXUSR, proc_fdinfo_inode_operations, proc_fdinfo_operations), + DIR("fdinfo", S_IRUGO|S_IXUGO, proc_fdinfo_inode_operations, proc_fdinfo_operations), DIR("ns", S_IRUSR|S_IXUGO, proc_ns_dir_inode_operations, proc_ns_dir_operations), #ifdef CONFIG_NET DIR("net", S_IRUGO|S_IXUGO, proc_net_inode_operations, proc_net_operations), diff --git a/fs/proc/fd.c b/fs/proc/fd.c index cb51763ed554..585e213301f9 100644 --- a/fs/proc/fd.c +++ b/fs/proc/fd.c @@ -6,6 +6,7 @@ #include <linux/fdtable.h> #include <linux/namei.h> #include <linux/pid.h> +#include <linux/ptrace.h> #include <linux/security.h> #include <linux/file.h> #include <linux/seq_file.h> @@ -72,6 +73,18 @@ static int seq_show(struct seq_file *m, void *v) static int seq_fdinfo_open(struct inode *inode, struct file *file) { + bool allowed = false; + struct task_struct *task = get_proc_task(inode); + + if (!task) + return -ESRCH; + + allowed = ptrace_may_access(task, PTRACE_MODE_READ_FSCREDS); + put_task_struct(task); + + if (!allowed) + return -EACCES; + return single_open(file, seq_show, inode); } @@ -307,7 +320,7 @@ static struct dentry *proc_fdinfo_instantiate(struct dentry *dentry, struct proc_inode *ei; struct inode *inode; - inode = proc_pid_make_inode(dentry->d_sb, task, S_IFREG | S_IRUSR); + inode = proc_pid_make_inode(dentry->d_sb, task, S_IFREG | S_IRUGO); if (!inode) return ERR_PTR(-ENOENT); -- 2.30.0.365.g02bc693789-goog

4 years, 10 months

2
2
0 0

[PATCH v3] dmabuf: Add the capability to expose DMA-BUF stats in sysfs

by Hridya Valsaraju

This patch allows statistics to be enabled for each DMA-BUF in sysfs by enabling the config CONFIG_DMABUF_SYSFS_STATS. The following stats will be exposed by the interface: /sys/kernel/dmabuf/buffers/<inode_number>/exporter_name /sys/kernel/dmabuf/buffers/<inode_number>/size /sys/kernel/dmabuf/buffers/<inode_number>/attachments/<attach_uid>/device /sys/kernel/dmabuf/buffers/<inode_number>/attachments/<attach_uid>/map_counter The inode_number is unique for each DMA-BUF and was added earlier [1] in order to allow userspace to track DMA-BUF usage across different processes. Currently, this information is exposed in /sys/kernel/debug/dma_buf/bufinfo. However, since debugfs is considered unsafe to be mounted in production, it is being duplicated in sysfs. This information will be used to derive DMA-BUF per-exporter stats and per-device usage stats for Android Bug reports. The corresponding userspace changes can be found at [2]. Telemetry tools will also capture this information(along with other memory metrics) periodically as well as on important events like a foreground app kill (which might have been triggered by Low Memory Killer). It will also contribute to provide a snapshot of the system memory usage on other events such as OOM kills and Application Not Responding events. A shell script that can be run on a classic Linux environment to read out the DMA-BUF statistics can be found at [3](suggested by John Stultz). The patch contains the following improvements over the previous version: 1) Each attachment is represented by its own directory to allow creating a symlink to the importing device and to also provide room for future expansion. 2) The number of distinct mappings of each attachment is exposed in a separate file. 3) The per-buffer statistics are now in /sys/kernel/dmabuf/buffers inorder to make the interface expandable in future. All of the improvements above are based on suggestions/feedback from Daniel Vetter and Christian König. [1]: https://lore.kernel.org/patchwork/patch/1088791/ [2]: https://android-review.googlesource.com/q/topic:%22dmabuf-sysfs%22+(status:… [3]: https://android-review.googlesource.com/c/platform/system/memory/libmeminfo… Signed-off-by: Hridya Valsaraju <hridya(a)google.com> Reported-by: kernel test robot <lkp(a)intel.com> --- Changes in v3: Fix a warning reported by the kernel test robot. Changes in v2: -Move statistics to /sys/kernel/dmabuf/buffers in oder to allow addition of other DMA-BUF-related sysfs stats in future. Based on feedback from Daniel Vetter. -Each attachment has its own directory to represent attaching devices as symlinks and to introduce map_count as a separate file. Based on feedback from Daniel Vetter and Christian König. Thank you both! -Commit messages updated to point to userspace code in AOSP that will read the DMA-BUF sysfs stats. .../ABI/testing/sysfs-kernel-dmabuf-buffers | 52 ++++ drivers/dma-buf/Kconfig | 11 + drivers/dma-buf/Makefile | 1 + drivers/dma-buf/dma-buf-sysfs-stats.c | 285 ++++++++++++++++++ drivers/dma-buf/dma-buf-sysfs-stats.h | 62 ++++ drivers/dma-buf/dma-buf.c | 37 +++ include/linux/dma-buf.h | 20 ++ 7 files changed, 468 insertions(+) create mode 100644 Documentation/ABI/testing/sysfs-kernel-dmabuf-buffers create mode 100644 drivers/dma-buf/dma-buf-sysfs-stats.c create mode 100644 drivers/dma-buf/dma-buf-sysfs-stats.h diff --git a/Documentation/ABI/testing/sysfs-kernel-dmabuf-buffers b/Documentation/ABI/testing/sysfs-kernel-dmabuf-buffers new file mode 100644 index 000000000000..6f7c65209f07 --- /dev/null +++ b/Documentation/ABI/testing/sysfs-kernel-dmabuf-buffers @@ -0,0 +1,52 @@ +What: /sys/kernel/dmabuf/buffers +Date: January 2021 +KernelVersion: v5.12 +Contact: Hridya Valsaraju <hridya(a)google.com> +Description: The /sys/kernel/dmabuf/buffers directory contains a + snapshot of the internal state of every DMA-BUF. + /sys/kernel/dmabuf/buffers/<inode_number> will contain the + statistics for the DMA-BUF with the unique inode number + <inode_number> +Users: kernel memory tuning/debugging tools + +What: /sys/kernel/dmabuf/buffers/<inode_number>/exporter_name +Date: January 2021 +KernelVersion: v5.12 +Contact: Hridya Valsaraju <hridya(a)google.com> +Description: This file is read-only and contains the name of the exporter of + the DMA-BUF. + +What: /sys/kernel/dmabuf/buffers/<inode_number>/size +Date: January 2021 +KernelVersion: v5.12 +Contact: Hridya Valsaraju <hridya(a)google.com> +Description: This file is read-only and specifies the size of the DMA-BUF in + bytes. + +What: /sys/kernel/dmabuf/buffers/<inode_number>/attachments +Date: January 2021 +KernelVersion: v5.12 +Contact: Hridya Valsaraju <hridya(a)google.com> +Description: This directory will contain subdirectories representing every + attachment of the DMA-BUF. + +What: /sys/kernel/dmabuf/buffers/<inode_number>/attachments/<attachment_uid> +Date: January 2021 +KernelVersion: v5.12 +Contact: Hridya Valsaraju <hridya(a)google.com> +Description: This directory will contain information on the attaching device + and the number of current distinct device mappings. + +What: /sys/kernel/dmabuf/buffers/<inode_number>/attachments/<attachment_uid>/device +Date: January 2021 +KernelVersion: v5.12 +Contact: Hridya Valsaraju <hridya(a)google.com> +Description: This file is read-only and is a symlink to the attaching devices's + sysfs entry. + +What: /sys/kernel/dmabuf/buffers/<inode_number>/attachments/<attachment_uid>/map_counter +Date: January 2021 +KernelVersion: v5.12 +Contact: Hridya Valsaraju <hridya(a)google.com> +Description: This file is read-only and contains a map_counter indicating the + number of distinct device mappings of the attachment. diff --git a/drivers/dma-buf/Kconfig b/drivers/dma-buf/Kconfig index 4f8224a6ac95..27e6a2dafeaa 100644 --- a/drivers/dma-buf/Kconfig +++ b/drivers/dma-buf/Kconfig @@ -64,6 +64,17 @@ menuconfig DMABUF_HEAPS allows userspace to allocate dma-bufs that can be shared between drivers. +menuconfig DMABUF_SYSFS_STATS + bool "DMA-BUF sysfs statistics" + select DMA_SHARED_BUFFER + help + Choose this option to enable DMA-BUF sysfs statistics + in location /sys/kernel/dmabuf/buffers. + + /sys/kernel/dmabuf/buffers/<inode_number> will contain + statistics for the DMA-BUF with the unique inode number + <inode_number>. + source "drivers/dma-buf/heaps/Kconfig" endmenu diff --git a/drivers/dma-buf/Makefile b/drivers/dma-buf/Makefile index 995e05f609ff..40d81f23cacf 100644 --- a/drivers/dma-buf/Makefile +++ b/drivers/dma-buf/Makefile @@ -6,6 +6,7 @@ obj-$(CONFIG_DMABUF_HEAPS) += heaps/ obj-$(CONFIG_SYNC_FILE) += sync_file.o obj-$(CONFIG_SW_SYNC) += sw_sync.o sync_debug.o obj-$(CONFIG_UDMABUF) += udmabuf.o +obj-$(CONFIG_DMABUF_SYSFS_STATS) += dma-buf-sysfs-stats.o dmabuf_selftests-y := \ selftest.o \ diff --git a/drivers/dma-buf/dma-buf-sysfs-stats.c b/drivers/dma-buf/dma-buf-sysfs-stats.c new file mode 100644 index 000000000000..5dc2e17f3054 --- /dev/null +++ b/drivers/dma-buf/dma-buf-sysfs-stats.c @@ -0,0 +1,285 @@ +// SPDX-License-Identifier: GPL-2.0-only +/* + * DMA-BUF sysfs statistics. + * + * Copyright (C) 2021 Google LLC. + */ + +#include <linux/dma-buf.h> +#include <linux/dma-resv.h> +#include <linux/kobject.h> +#include <linux/printk.h> +#include <linux/slab.h> +#include <linux/sysfs.h> + +#include "dma-buf-sysfs-stats.h" + +#define to_dma_buf_entry_from_kobj(x) container_of(x, struct dma_buf_sysfs_entry, kobj) + +struct dma_buf_stats_attribute { + struct attribute attr; + ssize_t (*show)(struct dma_buf *dmabuf, + struct dma_buf_stats_attribute *attr, char *buf); +}; +#define to_dma_buf_stats_attr(x) container_of(x, struct dma_buf_stats_attribute, attr) + +static ssize_t dma_buf_stats_attribute_show(struct kobject *kobj, + struct attribute *attr, + char *buf) +{ + struct dma_buf_stats_attribute *attribute; + struct dma_buf_sysfs_entry *sysfs_entry; + struct dma_buf *dmabuf; + + attribute = to_dma_buf_stats_attr(attr); + sysfs_entry = to_dma_buf_entry_from_kobj(kobj); + dmabuf = sysfs_entry->dmabuf; + + if (!dmabuf || !attribute->show) + return -EIO; + + return attribute->show(dmabuf, attribute, buf); +} + +static const struct sysfs_ops dma_buf_stats_sysfs_ops = { + .show = dma_buf_stats_attribute_show, +}; + +static ssize_t exporter_name_show(struct dma_buf *dmabuf, + struct dma_buf_stats_attribute *attr, + char *buf) +{ + return sysfs_emit(buf, "%s\n", dmabuf->exp_name); +} + +static ssize_t size_show(struct dma_buf *dmabuf, + struct dma_buf_stats_attribute *attr, + char *buf) +{ + return sysfs_emit(buf, "%zu\n", dmabuf->size); +} + +static struct dma_buf_stats_attribute exporter_name_attribute = + __ATTR_RO(exporter_name); +static struct dma_buf_stats_attribute size_attribute = __ATTR_RO(size); + +static struct attribute *dma_buf_stats_default_attrs[] = { + &exporter_name_attribute.attr, + &size_attribute.attr, + NULL, +}; +ATTRIBUTE_GROUPS(dma_buf_stats_default); + +static void dma_buf_sysfs_release(struct kobject *kobj) +{ + struct dma_buf_sysfs_entry *sysfs_entry; + + sysfs_entry = to_dma_buf_entry_from_kobj(kobj); + kfree(sysfs_entry); +} + +static struct kobj_type dma_buf_ktype = { + .sysfs_ops = &dma_buf_stats_sysfs_ops, + .release = dma_buf_sysfs_release, + .default_groups = dma_buf_stats_default_groups, +}; + +#define to_dma_buf_attach_entry_from_kobj(x) container_of(x, struct dma_buf_attach_sysfs_entry, kobj) + +struct dma_buf_attach_stats_attribute { + struct attribute attr; + ssize_t (*show)(struct dma_buf_attach_sysfs_entry *sysfs_entry, + struct dma_buf_attach_stats_attribute *attr, char *buf); +}; +#define to_dma_buf_attach_stats_attr(x) container_of(x, struct dma_buf_attach_stats_attribute, attr) + +static ssize_t dma_buf_attach_stats_attribute_show(struct kobject *kobj, + struct attribute *attr, + char *buf) +{ + struct dma_buf_attach_stats_attribute *attribute; + struct dma_buf_attach_sysfs_entry *sysfs_entry; + + attribute = to_dma_buf_attach_stats_attr(attr); + sysfs_entry = to_dma_buf_attach_entry_from_kobj(kobj); + + if (!attribute->show) + return -EIO; + + return attribute->show(sysfs_entry, attribute, buf); +} + +static const struct sysfs_ops dma_buf_attach_stats_sysfs_ops = { + .show = dma_buf_attach_stats_attribute_show, +}; + +static ssize_t map_counter_show(struct dma_buf_attach_sysfs_entry *sysfs_entry, + struct dma_buf_attach_stats_attribute *attr, + char *buf) +{ + return sysfs_emit(buf, "%u\n", sysfs_entry->map_counter); +} + +static struct dma_buf_attach_stats_attribute map_counter_attribute = + __ATTR_RO(map_counter); + +static struct attribute *dma_buf_attach_stats_default_attrs[] = { + &map_counter_attribute.attr, + NULL, +}; +ATTRIBUTE_GROUPS(dma_buf_attach_stats_default); + +static void dma_buf_attach_sysfs_release(struct kobject *kobj) +{ + struct dma_buf_attach_sysfs_entry *sysfs_entry; + + sysfs_entry = to_dma_buf_attach_entry_from_kobj(kobj); + kfree(sysfs_entry); +} + +static struct kobj_type dma_buf_attach_ktype = { + .sysfs_ops = &dma_buf_attach_stats_sysfs_ops, + .release = dma_buf_attach_sysfs_release, + .default_groups = dma_buf_attach_stats_default_groups, +}; + +void dma_buf_attach_stats_teardown(struct dma_buf_attachment *attach) +{ + struct dma_buf_attach_sysfs_entry *sysfs_entry; + + sysfs_entry = attach->sysfs_entry; + if (!sysfs_entry) + return; + + sysfs_delete_link(&sysfs_entry->kobj, &attach->dev->kobj, "device"); + + kobject_del(&sysfs_entry->kobj); + kobject_put(&sysfs_entry->kobj); +} + +int dma_buf_attach_stats_setup(struct dma_buf_attachment *attach, + unsigned int uid) +{ + struct dma_buf_attach_sysfs_entry *sysfs_entry; + int ret; + struct dma_buf *dmabuf; + + if (!attach) + return -EINVAL; + + dmabuf = attach->dmabuf; + + sysfs_entry = kzalloc(sizeof(struct dma_buf_attach_sysfs_entry), + GFP_KERNEL); + if (!sysfs_entry) + return -ENOMEM; + + sysfs_entry->kobj.kset = dmabuf->sysfs_entry->attach_stats_kset; + + attach->sysfs_entry = sysfs_entry; + + ret = kobject_init_and_add(&sysfs_entry->kobj, &dma_buf_attach_ktype, + NULL, "%u", uid); + if (ret) + goto kobj_err; + + ret = sysfs_create_link(&sysfs_entry->kobj, &attach->dev->kobj, + "device"); + if (ret) + goto link_err; + + return 0; + +link_err: + kobject_del(&sysfs_entry->kobj); +kobj_err: + kobject_put(&sysfs_entry->kobj); + attach->sysfs_entry = NULL; + + return ret; +} +void dma_buf_stats_teardown(struct dma_buf *dmabuf) +{ + struct dma_buf_sysfs_entry *sysfs_entry; + + sysfs_entry = dmabuf->sysfs_entry; + if (!sysfs_entry) + return; + + kset_unregister(sysfs_entry->attach_stats_kset); + kobject_del(&sysfs_entry->kobj); + kobject_put(&sysfs_entry->kobj); +} + +static struct kset *dma_buf_stats_kset; +static struct kset *dma_buf_per_buffer_stats_kset; +int dma_buf_init_sysfs_statistics(void) +{ + dma_buf_stats_kset = kset_create_and_add("dmabuf", NULL, kernel_kobj); + if (!dma_buf_stats_kset) + return -ENOMEM; + + dma_buf_per_buffer_stats_kset = kset_create_and_add("buffers", NULL, + &dma_buf_stats_kset->kobj); + if (!dma_buf_per_buffer_stats_kset) { + kset_unregister(dma_buf_stats_kset); + return -ENOMEM; + } + + return 0; +} + +void dma_buf_uninit_sysfs_statistics(void) +{ + kset_unregister(dma_buf_per_buffer_stats_kset); + kset_unregister(dma_buf_stats_kset); +} + +int dma_buf_stats_setup(struct dma_buf *dmabuf) +{ + struct dma_buf_sysfs_entry *sysfs_entry; + int ret; + struct kset *attach_stats_kset; + + if (!dmabuf || !dmabuf->file) + return -EINVAL; + + if (!dmabuf->exp_name) { + pr_err("exporter name must not be empty if stats needed\n"); + return -EINVAL; + } + + sysfs_entry = kzalloc(sizeof(struct dma_buf_sysfs_entry), GFP_KERNEL); + if (!sysfs_entry) + return -ENOMEM; + + sysfs_entry->kobj.kset = dma_buf_per_buffer_stats_kset; + sysfs_entry->dmabuf = dmabuf; + + dmabuf->sysfs_entry = sysfs_entry; + + /* create the directory for buffer stats */ + ret = kobject_init_and_add(&sysfs_entry->kobj, &dma_buf_ktype, NULL, + "%lu", file_inode(dmabuf->file)->i_ino); + if (ret) + goto err_sysfs_dmabuf; + + /* create the directory for attachment stats */ + attach_stats_kset = kset_create_and_add("attachments", NULL, + &sysfs_entry->kobj); + if (!attach_stats_kset) { + ret = -ENOMEM; + goto err_sysfs_attach; + } + + sysfs_entry->attach_stats_kset = attach_stats_kset; + + return 0; + +err_sysfs_attach: + kobject_del(&sysfs_entry->kobj); +err_sysfs_dmabuf: + kobject_put(&sysfs_entry->kobj); + dmabuf->sysfs_entry = NULL; + return ret; +} diff --git a/drivers/dma-buf/dma-buf-sysfs-stats.h b/drivers/dma-buf/dma-buf-sysfs-stats.h new file mode 100644 index 000000000000..5f4703249117 --- /dev/null +++ b/drivers/dma-buf/dma-buf-sysfs-stats.h @@ -0,0 +1,62 @@ +/* SPDX-License-Identifier: GPL-2.0-only */ +/* + * DMA-BUF sysfs statistics. + * + * Copyright (C) 2021 Google LLC. + */ + +#ifndef _DMA_BUF_SYSFS_STATS_H +#define _DMA_BUF_SYSFS_STATS_H + +#ifdef CONFIG_DMABUF_SYSFS_STATS + +int dma_buf_init_sysfs_statistics(void); +void dma_buf_uninit_sysfs_statistics(void); + +int dma_buf_stats_setup(struct dma_buf *dmabuf); +int dma_buf_attach_stats_setup(struct dma_buf_attachment *attach, + unsigned int uid); +static inline void dma_buf_update_attachment_map_count(struct dma_buf_attachment *attach, + int delta) +{ + struct dma_buf_attach_sysfs_entry *entry = attach->sysfs_entry; + + entry->map_counter += delta; +} +void dma_buf_stats_teardown(struct dma_buf *dmabuf); +void dma_buf_attach_stats_teardown(struct dma_buf_attachment *attach); +static inline unsigned int dma_buf_update_attach_uid(struct dma_buf *dmabuf) +{ + struct dma_buf_sysfs_entry *entry = dmabuf->sysfs_entry; + + return entry->attachment_uid++; +} +#else + +static inline int dma_buf_init_sysfs_statistics(void) +{ + return 0; +} + +static inline void dma_buf_uninit_sysfs_statistics(void) {} + +static inline int dma_buf_stats_setup(struct dma_buf *dmabuf) +{ + return 0; +} +static inline int dma_buf_attach_stats_setup(struct dma_buf_attachment *attach, + unsigned int uid) +{ + return 0; +} + +static inline void dma_buf_stats_teardown(struct dma_buf *dmabuf) {} +static inline void dma_buf_attach_stats_teardown(struct dma_buf_attachment *attach) {} +static inline void dma_buf_update_attachment_map_count(struct dma_buf_attachment *attach, + int delta) {} +static inline unsigned int dma_buf_update_attach_uid(struct dma_buf *dmabuf) +{ + return 0; +} +#endif +#endif // _DMA_BUF_SYSFS_STATS_H diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c index 9ad6397aaa97..29f9ea18eb47 100644 --- a/drivers/dma-buf/dma-buf.c +++ b/drivers/dma-buf/dma-buf.c @@ -29,6 +29,8 @@ #include <uapi/linux/dma-buf.h> #include <uapi/linux/magic.h> +#include "dma-buf-sysfs-stats.h" + static inline int is_dma_buf_file(struct file *); struct dma_buf_list { @@ -79,6 +81,7 @@ static void dma_buf_release(struct dentry *dentry) if (dmabuf->resv == (struct dma_resv *)&dmabuf[1]) dma_resv_fini(dmabuf->resv); + dma_buf_stats_teardown(dmabuf); module_put(dmabuf->owner); kfree(dmabuf->name); kfree(dmabuf); @@ -579,6 +582,10 @@ struct dma_buf *dma_buf_export(const struct dma_buf_export_info *exp_info) file->f_mode |= FMODE_LSEEK; dmabuf->file = file; + ret = dma_buf_stats_setup(dmabuf); + if (ret) + goto err_sysfs; + mutex_init(&dmabuf->lock); INIT_LIST_HEAD(&dmabuf->attachments); @@ -588,6 +595,14 @@ struct dma_buf *dma_buf_export(const struct dma_buf_export_info *exp_info) return dmabuf; +err_sysfs: + /* + * Set file->f_path.dentry->d_fsdata to NULL so that when + * dma_buf_release() gets invoked by dentry_ops, it exits + * early before calling the release() dma_buf op. + */ + file->f_path.dentry->d_fsdata = NULL; + fput(file); err_dmabuf: kfree(dmabuf); err_module: @@ -692,6 +707,7 @@ dma_buf_dynamic_attach(struct dma_buf *dmabuf, struct device *dev, { struct dma_buf_attachment *attach; int ret; + unsigned int attach_uid; if (WARN_ON(!dmabuf || !dev)) return ERR_PTR(-EINVAL); @@ -717,8 +733,13 @@ dma_buf_dynamic_attach(struct dma_buf *dmabuf, struct device *dev, } dma_resv_lock(dmabuf->resv, NULL); list_add(&attach->node, &dmabuf->attachments); + attach_uid = dma_buf_update_attach_uid(dmabuf); dma_resv_unlock(dmabuf->resv); + ret = dma_buf_attach_stats_setup(attach, attach_uid); + if (ret) + goto err_sysfs; + /* When either the importer or the exporter can't handle dynamic * mappings we cache the mapping here to avoid issues with the * reservation object lock. @@ -745,6 +766,7 @@ dma_buf_dynamic_attach(struct dma_buf *dmabuf, struct device *dev, dma_resv_unlock(attach->dmabuf->resv); attach->sgt = sgt; attach->dir = DMA_BIDIRECTIONAL; + dma_buf_update_attachment_map_count(attach, 1 /* delta */); } return attach; @@ -761,6 +783,7 @@ dma_buf_dynamic_attach(struct dma_buf *dmabuf, struct device *dev, if (dma_buf_is_dynamic(attach->dmabuf)) dma_resv_unlock(attach->dmabuf->resv); +err_sysfs: dma_buf_detach(dmabuf, attach); return ERR_PTR(ret); } @@ -799,6 +822,7 @@ void dma_buf_detach(struct dma_buf *dmabuf, struct dma_buf_attachment *attach) dma_resv_lock(attach->dmabuf->resv, NULL); dmabuf->ops->unmap_dma_buf(attach, attach->sgt, attach->dir); + dma_buf_update_attachment_map_count(attach, -1 /* delta */); if (dma_buf_is_dynamic(attach->dmabuf)) { dma_buf_unpin(attach); @@ -812,6 +836,7 @@ void dma_buf_detach(struct dma_buf *dmabuf, struct dma_buf_attachment *attach) if (dmabuf->ops->detach) dmabuf->ops->detach(dmabuf, attach); + dma_buf_attach_stats_teardown(attach); kfree(attach); } EXPORT_SYMBOL_GPL(dma_buf_detach); @@ -938,6 +963,9 @@ struct sg_table *dma_buf_map_attachment(struct dma_buf_attachment *attach, } #endif /* CONFIG_DMA_API_DEBUG */ + if (!IS_ERR(sg_table)) + dma_buf_update_attachment_map_count(attach, 1 /* delta */); + return sg_table; } EXPORT_SYMBOL_GPL(dma_buf_map_attachment); @@ -975,6 +1003,8 @@ void dma_buf_unmap_attachment(struct dma_buf_attachment *attach, if (dma_buf_is_dynamic(attach->dmabuf) && !IS_ENABLED(CONFIG_DMABUF_MOVE_NOTIFY)) dma_buf_unpin(attach); + + dma_buf_update_attachment_map_count(attach, -1 /* delta */); } EXPORT_SYMBOL_GPL(dma_buf_unmap_attachment); @@ -1412,6 +1442,12 @@ static inline void dma_buf_uninit_debugfs(void) static int __init dma_buf_init(void) { + int ret; + + ret = dma_buf_init_sysfs_statistics(); + if (ret) + return ret; + dma_buf_mnt = kern_mount(&dma_buf_fs_type); if (IS_ERR(dma_buf_mnt)) return PTR_ERR(dma_buf_mnt); @@ -1427,5 +1463,6 @@ static void __exit dma_buf_deinit(void) { dma_buf_uninit_debugfs(); kern_unmount(dma_buf_mnt); + dma_buf_uninit_sysfs_statistics(); } __exitcall(dma_buf_deinit); diff --git a/include/linux/dma-buf.h b/include/linux/dma-buf.h index cf72699cb2bc..4ae5cc38a4a7 100644 --- a/include/linux/dma-buf.h +++ b/include/linux/dma-buf.h @@ -294,6 +294,9 @@ struct dma_buf_ops { * @poll: for userspace poll support * @cb_excl: for userspace poll support * @cb_shared: for userspace poll support + * @sysfs_entry: for exposing information about this buffer in sysfs. + * The attachment_uid member of @sysfs_entry is protected by dma_resv lock + * and is incremented on each attach. * * This represents a shared buffer, created by calling dma_buf_export(). The * userspace representation is a normal file descriptor, which can be created by @@ -329,6 +332,15 @@ struct dma_buf { __poll_t active; } cb_excl, cb_shared; +#ifdef CONFIG_DMABUF_SYSFS_STATS + /* for sysfs stats */ + struct dma_buf_sysfs_entry { + struct kobject kobj; + struct dma_buf *dmabuf; + unsigned int attachment_uid; + struct kset *attach_stats_kset; + } *sysfs_entry; +#endif }; /** @@ -378,6 +390,7 @@ struct dma_buf_attach_ops { * @importer_ops: importer operations for this attachment, if provided * dma_buf_map/unmap_attachment() must be called with the dma_resv lock held. * @importer_priv: importer specific attachment data. + * @sysfs_entry: For exposing information about this attachment in sysfs. * * This structure holds the attachment information between the dma_buf buffer * and its user device(s). The list contains one attachment struct per device @@ -398,6 +411,13 @@ struct dma_buf_attachment { const struct dma_buf_attach_ops *importer_ops; void *importer_priv; void *priv; +#ifdef CONFIG_DMABUF_SYSFS_STATS + /* for sysfs stats */ + struct dma_buf_attach_sysfs_entry { + struct kobject kobj; + unsigned int map_counter; + } *sysfs_entry; +#endif }; /** -- 2.30.0.280.ga3ce27912f-goog

4 years, 10 months

6
10
0 0

[PATCH 0/2] Allow reading process DMA buf stats from fdinfo

by Kalesh Singh

Android captures per-process system memory state when certain low memory events (e.g a foreground app kill) occur, to identify potential memory hoggers. In order to measure how much memory a process actually consumes, it is necessary to include the DMA buffer sizes for that process in the memory accounting. Since the handle to DMA buffers are raw FDs, it is important to be able to identify which processes have FD references to a DMA buffer. Currently, DMA buffer FDs can be accounted using /proc/<pid>/fd/* and /proc/<pid>/fdinfo -- both are only readable by the process owner, as follows: 1. Do a readlink on each FD. 2. If the target path begins with "/dmabuf", then the FD is a dmabuf FD. 3. stat the file to get the dmabuf inode number. 4. Read/ proc/<pid>/fdinfo/<fd>, to get the DMA buffer size. Accessing other processes’ fdinfo requires root privileges. This limits the use of the interface to debugging environments and is not suitable for production builds. Granting root privileges even to a system process increases the attack surface and is highly undesirable. This series proposes making the requirement to read fdinfo less strict with PTRACE_MODE_READ. Kalesh Singh (2): procfs: Allow reading fdinfo with PTRACE_MODE_READ dmabuf: Add dmabuf inode no to fdinfo drivers/dma-buf/dma-buf.c | 1 + fs/proc/base.c | 4 ++-- fs/proc/fd.c | 15 ++++++++++++++- 3 files changed, 17 insertions(+), 3 deletions(-) -- 2.30.0.365.g02bc693789-goog

4 years, 10 months

3
8
0 0

Re: [Linaro-mm-sig] [PATCH] drm/todo: Add entry for moving to dma_resv_lock

by Daniel Vetter

On Fri, Jan 22, 2021 at 03:06:44PM +0100, Thomas Zimmermann wrote: > Hi > > Am 22.01.21 um 14:36 schrieb Daniel Vetter: > > Requested by Thomas. I think it justifies a new level, since I tried > > to make some forward progress on this last summer, and gave up (for > > now). This is very tricky. > > Adding it to the TODO list is a first step. :) > > Acked-by: Thomas Zimmermann <tzimmermann(a)suse.de> Applied. -Daniel > > > > > Signed-off-by: Daniel Vetter <daniel.vetter(a)intel.com> > > Cc: Maarten Lankhorst <maarten.lankhorst(a)linux.intel.com> > > Cc: Maxime Ripard <mripard(a)kernel.org> > > Cc: Thomas Zimmermann <tzimmermann(a)suse.de> > > Cc: David Airlie <airlied(a)linux.ie> > > Cc: Daniel Vetter <daniel(a)ffwll.ch> > > Cc: Sumit Semwal <sumit.semwal(a)linaro.org> > > Cc: "Christian König" <christian.koenig(a)amd.com> > > Cc: linux-media(a)vger.kernel.org > > Cc: linaro-mm-sig(a)lists.linaro.org > > --- > > Documentation/gpu/todo.rst | 19 +++++++++++++++++++ > > 1 file changed, 19 insertions(+) > > > > diff --git a/Documentation/gpu/todo.rst b/Documentation/gpu/todo.rst > > index dea9082c0e5f..f872d3d33218 100644 > > --- a/Documentation/gpu/todo.rst > > +++ b/Documentation/gpu/todo.rst > > @@ -23,6 +23,9 @@ Advanced: Tricky tasks that need fairly good understanding of the DRM subsystem > > and graphics topics. Generally need the relevant hardware for development and > > testing. > > +Expert: Only attempt these if you've successfully completed some tricky > > +refactorings already and are an expert in the specific area > > + > > Subsystem-wide refactorings > > =========================== > > @@ -168,6 +171,22 @@ Contact: Daniel Vetter, respective driver maintainers > > Level: Advanced > > +Move Buffer Object Locking to dma_resv_lock() > > +--------------------------------------------- > > + > > +Many drivers have their own per-object locking scheme, usually using > > +mutex_lock(). This causes all kinds of trouble for buffer sharing, since > > +depending which driver is the exporter and importer, the locking hierarchy is > > +reversed. > > + > > +To solve this we need one standard per-object locking mechanism, which is > > +dma_resv_lock(). This lock needs to be called as the outermost lock, with all > > +other driver specific per-object locks removed. The problem is tha rolling out > > +the actual change to the locking contract is a flag day, due to struct dma_buf > > +buffer sharing. > > + > > +Level: Expert > > + > > Convert logging to drm_* functions with drm_device paramater > > ------------------------------------------------------------ > > > > -- > Thomas Zimmermann > Graphics Driver Developer > SUSE Software Solutions Germany GmbH > Maxfeldstr. 5, 90409 Nürnberg, Germany > (HRB 36809, AG Nürnberg) > Geschäftsführer: Felix Imendörffer > -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch

4 years, 10 months

1
0
0 0

Re: [Linaro-mm-sig] [PATCH 08/29] dma-buf: Avoid comma separated statements

by Christian König

Am 30.01.21 um 19:47 schrieb Joe Perches: > On Mon, 2020-08-24 at 21:56 -0700, Joe Perches wrote: >> Use semicolons and braces. > Ping? > >> Signed-off-by: Joe Perches <joe(a)perches.com> Reviewed-by: Christian König <christian.koenig(a)amd.com> Do you have commit rights to drm-misc-next? >> --- >> drivers/dma-buf/st-dma-fence.c | 7 +++++-- >> 1 file changed, 5 insertions(+), 2 deletions(-) >> >> diff --git a/drivers/dma-buf/st-dma-fence.c b/drivers/dma-buf/st-dma-fence.c >> index e593064341c8..c8a12d7ad71a 100644 >> --- a/drivers/dma-buf/st-dma-fence.c >> +++ b/drivers/dma-buf/st-dma-fence.c >> @@ -471,8 +471,11 @@ static int thread_signal_callback(void *arg) >> dma_fence_signal(f1); >> >> >> smp_store_mb(cb.seen, false); >> - if (!f2 || dma_fence_add_callback(f2, &cb.cb, simple_callback)) >> - miss++, cb.seen = true; >> + if (!f2 || >> + dma_fence_add_callback(f2, &cb.cb, simple_callback)) { >> + miss++; >> + cb.seen = true; >> + } >> >> >> if (!t->before) >> dma_fence_signal(f1); >

4 years, 10 months

3
3
0 0

[PATCH 1/1] dma-buf: heaps: Map system heap pages as managed by linux vm

by Suren Baghdasaryan

Currently system heap maps its buffers with VM_PFNMAP flag using remap_pfn_range. This results in such buffers not being accounted for in PSS calculations because vm treats this memory as having no page structs. Without page structs there are no counters representing how many processes are mapping a page and therefore PSS calculation is impossible. Historically, ION driver used to map its buffers as VM_PFNMAP areas due to memory carveouts that did not have page structs [1]. That is not the case anymore and it seems there was desire to move away from remap_pfn_range [2]. Dmabuf system heap design inherits this ION behavior and maps its pages using remap_pfn_range even though allocated pages are backed by page structs. Clear VM_IO and VM_PFNMAP flags when mapping memory allocated by the system heap and replace remap_pfn_range with vm_insert_page, following Laura's suggestion in [1]. This would allow correct PSS calculation for dmabufs. [1] https://driverdev-devel.linuxdriverproject.narkive.com/v0fJGpaD/using-ion-m… [2] http://driverdev.linuxdriverproject.org/pipermail/driverdev-devel/2018-Octo… (sorry, could not find lore links for these discussions) Suggested-by: Laura Abbott <labbott(a)kernel.org> Signed-off-by: Suren Baghdasaryan <surenb(a)google.com> --- drivers/dma-buf/heaps/system_heap.c | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/drivers/dma-buf/heaps/system_heap.c b/drivers/dma-buf/heaps/system_heap.c index 17e0e9a68baf..0e92e42b2251 100644 --- a/drivers/dma-buf/heaps/system_heap.c +++ b/drivers/dma-buf/heaps/system_heap.c @@ -200,11 +200,13 @@ static int system_heap_mmap(struct dma_buf *dmabuf, struct vm_area_struct *vma) struct sg_page_iter piter; int ret; + /* All pages are backed by a "struct page" */ + vma->vm_flags &= ~VM_PFNMAP; + for_each_sgtable_page(table, &piter, vma->vm_pgoff) { struct page *page = sg_page_iter_page(&piter); - ret = remap_pfn_range(vma, addr, page_to_pfn(page), PAGE_SIZE, - vma->vm_page_prot); + ret = vm_insert_page(vma, addr, page); if (ret) return ret; addr += PAGE_SIZE; -- 2.30.0.280.ga3ce27912f-goog

4 years, 10 months

3
10
0 0

[PATCH] RFC: dma-fence: Document recoverable page fault implications

by Daniel Vetter

Recently there was a fairly long thread about recoreable hardware page faults, how they can deadlock, and what to do about that. While the discussion is still fresh I figured good time to try and document the conclusions a bit. References: https://lore.kernel.org/dri-devel/20210107030127.20393-1-Felix.Kuehling@amd… Cc: Maarten Lankhorst <maarten.lankhorst(a)linux.intel.com> Cc: Thomas Hellström <thomas.hellstrom(a)intel.com> Cc: "Christian König" <christian.koenig(a)amd.com> Cc: Jerome Glisse <jglisse(a)redhat.com> Cc: Felix Kuehling <felix.kuehling(a)amd.com> Signed-off-by: Daniel Vetter <daniel.vetter(a)intel.com> Cc: Sumit Semwal <sumit.semwal(a)linaro.org> Cc: linux-media(a)vger.kernel.org Cc: linaro-mm-sig(a)lists.linaro.org -- I'll be away next week, but figured I'll type this up quickly for some comments and to check whether I got this all roughly right. Critique very much wanted on this, so that we can make sure hw which can't preempt (with pagefaults pending) like gfx10 has a clear path to support page faults in upstream. So anything I missed, got wrong or like that would be good. -Daniel --- Documentation/driver-api/dma-buf.rst | 66 ++++++++++++++++++++++++++++ 1 file changed, 66 insertions(+) diff --git a/Documentation/driver-api/dma-buf.rst b/Documentation/driver-api/dma-buf.rst index a2133d69872c..e924c1e4f7a3 100644 --- a/Documentation/driver-api/dma-buf.rst +++ b/Documentation/driver-api/dma-buf.rst @@ -257,3 +257,69 @@ fences in the kernel. This means: userspace is allowed to use userspace fencing or long running compute workloads. This also means no implicit fencing for shared buffers in these cases. + +Recoverable Hardware Page Faults Implications +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +Modern hardware supports recoverable page faults, which has a lot of +implications for DMA fences. + +First, a pending page fault obviously holds up the work that's running on the +accelerator and a memory allocation is usually required to resolve the fault. +But memory allocations are not allowed to gate completion of DMA fences, which +means any workload using recoverable page faults cannot use DMA fences for +synchronization. Synchronization fences controlled by userspace must be used +instead. + +On GPUs this poses a problem, because current desktop compositor protocols on +Linus rely on DMA fences, which means without an entirely new userspace stack +built on top of userspace fences, they cannot benefit from recoverable page +faults. The exception is when page faults are only used as migration hints and +never to on-demand fill a memory request. For now this means recoverable page +faults on GPUs are limited to pure compute workloads. + +Furthermore GPUs usually have shared resources between the 3D rendering and +compute side, like compute units or command submission engines. If both a 3D +job with a DMA fence and a compute workload using recoverable page faults are +pending they could deadlock: + +- The 3D workload might need to wait for the compute job to finish and release + hardware resources first. + +- The compute workload might be stuck in a page fault, because the memory + allocation is waiting for the DMA fence of the 3D workload to complete. + +There are a few ways to prevent this problem: + +- Compute workloads can always be preempted, even when a page fault is pending + and not yet repaired. Not all hardware supports this. + +- DMA fence workloads and workloads which need page fault handling have + independent hardware resources to guarantee forward progress. This could be + achieved through e.g. through dedicated engines and minimal compute unit + reservations for DMA fence workloads. + +- The reservation approach could be further refined by only reserving the + hardware resources for DMA fence workloads when they are in-flight. This must + cover the time from when the DMA fence is visible to other threads up to + moment when fence is completed through dma_fence_signal(). + +- As a last resort, if the hardware provides no useful reservation mechanics, + all workloads must be flushed from the GPU when switching between jobs + requiring DMA fences or jobs requiring page fault handling: This means all DMA + fences must complete before a compute job with page fault handling can be + inserted into the scheduler queue. And vice versa, before a DMA fence can be + made visible anywhere in the system, all compute workloads must be preempted + to guarantee all pending GPU page faults are flushed. + +Note that workloads that run on independent hardware like copy engines or other +GPUs do not have any impact. This allows us to keep using DMA fences internally +in the kernel even for resolving hardware page faults, e.g. by using copy +engines to clear or copy memory needed to resolve the page fault. + +In some ways this page fault problem is a special case of the `Infinite DMA +Fences` discussions: Infinite fences from compute workloads are allowed to +depend on DMA fences, but not the other way around. And not even the page fault +problem is new, because some other CPU thread in userspace might +hit a page fault which holds up a userspace fence - supporting page faults on +GPUs doesn't anything fundamentally new. -- 2.30.0

4 years, 10 months

6
13
0 0

Re: [Linaro-mm-sig] [PATCH v4 04/13] drm/shmem-helper: Provide a vmap function for short-term mappings

by Daniel Vetter

On Wed, Jan 27, 2021 at 01:08:05PM +0100, Thomas Zimmermann wrote: > Hi > > Am 11.01.21 um 17:50 schrieb Daniel Vetter: > > On Fri, Jan 08, 2021 at 10:43:31AM +0100, Thomas Zimmermann wrote: > > > Implementations of the vmap/vunmap GEM callbacks may perform pinning > > > of the BO and may acquire the associated reservation object's lock. > > > Callers that only require a mapping of the contained memory can thus > > > interfere with other tasks that require exact pinning, such as scanout. > > > This is less of an issue with private SHMEM buffers, but may happen > > > with imported ones. > > > > > > Therefore provide the new interfaces drm_gem_shmem_vmap_local() and > > > drm_gem_shmem_vunmap_local(), which only perform the vmap/vunmap > > > operations. Callers have to hold the reservation lock while the mapping > > > persists. > > > > > > This patch also connects GEM SHMEM helpers to GEM object functions with > > > equivalent functionality. > > > > > > v4: > > > * call dma_buf_{vmap,vunmap}_local() where necessary (Daniel) > > > * move driver changes into separate patches (Daniel) > > > > > > Signed-off-by: Thomas Zimmermann <tzimmermann(a)suse.de> > > > --- > > > drivers/gpu/drm/drm_gem_shmem_helper.c | 90 +++++++++++++++++++++++--- > > > include/drm/drm_gem_shmem_helper.h | 2 + > > > 2 files changed, 84 insertions(+), 8 deletions(-) > > > > > > diff --git a/drivers/gpu/drm/drm_gem_shmem_helper.c b/drivers/gpu/drm/drm_gem_shmem_helper.c > > > index 9825c378dfa6..298832b2b43b 100644 > > > --- a/drivers/gpu/drm/drm_gem_shmem_helper.c > > > +++ b/drivers/gpu/drm/drm_gem_shmem_helper.c > > > @@ -32,6 +32,8 @@ static const struct drm_gem_object_funcs drm_gem_shmem_funcs = { > > > .get_sg_table = drm_gem_shmem_get_sg_table, > > > .vmap = drm_gem_shmem_vmap, > > > .vunmap = drm_gem_shmem_vunmap, > > > + .vmap_local = drm_gem_shmem_vmap_local, > > > + .vunmap_local = drm_gem_shmem_vunmap_local, > > > .mmap = drm_gem_shmem_mmap, > > > }; > > > @@ -261,7 +263,8 @@ void drm_gem_shmem_unpin(struct drm_gem_object *obj) > > > } > > > EXPORT_SYMBOL(drm_gem_shmem_unpin); > > > -static int drm_gem_shmem_vmap_locked(struct drm_gem_shmem_object *shmem, struct dma_buf_map *map) > > > +static int drm_gem_shmem_vmap_locked(struct drm_gem_shmem_object *shmem, struct dma_buf_map *map, > > > + bool local) > > > > This is a bit spaghetti and also has the problem that we're not changing > > shmem->vmap_use_count under different locks, depending upon which path > > we're taking. > > > > I think the cleanest would be if we pull the if (import_attach) case out > > of the _locked() version completely, for all cases, and also outside of > > the shmem->vmap_lock. This means no caching of vmaps in the shmem layer > > anymore for imported buffers, but this is no longer a problem: We cache > > them in the exporters instead (I think at least, if not maybe need to fix > > that where it's expensive). > > There's no vmap refcounting in amdgpu AFAICT. So importing pages from there > into an SHMEM object has the potential of breaking. IIRC same fro radeon and > nouveau. As long as the pinning is refcounted I think it should be fine, it's just that if you have multiple vmaps (e.g. 2 udl devices plugged in) we'll set up 2 vmaps. Which is a point pointless, but not really harmful. At least on 64bit where there's enough virtual address space. > So I'm somewhat reluctant to making this change. I guess I'll look elsewhere > first to fix some of the locking issues (e.g., my recent ast cursor > patches). If this would break for amdgpu/radeon/nouveau then we already have a bug, since 2 udl devices can provoke this issue already as-is. So I don't think this should be a blocker. -Daniel > > Best regards > Thomas > > > > > Other option would be to unly pull it out for the _vmap_local case, but > > that's a bit ugly because no longer symmetrical in the various paths. > > > > > { > > > struct drm_gem_object *obj = &shmem->base; > > > int ret = 0; > > > @@ -272,7 +275,10 @@ static int drm_gem_shmem_vmap_locked(struct drm_gem_shmem_object *shmem, struct > > > } > > > if (obj->import_attach) { > > > - ret = dma_buf_vmap(obj->import_attach->dmabuf, map); > > > + if (local) > > > + ret = dma_buf_vmap_local(obj->import_attach->dmabuf, map); > > > + else > > > + ret = dma_buf_vmap(obj->import_attach->dmabuf, map); > > > if (!ret) { > > > if (WARN_ON(map->is_iomem)) { > > > ret = -EIO; > > > @@ -313,7 +319,7 @@ static int drm_gem_shmem_vmap_locked(struct drm_gem_shmem_object *shmem, struct > > > return ret; > > > } > > > -/* > > > +/** > > > * drm_gem_shmem_vmap - Create a virtual mapping for a shmem GEM object > > > * @shmem: shmem GEM object > > > * @map: Returns the kernel virtual address of the SHMEM GEM object's backing > > > @@ -339,15 +345,53 @@ int drm_gem_shmem_vmap(struct drm_gem_object *obj, struct dma_buf_map *map) > > > ret = mutex_lock_interruptible(&shmem->vmap_lock); > > > if (ret) > > > return ret; > > > - ret = drm_gem_shmem_vmap_locked(shmem, map); > > > + ret = drm_gem_shmem_vmap_locked(shmem, map, false); > > > mutex_unlock(&shmem->vmap_lock); > > > return ret; > > > } > > > EXPORT_SYMBOL(drm_gem_shmem_vmap); > > > +/** > > > + * drm_gem_shmem_vmap_local - Create a virtual mapping for a shmem GEM object > > > + * @shmem: shmem GEM object > > > + * @map: Returns the kernel virtual address of the SHMEM GEM object's backing > > > + * store. > > > + * > > > + * This function makes sure that a contiguous kernel virtual address mapping > > > + * exists for the buffer backing the shmem GEM object. > > > + * > > > + * The function is called with the BO's reservation object locked. Callers must > > > + * hold the lock until after unmapping the buffer. > > > + * > > > + * This function can be used to implement &drm_gem_object_funcs.vmap_local. But > > > + * it can also be called by drivers directly, in which case it will hide the > > > + * differences between dma-buf imported and natively allocated objects. > > > > So for the other callbacks I tried to make sure we have different entry > > points for this, since it's not really the same thing and because of the > > locking mess we have with dma_resv_lock vs various pre-existing local > > locking scheme, it's easy to get a mess. > > > > I think the super clean version here would be to also export just the > > internal stuff for the ->v(un)map_local hooks, but that's maybe a bit too > > much boilerplate for no real gain. > > -Daniel > > > > > + * > > > + * Acquired mappings should be cleaned up by calling drm_gem_shmem_vunmap_local(). > > > + * > > > + * Returns: > > > + * 0 on success or a negative error code on failure. > > > + */ > > > +int drm_gem_shmem_vmap_local(struct drm_gem_object *obj, struct dma_buf_map *map) > > > +{ > > > + struct drm_gem_shmem_object *shmem = to_drm_gem_shmem_obj(obj); > > > + int ret; > > > + > > > + dma_resv_assert_held(obj->resv); > > > + > > > + ret = mutex_lock_interruptible(&shmem->vmap_lock); > > > + if (ret) > > > + return ret; > > > + ret = drm_gem_shmem_vmap_locked(shmem, map, true); > > > + mutex_unlock(&shmem->vmap_lock); > > > + > > > + return ret; > > > +} > > > +EXPORT_SYMBOL(drm_gem_shmem_vmap_local); > > > + > > > static void drm_gem_shmem_vunmap_locked(struct drm_gem_shmem_object *shmem, > > > - struct dma_buf_map *map) > > > + struct dma_buf_map *map, bool local) > > > { > > > struct drm_gem_object *obj = &shmem->base; > > > @@ -358,7 +402,10 @@ static void drm_gem_shmem_vunmap_locked(struct drm_gem_shmem_object *shmem, > > > return; > > > if (obj->import_attach) > > > - dma_buf_vunmap(obj->import_attach->dmabuf, map); > > > + if (local) > > > + dma_buf_vunmap_local(obj->import_attach->dmabuf, map); > > > + else > > > + dma_buf_vunmap(obj->import_attach->dmabuf, map); > > > else > > > vunmap(shmem->vaddr); > > > @@ -366,7 +413,7 @@ static void drm_gem_shmem_vunmap_locked(struct drm_gem_shmem_object *shmem, > > > drm_gem_shmem_put_pages(shmem); > > > } > > > -/* > > > +/** > > > * drm_gem_shmem_vunmap - Unmap a virtual mapping fo a shmem GEM object > > > * @shmem: shmem GEM object > > > * @map: Kernel virtual address where the SHMEM GEM object was mapped > > > @@ -384,11 +431,38 @@ void drm_gem_shmem_vunmap(struct drm_gem_object *obj, struct dma_buf_map *map) > > > struct drm_gem_shmem_object *shmem = to_drm_gem_shmem_obj(obj); > > > mutex_lock(&shmem->vmap_lock); > > > - drm_gem_shmem_vunmap_locked(shmem, map); > > > + drm_gem_shmem_vunmap_locked(shmem, map, false); > > > mutex_unlock(&shmem->vmap_lock); > > > } > > > EXPORT_SYMBOL(drm_gem_shmem_vunmap); > > > +/** > > > + * drm_gem_shmem_vunmap_local - Unmap a virtual mapping fo a shmem GEM object > > > + * @shmem: shmem GEM object > > > + * @map: Kernel virtual address where the SHMEM GEM object was mapped > > > + * > > > + * This function cleans up a kernel virtual address mapping acquired by > > > + * drm_gem_shmem_vmap_local(). The mapping is only removed when the use count > > > + * drops to zero. > > > + * > > > + * The function is called with the BO's reservation object locked. > > > + * > > > + * This function can be used to implement &drm_gem_object_funcs.vmap_local. > > > + * But it can also be called by drivers directly, in which case it will hide > > > + * the differences between dma-buf imported and natively allocated objects. > > > + */ > > > +void drm_gem_shmem_vunmap_local(struct drm_gem_object *obj, struct dma_buf_map *map) > > > +{ > > > + struct drm_gem_shmem_object *shmem = to_drm_gem_shmem_obj(obj); > > > + > > > + dma_resv_assert_held(obj->resv); > > > + > > > + mutex_lock(&shmem->vmap_lock); > > > + drm_gem_shmem_vunmap_locked(shmem, map, true); > > > + mutex_unlock(&shmem->vmap_lock); > > > +} > > > +EXPORT_SYMBOL(drm_gem_shmem_vunmap_local); > > > + > > > struct drm_gem_shmem_object * > > > drm_gem_shmem_create_with_handle(struct drm_file *file_priv, > > > struct drm_device *dev, size_t size, > > > diff --git a/include/drm/drm_gem_shmem_helper.h b/include/drm/drm_gem_shmem_helper.h > > > index 434328d8a0d9..3f59bdf749aa 100644 > > > --- a/include/drm/drm_gem_shmem_helper.h > > > +++ b/include/drm/drm_gem_shmem_helper.h > > > @@ -114,7 +114,9 @@ void drm_gem_shmem_put_pages(struct drm_gem_shmem_object *shmem); > > > int drm_gem_shmem_pin(struct drm_gem_object *obj); > > > void drm_gem_shmem_unpin(struct drm_gem_object *obj); > > > int drm_gem_shmem_vmap(struct drm_gem_object *obj, struct dma_buf_map *map); > > > +int drm_gem_shmem_vmap_local(struct drm_gem_object *obj, struct dma_buf_map *map); > > > void drm_gem_shmem_vunmap(struct drm_gem_object *obj, struct dma_buf_map *map); > > > +void drm_gem_shmem_vunmap_local(struct drm_gem_object *obj, struct dma_buf_map *map); > > > int drm_gem_shmem_madvise(struct drm_gem_object *obj, int madv); > > > -- > > > 2.29.2 > > > > > > > -- > Thomas Zimmermann > Graphics Driver Developer > SUSE Software Solutions Germany GmbH > Maxfeldstr. 5, 90409 Nürnberg, Germany > (HRB 36809, AG Nürnberg) > Geschäftsführer: Felix Imendörffer > -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch

4 years, 10 months

1
0
0 0

Re: [Linaro-mm-sig] [PATCH v3] dmabuf: Add the capability to expose DMA-BUF stats in sysfs

by Sumit Semwal

Hi Simon, On Thu, 28 Jan 2021 at 20:01, Simon Ser <contact(a)emersion.fr> wrote: > > On Thursday, January 28th, 2021 at 1:03 PM, Sumit Semwal <sumit.semwal(a)linaro.org> wrote: > > > Since he didn't comment over Hridya's last clarification about the > > tracepoints to track total GPU memory allocations being orthogonal to > > this series, I assumed he agreed with it. > > IIRC he's away this week. (I don't remember when he comes back.) > > > Daniel, do you still have objections around adding this patch in? > > (Adding him explicitly in CC) Thanks for doing this! Best, Sumit.

4 years, 10 months

2
1
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

Linaro-mm-sig