Linaro-mm-sig

linaro-mm-sig@lists.linaro.org

16 participants
3173 discussions

Re: [PATCH v3 06/28] drm/amdgpu: add amdgpu_ttm_job_submit helper

by Christian König

On 11/21/25 11:12, Pierre-Eric Pelloux-Prayer wrote: > Deduplicate the IB padding code and will also be used > later to check locking. > > Signed-off-by: Pierre-Eric Pelloux-Prayer <pierre-eric.pelloux-prayer(a)amd.com> Reviewed-by: Christian König <christian.koenig(a)amd.com> > --- > drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c | 34 ++++++++++++------------- > 1 file changed, 16 insertions(+), 18 deletions(-) > > diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c > index 17e1892c44a2..be1232b2d55e 100644 > --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c > +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c > @@ -162,6 +162,18 @@ static void amdgpu_evict_flags(struct ttm_buffer_object *bo, > *placement = abo->placement; > } > > +static struct dma_fence * > +amdgpu_ttm_job_submit(struct amdgpu_device *adev, struct amdgpu_job *job, u32 num_dw) > +{ > + struct amdgpu_ring *ring; > + > + ring = adev->mman.buffer_funcs_ring; > + amdgpu_ring_pad_ib(ring, &job->ibs[0]); > + WARN_ON(job->ibs[0].length_dw > num_dw); > + > + return amdgpu_job_submit(job); > +} > + > /** > * amdgpu_ttm_map_buffer - Map memory into the GART windows > * @adev: the device being used > @@ -185,7 +197,6 @@ static int amdgpu_ttm_map_buffer(struct amdgpu_device *adev, > { > unsigned int offset, num_pages, num_dw, num_bytes; > uint64_t src_addr, dst_addr; > - struct amdgpu_ring *ring; > struct amdgpu_job *job; > void *cpu_addr; > uint64_t flags; > @@ -240,10 +251,6 @@ static int amdgpu_ttm_map_buffer(struct amdgpu_device *adev, > amdgpu_emit_copy_buffer(adev, &job->ibs[0], src_addr, > dst_addr, num_bytes, 0); > > - ring = adev->mman.buffer_funcs_ring; > - amdgpu_ring_pad_ib(ring, &job->ibs[0]); > - WARN_ON(job->ibs[0].length_dw > num_dw); > - > flags = amdgpu_ttm_tt_pte_flags(adev, bo->ttm, mem); > if (tmz) > flags |= AMDGPU_PTE_TMZ; > @@ -261,7 +268,7 @@ static int amdgpu_ttm_map_buffer(struct amdgpu_device *adev, > amdgpu_gart_map_vram_range(adev, pa, 0, num_pages, flags, cpu_addr); > } > > - dma_fence_put(amdgpu_job_submit(job)); > + dma_fence_put(amdgpu_ttm_job_submit(adev, job, num_dw)); > return 0; > } > > @@ -1497,10 +1504,7 @@ static int amdgpu_ttm_access_memory_sdma(struct ttm_buffer_object *bo, > amdgpu_emit_copy_buffer(adev, &job->ibs[0], src_addr, dst_addr, > PAGE_SIZE, 0); > > - amdgpu_ring_pad_ib(adev->mman.buffer_funcs_ring, &job->ibs[0]); > - WARN_ON(job->ibs[0].length_dw > num_dw); > - > - fence = amdgpu_job_submit(job); > + fence = amdgpu_ttm_job_submit(adev, job, num_dw); > > if (!dma_fence_wait_timeout(fence, false, adev->sdma_timeout)) > r = -ETIMEDOUT; > @@ -2285,11 +2289,9 @@ int amdgpu_copy_buffer(struct amdgpu_device *adev, uint64_t src_offset, > byte_count -= cur_size_in_bytes; > } > > - amdgpu_ring_pad_ib(ring, &job->ibs[0]); > - WARN_ON(job->ibs[0].length_dw > num_dw); > - *fence = amdgpu_job_submit(job); > if (r) > goto error_free; > + *fence = amdgpu_ttm_job_submit(adev, job, num_dw); > > return r; > > @@ -2307,7 +2309,6 @@ static int amdgpu_ttm_fill_mem(struct amdgpu_device *adev, uint32_t src_data, > u64 k_job_id) > { > unsigned int num_loops, num_dw; > - struct amdgpu_ring *ring; > struct amdgpu_job *job; > uint32_t max_bytes; > unsigned int i; > @@ -2331,10 +2332,7 @@ static int amdgpu_ttm_fill_mem(struct amdgpu_device *adev, uint32_t src_data, > byte_count -= cur_size; > } > > - ring = adev->mman.buffer_funcs_ring; > - amdgpu_ring_pad_ib(ring, &job->ibs[0]); > - WARN_ON(job->ibs[0].length_dw > num_dw); > - *fence = amdgpu_job_submit(job); > + *fence = amdgpu_ttm_job_submit(adev, job, num_dw); > return 0; > } >

16 minutes

Re: [PATCH v9 10/11] vfio/pci: Add dma-buf export support for MMIO regions

by Leon Romanovsky

On Thu, Nov 20, 2025 at 05:04:13PM -0700, Alex Williamson wrote: > On Thu, 20 Nov 2025 11:28:29 +0200 > Leon Romanovsky <leon(a)kernel.org> wrote: > > diff --git a/drivers/vfio/pci/vfio_pci_core.c b/drivers/vfio/pci/vfio_pci_core.c > > index 142b84b3f225..51a3bcc26f8b 100644 > > --- a/drivers/vfio/pci/vfio_pci_core.c > > +++ b/drivers/vfio/pci/vfio_pci_core.c > ... > > @@ -2487,8 +2500,11 @@ static int vfio_pci_dev_set_hot_reset(struct vfio_device_set *dev_set, > > > > err_undo: > > list_for_each_entry_from_reverse(vdev, &dev_set->device_list, > > - vdev.dev_set_list) > > + vdev.dev_set_list) { > > + if (__vfio_pci_memory_enabled(vdev)) > > + vfio_pci_dma_buf_move(vdev, false); > > up_write(&vdev->memory_lock); > > + } > > I ran into a bug here. In the hot reset path we can have dev_sets > where one or more devices are not opened by the user. The vconfig > buffer for the device is established on open. However: > > bool __vfio_pci_memory_enabled(struct vfio_pci_core_device *vdev) > { > struct pci_dev *pdev = vdev->pdev; > u16 cmd = le16_to_cpu(*(__le16 *)&vdev->vconfig[PCI_COMMAND]); > ... > > Leads to a NULL pointer dereference. > > I think the most straightforward fix is simply to test the open_count > on the vfio_device, which is also protected by the dev_set->lock that > we already hold here: > > --- a/drivers/vfio/pci/vfio_pci_core.c > +++ b/drivers/vfio/pci/vfio_pci_core.c > @@ -2501,7 +2501,7 @@ static int vfio_pci_dev_set_hot_reset(struct vfio_device_set *dev_set, > err_undo: > list_for_each_entry_from_reverse(vdev, &dev_set->device_list, > vdev.dev_set_list) { > - if (__vfio_pci_memory_enabled(vdev)) > + if (vdev->vdev.open_count && __vfio_pci_memory_enabled(vdev)) > vfio_pci_dma_buf_move(vdev, false); > up_write(&vdev->memory_lock); > } > > Any other suggestions? This should be the only reset path with this > nuance of affecting non-opened devices. Thanks, It seems right to me. Thanks > > Alex

5 hours, 34 minutes

Re: [PATCH v2] dma-buf: system_heap: use larger contiguous mappings instead of per-page mmap

by Sumit Semwal

Hi Barry, On Fri, 21 Nov 2025 at 06:54, Barry Song <21cnbao(a)gmail.com> wrote: > > Hi Sumit, > > > > > Using the micro-benchmark below, we see that mmap becomes > > 3.5X faster: > > > Marcin pointed out to me off-tree that it is actually 35x faster, > not 3.5x faster. Sorry for my poor math. I assume you can fix this > when merging it? Sure, I corrected this, and is merged to drm-misc-next Thanks, Sumit. > > > > > W/ patch: > > > > ~ # ./a.out > > mmap 512MB took 200266.000 us, verify OK > > ~ # ./a.out > > mmap 512MB took 198151.000 us, verify OK > > ~ # ./a.out > > mmap 512MB took 197069.000 us, verify OK > > ~ # ./a.out > > mmap 512MB took 196781.000 us, verify OK > > ~ # ./a.out > > mmap 512MB took 198102.000 us, verify OK > > ~ # ./a.out > > mmap 512MB took 195552.000 us, verify OK > > > > W/o patch: > > > > ~ # ./a.out > > mmap 512MB took 6987470.000 us, verify OK > > ~ # ./a.out > > mmap 512MB took 6970739.000 us, verify OK > > ~ # ./a.out > > mmap 512MB took 6984383.000 us, verify OK > > ~ # ./a.out > > mmap 512MB took 6971311.000 us, verify OK > > ~ # ./a.out > > mmap 512MB took 6991680.000 us, verify OK > > > Thanks > Barry

7 hours, 24 minutes

Re: [PATCH 6/9] iommufd: Have pfn_reader process DMABUF iopt_pages

by Jason Gunthorpe

On Thu, Nov 20, 2025 at 08:04:37AM +0000, Tian, Kevin wrote: > > From: Jason Gunthorpe <jgg(a)nvidia.com> > > Sent: Saturday, November 8, 2025 12:50 AM > > + > > +static int pfn_reader_fill_dmabuf(struct pfn_reader_dmabuf *dmabuf, > > + struct pfn_batch *batch, > > + unsigned long start_index, > > + unsigned long last_index) > > +{ > > + unsigned long start = dmabuf->start_offset + start_index * PAGE_SIZE; > > + > > + /* > > + * This works in PAGE_SIZE indexes, if the dmabuf is sliced and > > + * starts/ends at a sub page offset then the batch to domain code will > > + * adjust it. > > + */ > > dmabuf->start_offset comes from pages->dmabuf.start, which is initialized as: > > pages->dmabuf.start = start - start_byte; > > so it's always page-aligned. Where is the sub-page offset coming from? I need to go over this again to check it, this sub-page stuff is a bit convoluted. start_offset should include the sub page offset here.. > > @@ -1687,6 +1737,12 @@ static void __iopt_area_unfill_domain(struct > > iopt_area *area, > > > > lockdep_assert_held(&pages->mutex); > > > > + if (iopt_is_dmabuf(pages)) { > > + iopt_area_unmap_domain_range(area, domain, start_index, > > + last_index); > > + return; > > + } > > + > > this belongs to patch3? This is part of programming the domain with the dmabuf, the patch3 was about the revoke which is a slightly different topic though they are both similar. Thanks, Jason

