Linaro-mm-sig

linaro-mm-sig@lists.linaro.org

23 participants
3667 discussions

[PATCH v7 00/19] PCI/P2PDMA: Route peer-to-peer DMA by TLP class

by Leon Romanovsky

PCI P2PDMA applies Request and Completion Redirect throughout both paths. This misclassifies asymmetric and nested switches, and reports one answer for every kind of TLP. Three ACS controls act on TLP attributes the client chooses rather than on the topology: Translation Blocking and Direct Translated P2P act on a Request's Address Type, and Completion Redirect skips Completions carrying Relaxed Ordering. Evaluate each direction at the path divergence, decide every class from the one walk, expose the provider to dma-buf importers, and let mlx5 ask rather than assume. Signed-off-by: Leon Romanovsky <leonro(a)nvidia.com> --- Changes in v7: - Removed "Document pdev->p2pdma lifetime rules" patch, it gives nothing after p2pmem fix. - Split dmabuf patch. - Tushar retested the series, so added his Tested-by. - Added Logan's ROB tags and fixed minor documentation issues pointed by him. - Link to v6: https://lore.kernel.org/all/20260914-fix-p2p-acs-v4-0-v6-0-5ef07ec9ef06@nvi… Changes in v6: - Changed DMABUF to use callbacks and not directly stored pointer. - Link to v5: https://patch.msgid.link/20260910-fix-p2p-acs-v4-0-v5-0-856087f63c0d@nvidia… Changes in v5: - Rebase on the posted fixes. - Dropped tags from changed patches. - Remove Egress Control Vector interpretation and coverage. - Keep enabled Egress Control conservative as a Request redirect. - Use pci_dbg()/dev_dbg() for diagnostics and drop the "debug" prefix. - Removed code comments from "Document the pdev->p2pdma lifetime and RCU rules" patch and reduced description to actual lifetime explanation. - Added note that Linux assumes that TLPs are in strict-ordering and untranslated. - Added code to calculate p2p paths per-TLP type. - Converted mlx5 to use that new proposed API. - Link to https://patch.msgid.link/20260821-fix-p2p-acs-v4-0-v4-0-94426b96de73@nvidia… Changes in v4: - Reject ACS Violations and unreadable routing state instead of treating them as host-bridge redirects - Added Tested-by tags from Tushar Dave - Added support to asymmetric ACS routing - Limited redirect checks to the two ports at the path divergence - Added standalone ACS routing diagnostics for hardware retesting - Dropped " PCI: Account for Direct Translated P2P in ACS isolation checks" patch - Link to v3: https://patch.msgid.link/20260811-fix-p2p-acs-v3-0-efc488ee7c03@nvidia.com Changes in v3: - Fixed pci_p2pdma_add_resource() error unwinding - Made pdev->p2pdma teardown wait unconditionally for RCU readers - Restricted pci_p2pmem_find_many() to pool-backed providers - Documented the pdev->p2pdma lifetime and RCU rules - Fixed calc_map_type_and_dist() handling of the verbose argument - Required the ACS port and target to share a bus before indexing the Egress Control Vector - Gave pci_acs_enabled() and pci_acs_path_enabled() a scope, so the ACS Direct Translated P2P rule no longer stops pci_enable_pasid() from enabling PASID - Dropped "Report ACS ports when the paths share no upstream bridge": the mapping type cannot change without a shared upstream bridge, so the pci=disable_acs_redir= hint was not actionable there and the ACS walk only cost config space reads - Folded the Request Redirect rule into pci_acs_rr_ineffective(), so pci_acs_flags_enabled() and the Intel SPT PCH quirk share one copy - Renamed pci_acs_egress_ctrl_set() to pci_acs_egress_ctrl_is_set(), it reads the bit rather than setting it - Reworded the blocked-path warning: ACS may also leave the direct route indeterminate rather than blocked - Added KUnit coverage for the shared-bus guard, a device with no ACS capability and an unreadable ACS Control register - Added the missing Fixes: tags, a second one on the pci_p2pdma_add_resource() unwinding fix (the dangling devres action dates to f58ef9d1d135) and one on the Egress Control isolation change - Link to v2: https://patch.msgid.link/20260806-fix-p2p-acs-v2-0-0cec14812965@nvidia.com Changes in v2: - Added Logan's ROB tags - Added commas in Documentation patch - Link to v1: https://patch.msgid.link/20260802-fix-p2p-acs-v1-0-a7c5eb64fff6@nvidia.com --- Leon Romanovsky (19): PCI/P2PDMA: Document the TLP attribute assumptions PCI/P2PDMA: Derive routing from directional ACS controls PCI: Reject unreadable ACS controls in isolation checks PCI/P2PDMA: Evaluate ACS controls at the path divergence PCI/P2PDMA: Document directional ACS routing PCI/P2PDMA: Collect the path's ACS controls before deciding PCI/P2PDMA: Answer routing per TLP class PCI/P2PDMA: Route Relaxed Ordering Completions directly PCI/P2PDMA: Reject Translated Requests blocked by Translation Blocking PCI/P2PDMA: Route Translated Requests under Direct Translated P2P PCI/P2PDMA: Log detailed ACS routing diagnostics PCI/P2PDMA: Add KUnit tests for the ACS routing decisions PCI/P2PDMA: Test the ACS P2P routing walk PCI: Add KUnit coverage for ACS isolation checks PCI/P2PDMA: Document TLP-class routing dma-buf: Let importers ask how peer-to-peer traffic is routed vfio/pci: Hand out the P2PDMA provider behind a dma-buf RDMA/uverbs: Hand out the P2PDMA provider behind a dma-buf RDMA/mlx5: Ask P2PDMA whether ATS takes a direct peer-to-peer route Documentation/admin-guide/kernel-parameters.txt | 15 +- Documentation/driver-api/pci/p2pdma.rst | 71 +++ drivers/dma-buf/dma-buf-mapping.c | 39 ++ drivers/infiniband/core/uverbs_std_types_dmabuf.c | 12 + drivers/infiniband/hw/mlx5/mlx5_ib.h | 36 +- drivers/infiniband/hw/mlx5/mr.c | 47 ++ drivers/pci/Kconfig | 15 + drivers/pci/Makefile | 1 + drivers/pci/p2pdma.c | 630 +++++++++++++++--- drivers/pci/pci.c | 7 +- drivers/pci/pci.h | 26 + drivers/pci/pci_acs_test.c | 737 ++++++++++++++++++++++ drivers/pci/quirks.c | 6 +- drivers/vfio/pci/vfio_pci_dmabuf.c | 12 + include/linux/dma-buf-mapping.h | 3 + include/linux/dma-buf.h | 19 + include/linux/pci-p2pdma.h | 57 +- 17 files changed, 1611 insertions(+), 122 deletions(-) --- base-commit: 08dbfad3f5040f5bdb6c529da20d6d4e81fefd72 change-id: 20260821-fix-p2p-acs-v4-0-e72455e3a261 prerequisite-message-id: <20260830-batch-p2p-fixes-v1-0-5044e8dfbe2e(a)nvidia.com> prerequisite-patch-id: 6b25c7fcf164cdfc14e9fac5b908d97fcf6509d7 prerequisite-patch-id: 0d083c281001365aae4b35544cf28891a6ab9a96 prerequisite-patch-id: bfd9dabf271f3cc9a3a61f46387d20c20311363d prerequisite-patch-id: fad0275efc722830fc591509506c0a5e4f581073 prerequisite-patch-id: 0c83bee688fec1f6d1564654df7c630fa6a4a978 Best regards, -- Leon Romanovsky <leonro(a)nvidia.com>

1 month

Re: [PATCH v6 03/18] PCI/P2PDMA: Derive routing from directional ACS controls

by Leon Romanovsky

On Fri, Sep 18, 2026 at 01:39:55PM -0600, Logan Gunthorpe wrote: > > > On 2026-09-14 05:22, Leon Romanovsky wrote: > > From: Leon Romanovsky <leonro(a)nvidia.com> > > > > pci_bridge_has_acs_redir() treats Request and Completion Redirect as > > interchangeable. On asymmetric fabrics, a control for only the reverse TLP > > direction can unnecessarily force P2PDMA through the host bridge. > > > > Evaluate Request Redirect for client Requests and Completion Redirect for > > provider read Completions. Continue treating enabled Egress Control > > conservatively as a Request redirect. > > > > Fixes: 52916982af48 ("PCI/P2PDMA: Support peer-to-peer memory") > > Signed-off-by: Leon Romanovsky <leonro(a)nvidia.com> > > Core patch seems fine, minus one minor point below: > > Reviewed-by: Logan Gunthorpe <logang(a)deltatee.com> > > > @@ -1132,10 +1173,10 @@ EXPORT_SYMBOL_GPL(pci_p2pmem_publish); > > /** > > * pci_p2pdma_map_type - Determine the mapping type for P2PDMA transfers > > * @provider: P2PDMA provider structure > > - * @dev: Target device for the transfer > > + * @dev: Client device that initiates the transfer > > * > > * Determines how peer-to-peer DMA transfers should be mapped between > > - * the provider and the target device. The mapping type indicates whether > > + * the provider and the client device. The mapping type indicates whether > > * the transfer can be done directly through PCI switches or must go > > * through the host bridge. > > */ > > > > This hunk does not seem like it belongs in this patch. This is the first patch that distinguishes between client and provider and starts using that terminology instead of target/initiator. Therefore, the change belongs here. Thanks