12 hours, 29 minutes

Re: [PATCH v9 10/11] vfio/pci: Add dma-buf export support for MMIO regions

by Jason Gunthorpe

On Thu, Nov 20, 2025 at 05:04:13PM -0700, Alex Williamson wrote: > @@ -2501,7 +2501,7 @@ static int vfio_pci_dev_set_hot_reset(struct vfio_device_set *dev_set, > err_undo: > list_for_each_entry_from_reverse(vdev, &dev_set->device_list, > vdev.dev_set_list) { > - if (__vfio_pci_memory_enabled(vdev)) > + if (vdev->vdev.open_count && __vfio_pci_memory_enabled(vdev)) > vfio_pci_dma_buf_move(vdev, false); > up_write(&vdev->memory_lock); > } > > Any other suggestions? This should be the only reset path with this > nuance of affecting non-opened devices. Thanks, Seems reasonable, but should it be in __vfio_pci_memory_enabled() just to be robust? Jason

12 hours, 53 minutes

Re: [PATCH] drm/xe: Fix memory leak when handling pagefault vma

by Thomas Hellström

On Thu, 2025-11-20 at 18:14 +0200, Mika Kuoppala wrote: > When the pagefault handling code was moved to a new file, an extra > drm_exec_init() was added to the VMA path. This call is unnecessary > because > xe_validation_ctx_init() already performs a drm_exec_init(), > resulting in a > memory leak reported by kmemleak. > > Remove the redundant drm_exec_init() from the VMA pagefault handling > code. > > Fixes: fb544b844508 ("drm/xe: Implement xe_pagefault_queue_work") > Cc: Matthew Brost <matthew.brost(a)intel.com> > Cc: Stuart Summers <stuart.summers(a)intel.com> > Cc: Lucas De Marchi <lucas.demarchi(a)intel.com> > Cc: "Thomas Hellström" <thomas.hellstrom(a)linux.intel.com> > Cc: Rodrigo Vivi <rodrigo.vivi(a)intel.com> > Cc: Sumit Semwal <sumit.semwal(a)linaro.org> > Cc: "Christian König" <christian.koenig(a)amd.com> > Cc: intel-xe(a)lists.freedesktop.org > Cc: linux-media(a)vger.kernel.org > Cc: dri-devel(a)lists.freedesktop.org > Cc: linaro-mm-sig(a)lists.linaro.org > Signed-off-by: Mika Kuoppala <mika.kuoppala(a)linux.intel.com> Reviewed-by: Thomas Hellström <thomas.hellstrom(a)linux.intel.com> > --- > drivers/gpu/drm/xe/xe_pagefault.c | 1 - > 1 file changed, 1 deletion(-) > > diff --git a/drivers/gpu/drm/xe/xe_pagefault.c > b/drivers/gpu/drm/xe/xe_pagefault.c > index fe3e40145012..afb06598b6e1 100644 > --- a/drivers/gpu/drm/xe/xe_pagefault.c > +++ b/drivers/gpu/drm/xe/xe_pagefault.c > @@ -102,7 +102,6 @@ static int xe_pagefault_handle_vma(struct xe_gt > *gt, struct xe_vma *vma, > > /* Lock VM and BOs dma-resv */ > xe_validation_ctx_init(&ctx, &vm->xe->val, &exec, (struct > xe_val_flags) {}); > - drm_exec_init(&exec, 0, 0); > drm_exec_until_all_locked(&exec) { > err = xe_pagefault_begin(&exec, vma, tile->mem.vram, > needs_vram == 1);

20 hours, 59 minutes

Re: [PATCH 5/9] iommufd: Allow MMIO pages in a batch

by Jason Gunthorpe

On Thu, Nov 20, 2025 at 07:59:19AM +0000, Tian, Kevin wrote: > > From: Jason Gunthorpe <jgg(a)nvidia.com> > > Sent: Saturday, November 8, 2025 12:50 AM > > > > +enum batch_kind { > > + BATCH_CPU_MEMORY = 0, > > + BATCH_MMIO, > > +}; > > with 'CPU_MEMORY' (instead of plain 'MEMORY') implies future > support of 'DEV_MEMORY'? Maybe, but I don't have an immediate thought on this. CXL "MMIO" that is cachable is a thing but we can also label it as CPU_MEMORY. We might have something for CC shared/protected memory down the road. Thanks, Jason

22 hours, 17 minutes

Reasonable maximum signaling timeout for dma_fences

by Christian König

Hi everybody, we have documented here https://www.kernel.org/doc/html/latest/driver-api/dma-buf.html#dma-fence-cr… that dma_fence objects must signal in a reasonable amount of time, but at the same time note that drivers might have a different idea of what reasonable means. Recently I realized that this is actually not a good idea. Background is that the wall clock timeout means that for example the OOM killer might actually wait for this timeout to be able to terminate a process and reclaim the memory used. And this is just an example of how general kernel features might depend on that. Some drivers and fence implementations used 10 seconds and that raised complains by end users. So at least amdgpu recently switched to 2 second which triggered an internal discussion about it. This patch set here now adds a define to the dma_fence header which gives 2 seconds as reasonable amount of time. SW-sync is modified to always taint the kernel (since it doesn't has a timeout), VGEM is switched over to the new define and the scheduler gets a warning and taints the kernel if a driver uses a timeout longer than that. I have not much intention of actually committing the patches (maybe except the SW-sync one), but question is if 2 seconds are reasonable? Regards, Christian.

22 hours, 35 minutes

Re: [PATCH net-next v6 0/6] Add AF_XDP zero copy support

by patchwork-bot+netdevbpf＠kernel.org

Hello: This series was applied to netdev/net-next.git (main) by Paolo Abeni <pabeni(a)redhat.com>: On Tue, 18 Nov 2025 19:25:36 +0530 you wrote: > This series adds AF_XDP zero coppy support to icssg driver. > > Tests were performed on AM64x-EVM with xdpsock application [1]. > > A clear improvement is seen Transmit (txonly) and receive (rxdrop) > for 64 byte packets. 1500 byte test seems to be limited by line > rate (1G link) so no improvement seen there in packet rate > > [...] Here is the summary with links: - [net-next,v6,1/6] net: ti: icssg-prueth: Add functions to create and destroy Rx/Tx queues https://git.kernel.org/netdev/net-next/c/41dde7f1d013 - [net-next,v6,2/6] net: ti: icssg-prueth: Add XSK pool helpers https://git.kernel.org/netdev/net-next/c/7dfd7597911f - [net-next,v6,3/6] net: ti: icssg-prueth: Add AF_XDP zero copy for TX https://git.kernel.org/netdev/net-next/c/8756ef2eb078 - [net-next,v6,4/6] net: ti: icssg-prueth: Make emac_run_xdp function independent of page https://git.kernel.org/netdev/net-next/c/121133163c9f - [net-next,v6,5/6] net: ti: icssg-prueth: Add AF_XDP zero copy for RX https://git.kernel.org/netdev/net-next/c/7a64bb388df3 - [net-next,v6,6/6] net: ti: icssg-prueth: Enable zero copy in XDP features https://git.kernel.org/netdev/net-next/c/c6a1ec1870e6 You are awesome, thank you! -- Deet-doot-dot, I am a bot. https://korg.docs.kernel.org/patchwork/pwbot.html

22 hours, 46 minutes

Re: [PATCH 02/18] dma-buf: protected fence ops by RCU v3

by Christian König

On 11/18/25 17:03, Tvrtko Ursulin wrote: >>>> @@ -448,13 +465,19 @@ dma_fence_is_signaled_locked(struct dma_fence *fence) >>>> static inline bool >>>> dma_fence_is_signaled(struct dma_fence *fence) >>>> { >>>> + const struct dma_fence_ops *ops; >>>> + >>>> if (test_bit(DMA_FENCE_FLAG_SIGNALED_BIT, &fence->flags)) >>>> return true; >>>> - if (fence->ops->signaled && fence->ops->signaled(fence)) { >>>> + rcu_read_lock(); >>>> + ops = rcu_dereference(fence->ops); >>>> + if (ops->signaled && ops->signaled(fence)) { >>>> + rcu_read_unlock(); >>> >>> With the unlocked version two threads could race and one could make the fence->lock go away just around here, before the dma_fence_signal below will take it. It seems it is only safe to rcu_read_unlock before signaling if using the embedded fence (later in the series). Can you think of a downside to holding the rcu read lock to after signaling? that would make it safe I think. >> >> Well it's good to talk about it but I think that it is not necessary to protect the lock in this particular case. >> >> See the RCU protection is only for the fence->ops pointer, but the lock can be taken way after the fence is already signaled. >> >> That's why I came up with the patch to move the lock into the fence in the first place. > > Right. And you think there is nothing to gain with the option of keeping the rcu_read_unlock() to after signalling? Ie. why not plug a potential race if we can for no negative effect. I thought quite a bit over that, but at least of hand I can't come up with a reason why we should do this. The signaling path doesn't need the RCU read side lock as far as I can see. Regards, Christian. > > Regards, > > Tvrtko

23 hours, 13 minutes

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

Linaro-mm-sig