1 month

Re: [PATCH] dma-buf/udmabuf: avoid oversized kvmalloc in init_udmabuf()

by Christian König

On 9/18/26 03:34, Jiakai Xu wrote: > init_udmabuf() allocates two pointer arrays with one entry per page of > the created buffer. Since commit 1c0844c6184e ("udmabuf: change folios > array from kmalloc to kvmalloc") these arrays are allocated with > kvmalloc(), which warns and fails when the requested size exceeds > INT_MAX bytes. > > With the default size limit of 64 MB the largest possible request was > far below that threshold, but commit 44e9eb5a7621 ("dma-buf/udmabuf: > Disable the size limit by default") raised the limit to INT_MAX MB. > With 4K pages, creating a buffer of more than INT_MAX / 8 pages (about > 1 TB of pinned memory) now makes kvmalloc() hit its "crazy size" > WARN_ON_ONCE(), which is trivially triggerable from unprivileged users > through the UDMABUF_CREATE ioctls: > > WARNING: CPU: 0 PID: 412 at mm/slub.c:7021 __kvmalloc_node_noprof > Call Trace: > udmabuf_create > udmabuf_ioctl_create_list > > Fix it by rejecting buffers whose page count exceeds what the pointer > arrays can address before calling init_udmabuf(), returning -EINVAL. I was already wondering if we won't hit some allocation limit when we drop the general limit. Please don't add any new check, but rather give a reasonable default size limit. > > Fixes: 1c0844c6184e ("udmabuf: change folios array from kmalloc to kvmalloc") > Fixes: 44e9eb5a7621 ("dma-buf/udmabuf: Disable the size limit by default") Two fixes tags usually doesn't make much sense. Regards, Christian. > Signed-off-by: Jiakai Xu <xujiakai24(a)mails.ucas.ac.cn> > --- > drivers/dma-buf/udmabuf.c | 8 ++++++++ > 1 file changed, 8 insertions(+) > > diff --git a/drivers/dma-buf/udmabuf.c b/drivers/dma-buf/udmabuf.c > index df6dd00462423..25984e75d7ff3 100644 > --- a/drivers/dma-buf/udmabuf.c > +++ b/drivers/dma-buf/udmabuf.c > @@ -383,6 +383,14 @@ static long udmabuf_create(struct miscdevice *device, > if (!pgcnt) > goto err_noinit; > > + /* > + * init_udmabuf() allocates two arrays of pointers, one entry per > + * page, with kvmalloc(), which cannot handle sizes larger than > + * INT_MAX bytes. > + */ > + if (pgcnt > INT_MAX / sizeof(struct page *)) > + goto err_noinit; > + > ret = init_udmabuf(ubuf, pgcnt); > if (ret) > goto err; > -- > 2.34.1 > > > -- > Below is the crash report: > ------------[ cut here ]------------ > WARNING: mm/slub.c:7013 at __kvmalloc_node_noprof+0x516/0x5d0 home/zzzrrll/tmp/kf_src/linux-7.3-rc2/mm/slub.c:7013, CPU#0: syz.5.27938/167363 > Modules linked in: > CPU: 0 UID: 0 PID: 167363 Comm: syz.5.27938 Tainted: G W L 7.3.0-rc2 #1 PREEMPT(full) > Tainted: [W]=WARN, [L]=SOFTLOCKUP > Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014 > RIP: 0010:__kvmalloc_node_noprof+0x516/0x5d0 home/zzzrrll/tmp/kf_src/linux-7.3-rc2/mm/slub.c:7013 > Code: 05 bf fa 2d 08 49 8b 0f c6 04 08 00 65 48 ff 0d 90 fa 2d 08 0f 85 4c fd ff ff e8 05 43 8c ff e9 42 fd ff ff e8 9b 86 0e 04 90 <0f> 0b 90 31 db e9 d2 fe ff ff f3 0f 1e fa 65 8b 05 8d fa 2d 08 89 > RSP: 0018:ffffc90002bc3cf8 EFLAGS: 00010246 > RAX: 0000000000000100 RBX: 0000000000000000 RCX: 0000008000000000 > RDX: 0000008000000000 RSI: 0000000000000000 RDI: ffffffff835e3226 > RBP: 00000000ffffffff R08: 00000000000028c0 R09: 00000000ffffffff > R10: 0000000000000006 R11: 0000000000000002 R12: 0000008000000000 > R13: 00000000000028c0 R14: 0000001000000000 R15: 0000008000000000 > FS: 00007fc89ae45640(0000) GS:ffff8880f3de4000(0000) knlGS:0000000000000000 > CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 > CR2: 000000110c2ff305 CR3: 000000002b3d4000 CR4: 0000000000752ef0 > DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000006000 > DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400 > PKRU: 80000000 > Call Trace: > <TASK> > init_udmabuf home/zzzrrll/tmp/kf_src/linux-7.3-rc2/drivers/dma-buf/udmabuf.c:193 [inline] > udmabuf_create+0x1b6/0x750 home/zzzrrll/tmp/kf_src/linux-7.3-rc2/drivers/dma-buf/udmabuf.c:386 > udmabuf_ioctl_create home/zzzrrll/tmp/kf_src/linux-7.3-rc2/drivers/dma-buf/udmabuf.c:465 [inline] > udmabuf_ioctl+0x132/0x1d0 home/zzzrrll/tmp/kf_src/linux-7.3-rc2/drivers/dma-buf/udmabuf.c:496 > vfs_ioctl home/zzzrrll/tmp/kf_src/linux-7.3-rc2/fs/ioctl.c:51 [inline] > __do_sys_ioctl home/zzzrrll/tmp/kf_src/linux-7.3-rc2/fs/ioctl.c:597 [inline] > __se_sys_ioctl+0xbc/0x130 home/zzzrrll/tmp/kf_src/linux-7.3-rc2/fs/ioctl.c:583 > do_syscall_x64 home/zzzrrll/tmp/kf_src/linux-7.3-rc2/arch/x86/entry/syscall_64.c:61 [inline] > do_syscall_64+0x12b/0x350 home/zzzrrll/tmp/kf_src/linux-7.3-rc2/arch/x86/entry/syscall_64.c:84 > entry_SYSCALL_64_after_hwframe+0x77/0x7f > RIP: 0033:0x590d6d > Code: 02 b8 ff ff ff ff c3 66 0f 1f 44 00 00 f3 0f 1e fa 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 a8 ff ff ff f7 d8 64 89 01 48 > RSP: 002b:00007fc89ae44fd8 EFLAGS: 00000216 ORIG_RAX: 0000000000000010 > RAX: ffffffffffffffda RBX: 0000000000611e7f RCX: 0000000000590d6d > RDX: 00002000000023c0 RSI: 0000000040187542 RDI: 000000000000000a > RBP: 00007fc89ae45010 R08: 0000000000000000 R09: 0000000000000000 > R10: 0000000000000000 R11: 0000000000000216 R12: 00007fc89ae45640 > R13: 000000000000000b R14: 0000000000528d40 R15: 00007fc89ae25000 > </TASK> > ---[ end trace 0000000000000000 ]--- > --- >

1 month, 1 week

Re: [PATCH v6 01/18] PCI/P2PDMA: Document pdev->p2pdma lifetime rules

by Leon Romanovsky

On Fri, Sep 18, 2026 at 12:25:01PM -0600, Logan Gunthorpe wrote: > > > On 2026-09-14 05:22, Leon Romanovsky wrote: > > From: Leon Romanovsky <leonro(a)nvidia.com> > > > > pdev->p2pdma is normally accessed through provider-owned references, but > > pci_p2pmem_find_many() and the p2pmem sysfs attributes may race with driver > > unbind. > > > > Document initialization, teardown, and how the release grace period > > protects both the P2PDMA state and its optional allocation pool. > > > > Cc: Alex Williamson <alex(a)shazbot.org> > > Cc: Matt Evans <matt(a)ozlabs.org> > > Signed-off-by: Leon Romanovsky <leonro(a)nvidia.com> > Reads correct to me. > > Reviewed-by: Logan Gunthorpe <logang(a)deltatee.com> Thanks, Logan. Unfortunately, I'm inclined to drop this patch. AI review makes it nearly impossible to write the description without complaints. If I use my own words to describe the lifetime, the tools complain about almost every word or sentence. If I let the tools write it instead, the result is complete junk that merely describes basics already obvious from the code itself. Thanks

1 month, 1 week

Re: [PATCH] drm/vmwgfx: Fix GEM_CLOSE returning -EINVAL for PRIME-imported surfaces

by kernel test robot

Hi Claire, kernel test robot noticed the following build warnings: [auto build test WARNING on drm-misc/drm-misc-next] [also build test WARNING on linus/master v7.3-rc3 next-20260916] [If your patch is applied to the wrong git tree, kindly drop us a note. And when submitting patch, we suggest to use '--base' as documented in https://git-scm.com/docs/git-format-patch#_base_tree_information] url: https://github.com/intel-lab-lkp/linux/commits/Claire-DuSoleil/drm-vmwgfx-F… base: https://gitlab.freedesktop.org/drm/misc/kernel.git drm-misc-next patch link: https://lore.kernel.org/r/20260917181312.12473-1-claire.m.dusoleil%40gmail.… patch subject: [PATCH] drm/vmwgfx: Fix GEM_CLOSE returning -EINVAL for PRIME-imported surfaces config: x86_64-buildonly-randconfig-1001-20260918 (https://download.01.org/0day-ci/archive/20260918/202609182113.RjRMgrW6-lkp@…) compiler: gcc-14 (Debian 14.2.0-19) 14.2.0 reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20260918/202609182113.RjRMgrW6-lkp@…) If you fix the issue in a separate patch/commit (i.e. not just a new version of the same patch/commit), kindly add following tags | Reported-by: kernel test robot <lkp(a)intel.com> | Closes: https://lore.kernel.org/oe-kbuild-all/202609182113.RjRMgrW6-lkp@intel.com/ All warnings (new ones prefixed by >>): >> Warning: drivers/gpu/drm/vmwgfx/vmwgfx_resource.c:263 function parameter 'file_priv' not described in 'vmw_user_resource_lookup_handle' >> Warning: drivers/gpu/drm/vmwgfx/vmwgfx_resource.c:263 function parameter 'file_priv' not described in 'vmw_user_resource_lookup_handle' -- 0-DAY CI Kernel Test Service https://github.com/intel/lkp-tests/wiki

1 month, 1 week

Re: [PATCH v5 5/5] accel/amdxdna: do not fail a sync for a BO with no debug context

by Lizhi Hou

On 8/19/26 15:44, Taimuraz Kaitmazov wrote: > amdxdna_drm_sync_bo_ioctl() calls amdxdna_hwctx_sync_debug_bo() for every > FROM_DEVICE sync, which answers -EINVAL when the BO's assigned_hwctx names > no context. Only a BO attached with ATTACH_DEBUG_BO is ever given one, so > an ordinary read-back sync reports failure after its flush has already run. > > Ask for the debug sync only when the BO has a context. An unattached BO > carries AMDXDNA_INVALID_CTX_HANDLE and hwctx ids are allocated above it, so > the test is exact, -EINVAL keeps meaning that the named context is gone, > and the handle is not resolved twice. The field is written under dev_lock > and read here without it; the context is still resolved under that lock, so > a racing attach only decides whether this sync sees the buffer. > > Suggested-by: Lizhi Hou <lizhi.hou(a)amd.com> > Signed-off-by: Taimuraz Kaitmazov <taimuraz(a)kaitmazov.com> > --- > drivers/accel/amdxdna/amdxdna_gem.c | 3 ++- > 1 file changed, 2 insertions(+), 1 deletion(-) > > diff --git a/drivers/accel/amdxdna/amdxdna_gem.c b/drivers/accel/amdxdna/amdxdna_gem.c > index 4be5298d1062..2613c94dd842 100644 > --- a/drivers/accel/amdxdna/amdxdna_gem.c > +++ b/drivers/accel/amdxdna/amdxdna_gem.c > @@ -1319,7 +1319,8 @@ int amdxdna_drm_sync_bo_ioctl(struct drm_device *dev, > XDNA_DBG(xdna, "Sync bo %d offset 0x%llx, size 0x%llx\n", > args->handle, args->offset, args->size); > > - if (args->direction == SYNC_DIRECT_FROM_DEVICE) > + if (abo->assigned_hwctx != AMDXDNA_INVALID_CTX_HANDLE && > + args->direction == SYNC_DIRECT_FROM_DEVICE) > ret = amdxdna_hwctx_sync_debug_bo(client, args->handle); Reviewed-by: Lizhi Hou <lizhi.hou(a)amd.com> > > put_obj:

1 month, 1 week

Re: [PATCH v5 3/5] accel/amdxdna: do not warn when a sync request is rejected

by Lizhi Hou

On 8/19/26 15:44, Taimuraz Kaitmazov wrote: > amdxdna_drm_sync_bo_ioctl() answers a failed amdxdna_flush_bo() with > drm_WARN(). Both of that function's error returns are decided by the > ioctl's arguments, so SYNC_BO with an offset past the end of the BO > splats and taints the kernel from an unprivileged caller. > > Log it at debug level, since the same caller can repeat it. > > Signed-off-by: Taimuraz Kaitmazov <taimuraz(a)kaitmazov.com> > --- > drivers/accel/amdxdna/amdxdna_gem.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/accel/amdxdna/amdxdna_gem.c b/drivers/accel/amdxdna/amdxdna_gem.c > index 77a9493cd7ba..0e0f844526ca 100644 > --- a/drivers/accel/amdxdna/amdxdna_gem.c > +++ b/drivers/accel/amdxdna/amdxdna_gem.c > @@ -1310,7 +1310,7 @@ int amdxdna_drm_sync_bo_ioctl(struct drm_device *dev, > amdxdna_gem_unpin(abo); > > if (ret) { > - drm_WARN(&xdna->ddev, 1, "Can not get flush memory"); > + XDNA_DBG(xdna, "Flush BO %d failed, ret %d", args->handle, ret); Reviewed-by: Lizhi Hou <lizhi.hou(a)amd.com> > goto put_obj; > } > }

1 month, 1 week

[PATCH v3 0/2] drm/drm_crtc: dma_fence_ops fixes

by André Draszik

Hi, These patches fix two issues in the drm/drm_crtc driver. Initially I was hitting the BUG_ON() in a scenario as explained in the commit message of what is now the second patch in this series. After posting, sashiko.dev noticed another issue, that was previously masked by the now-removed BUG_ON(). Since we can't have a loud BUG() be replaced with silent data corruption or worse, I've also added a patch to address this issue highlighted by sashiko.dev. I believe its observation and analysis to be correct. Cheers, Andre' Signed-off-by: André Draszik <andre.draszik(a)linaro.org> --- Changes in v3: - Philipp: - patch 1: update kerneldoc, add Fixes: - patch 2: shorten commit message - explicitly Cc: stable - collect tag - Link to v2: https://lore.kernel.org/r/20260708-linux-drm_crtc_fix2-v2-0-cf72be75d75a@li… Changes in v2: - add new patch 1 to address sashiko observation - original patch 1 becomes patch 2 - patch 2: - don't turn fence_to_crtc() into macro (Jani, Philipp) - update commit message to include reference to deprecated use of BUG - Link to v1: https://lore.kernel.org/r/20260618-linux-drm_crtc_fix2-v1-1-c03e77b36f34@li… --- André Draszik (2): drm/drm_crtc: ensure dma_fence_ops remain valid during device unbind drm/drm_crtc: fix race with dma_fence_signal() in ::get_driver_name() drivers/gpu/drm/drm_crtc.c | 18 ++++++++++++------ 1 file changed, 12 insertions(+), 6 deletions(-) --- base-commit: 0718283ab28bc3907e10b61a6b4be6fefa1cbb2f change-id: 20260618-linux-drm_crtc_fix2-23a7c354a412 Best regards, -- André Draszik <andre.draszik(a)linaro.org>

1 month, 1 week

Re: [PATCH] dma-fence: Fix dma_fence_enable_signaling() reference in kernel-doc

by Christian König

On 9/12/26 00:11, Karl Mehltretter wrote: > The kernel-doc comment of dma_fence_is_signaled_locked() refers to > dma_fence_enable_sw_signaling, which was renamed to > dma_fence_enable_signaling by commit 9370a5c664e8 ("dma-buf: rename > dma_fence_enable_sw_signaling"). Say dma_fence_enable_signaling. > > Fixes: 9370a5c664e8 ("dma-buf: rename dma_fence_enable_sw_signaling") > Assisted-by: LLM > Signed-off-by: Karl Mehltretter <kmehltretter(a)gmail.com> I'm really wondering why that was not automatically renamed. Anyway reviewed and pushed to drm-misc-next. Thanks, Christian. > --- > include/linux/dma-fence.h | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/include/linux/dma-fence.h b/include/linux/dma-fence.h > index 158cd609f1036e56668867f092041213cbf30427..3aa85be43aada5a80ea2e1cecc5f76824b434d14 100644 > --- a/include/linux/dma-fence.h > +++ b/include/linux/dma-fence.h > @@ -501,7 +501,7 @@ dma_fence_test_signaled_flag(struct dma_fence *fence) > * Returns true if the fence was already signaled, false if not. Since this > * function doesn't enable signaling, it is not guaranteed to ever return > * true if dma_fence_add_callback(), dma_fence_wait() or > - * dma_fence_enable_sw_signaling() haven't been called before. > + * dma_fence_enable_signaling() haven't been called before. > * > * This function requires &dma_fence.lock to be held. > *

1 month, 1 week

[PATCH v5 00/18] PCI/P2PDMA: Route peer-to-peer DMA by TLP class

by Leon Romanovsky

PCI P2PDMA applies Request and Completion Redirect throughout both paths. This misclassifies asymmetric and nested switches, and reports one answer for every kind of TLP. Three ACS controls act on TLP attributes the client chooses rather than on the topology: Translation Blocking and Direct Translated P2P act on a Request's Address Type, and Completion Redirect skips Completions carrying Relaxed Ordering. Evaluate each direction at the path divergence, decide every class from the one walk, expose the provider to dma-buf importers, and let mlx5 ask rather than assume. Signed-off-by: Leon Romanovsky <leonro(a)nvidia.com> --- Changes in v5: - Rebase on the posted fixes. - Dropped tags from changed patches. - Remove Egress Control Vector interpretation and coverage. - Keep enabled Egress Control conservative as a Request redirect. - Use pci_dbg()/dev_dbg() for diagnostics and drop the "debug" prefix. - Removed code comments from "Document the pdev->p2pdma lifetime and RCU rules" patch and reduced description to actual lifetime explanation. - Added note that Linux assumes that TLPs are in strict-ordering and untranslated. - Added code to calculate p2p paths per-TLP type. - Converted mlx5 to use that new proposed API. - Link to https://patch.msgid.link/20260821-fix-p2p-acs-v4-0-v4-0-94426b96de73@nvidia… Changes in v4: - Reject ACS Violations and unreadable routing state instead of treating them as host-bridge redirects - Added Tested-by tags from Tushar Dave - Added support to asymmetric ACS routing - Limited redirect checks to the two ports at the path divergence - Added standalone ACS routing diagnostics for hardware retesting - Dropped " PCI: Account for Direct Translated P2P in ACS isolation checks" patch - Link to v3: https://patch.msgid.link/20260811-fix-p2p-acs-v3-0-efc488ee7c03@nvidia.com Changes in v3: - Fixed pci_p2pdma_add_resource() error unwinding - Made pdev->p2pdma teardown wait unconditionally for RCU readers - Restricted pci_p2pmem_find_many() to pool-backed providers - Documented the pdev->p2pdma lifetime and RCU rules - Fixed calc_map_type_and_dist() handling of the verbose argument - Required the ACS port and target to share a bus before indexing the Egress Control Vector - Gave pci_acs_enabled() and pci_acs_path_enabled() a scope, so the ACS Direct Translated P2P rule no longer stops pci_enable_pasid() from enabling PASID - Dropped "Report ACS ports when the paths share no upstream bridge": the mapping type cannot change without a shared upstream bridge, so the pci=disable_acs_redir= hint was not actionable there and the ACS walk only cost config space reads - Folded the Request Redirect rule into pci_acs_rr_ineffective(), so pci_acs_flags_enabled() and the Intel SPT PCH quirk share one copy - Renamed pci_acs_egress_ctrl_set() to pci_acs_egress_ctrl_is_set(), it reads the bit rather than setting it - Reworded the blocked-path warning: ACS may also leave the direct route indeterminate rather than blocked - Added KUnit coverage for the shared-bus guard, a device with no ACS capability and an unreadable ACS Control register - Added the missing Fixes: tags, a second one on the pci_p2pdma_add_resource() unwinding fix (the dangling devres action dates to f58ef9d1d135) and one on the Egress Control isolation change - Link to v2: https://patch.msgid.link/20260806-fix-p2p-acs-v2-0-0cec14812965@nvidia.com Changes in v2: - Added Logan's ROB tags - Added commas in Documentation patch - Link to v1: https://patch.msgid.link/20260802-fix-p2p-acs-v1-0-a7c5eb64fff6@nvidia.com --- Leon Romanovsky (18): PCI/P2PDMA: Document pdev->p2pdma lifetime rules PCI/P2PDMA: Document the TLP attribute assumptions PCI/P2PDMA: Derive routing from directional ACS controls PCI: Reject unreadable ACS controls in isolation checks PCI/P2PDMA: Evaluate ACS controls at the path divergence PCI/P2PDMA: Document directional ACS routing PCI/P2PDMA: Collect the path's ACS controls before deciding PCI/P2PDMA: Answer routing per TLP class PCI/P2PDMA: Route Relaxed Ordering Completions directly PCI/P2PDMA: Reject Translated Requests blocked by Translation Blocking PCI/P2PDMA: Route Translated Requests under Direct Translated P2P PCI/P2PDMA: Log detailed ACS routing diagnostics PCI/P2PDMA: Add KUnit tests for the ACS routing decisions PCI/P2PDMA: Test the ACS P2P routing walk PCI: Add KUnit coverage for ACS isolation checks PCI/P2PDMA: Document TLP-class routing dma-buf: Let importers ask how peer-to-peer traffic is routed RDMA/mlx5: Ask P2PDMA whether ATS takes a direct peer-to-peer route Documentation/admin-guide/kernel-parameters.txt | 9 +- Documentation/driver-api/pci/p2pdma.rst | 69 +++ drivers/dma-buf/dma-buf-mapping.c | 41 +- drivers/dma-buf/dma-buf.c | 1 + drivers/infiniband/core/uverbs.h | 1 - drivers/infiniband/core/uverbs_std_types_dmabuf.c | 7 +- drivers/infiniband/hw/mlx5/mlx5_ib.h | 36 +- drivers/infiniband/hw/mlx5/mr.c | 40 ++ drivers/pci/Kconfig | 15 + drivers/pci/Makefile | 1 + drivers/pci/p2pdma.c | 637 +++++++++++++++++++--- drivers/pci/pci.c | 7 +- drivers/pci/pci.h | 26 + drivers/pci/pci_acs_test.c | 609 +++++++++++++++++++++ drivers/pci/quirks.c | 6 +- drivers/vfio/pci/vfio_pci_dmabuf.c | 8 +- include/linux/dma-buf-mapping.h | 4 +- include/linux/dma-buf.h | 5 + include/linux/pci-p2pdma.h | 57 +- 19 files changed, 1440 insertions(+), 139 deletions(-) --- base-commit: 08dbfad3f5040f5bdb6c529da20d6d4e81fefd72 change-id: 20260821-fix-p2p-acs-v4-0-e72455e3a261 prerequisite-message-id: <20260830-batch-p2p-fixes-v1-0-5044e8dfbe2e(a)nvidia.com> prerequisite-patch-id: 6b25c7fcf164cdfc14e9fac5b908d97fcf6509d7 prerequisite-patch-id: 0d083c281001365aae4b35544cf28891a6ab9a96 prerequisite-patch-id: bfd9dabf271f3cc9a3a61f46387d20c20311363d prerequisite-patch-id: fad0275efc722830fc591509506c0a5e4f581073 prerequisite-patch-id: 0c83bee688fec1f6d1564654df7c630fa6a4a978 Best regards, -- Leon Romanovsky <leonro(a)nvidia.com>

1 month, 2 weeks

← Newer
1
...
8
9
10
11
12
13
14
...
367
Older →

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

Linaro-mm-sig