Hi everyone,
dma_fences have ever lived under the tyranny dictated by the module
lifetime of their issuer, leading to crashes should anybody still holding
a reference to a dma_fence when the module of the issuer was unloaded.
The basic problem is that when buffer are shared between drivers
dma_fence objects can leak into external drivers and stay there even
after they are signaled. The dma_resv object for example only lazy releases
dma_fences.
So what happens is that when the module who originally created the dma_fence
unloads the dma_fence_ops function table becomes unavailable as well and so
any attempt to release the fence crashes the system.
Previously various approaches have been discussed, including changing the
locking semantics of the dma_fence callbacks (by me) as well as using the
drm scheduler as intermediate layer (by Sima) to disconnect dma_fences
from their actual users, but none of them are actually solving all problems.
Tvrtko did some really nice prerequisite work by protecting the returned
strings of the dma_fence_ops by RCU. This way dma_fence creators where
able to just wait for an RCU grace period after fence signaling before
they could be save to free those data structures.
Now this patch set here goes a step further and protects the whole
dma_fence_ops structure by RCU, so that after the fence signals the
pointer to the dma_fence_ops is set to NULL when there is no wait nor
release callback given. All functionality which use the dma_fence_ops
reference are put inside an RCU critical section, except for the
deprecated issuer specific wait and of course the optional release
callback.
Additional to the RCU changes the lock protecting the dma_fence state
previously had to be allocated external. This set here now changes the
functionality to make that external lock optional and allows dma_fences
to use an inline lock and be self contained.
This patch set addressed all previous code review comments and is based
on drm-tip, includes my changes for amdgpu as well as Mathew's patches for XE.
Going to push the core DMA-buf changes to drm-misc-next as soon as I get
the appropriate rb. The driver specific changes can go upstream through
the driver channels as necessary.
Please review and comment,
Christian.
Andy,
> Use %ptS instead of open coded variants to print content of
> struct timespec64 in human readable format.
Reviewed-by: Martin K. Petersen <martin.petersen(a)oracle.com>
--
Martin K. Petersen
Andy,
> Use %ptSp instead of open coded variants to print content of
> struct timespec64 in human readable format.
Reviewed-by: Martin K. Petersen <martin.petersen(a)oracle.com>
--
Martin K. Petersen
On Sun, 09 Nov 2025 23:37:54 +0200 Roger Quadros wrote:
> + ndev->stats.rx_dropped++;
AFAIU the device is multi-queue so using per-device stats looks racy.
Please create your own per queue stats.
On Sun, 09 Nov 2025 23:37:57 +0200 Roger Quadros wrote:
> In am65_cpsw_nuss_rx_poll() there is a possibility that irq_disabled flag
> is cleared but the IRQ is not enabled.
>
> This patch fixes by that by clearing irq_disabled flag right when enabling
> the irq.
>
> Fixes: da70d184a8c3 ("net: ethernet: ti: am65-cpsw: Introduce multi queue Rx")
> Signed-off-by: Roger Quadros <rogerq(a)kernel.org>
This looks independent from the series, it needs to go to net.
--
pw-bot: cr
On Sun, 09 Nov 2025 23:37:50 +0200 Roger Quadros wrote:
> This series adds AF_XDP zero coppy support to am65-cpsw driver.
>
> Tests were performed on AM62x-sk with xdpsock application [1].
>
> A clear improvement is seen in 64 byte packets on Transmit (txonly)
> and receive (rxdrop).
> 1500 byte test seems to be limited by line rate (1G link) so no
> improvement seen there in packet rate. A test on higher speed link
> (or PHY-less setup) might be worthwile.
>
> There is some issue during l2fwd with 64 byte packets and benchmark
> results show 0. This issue needs to be debugged further.
> A 512 byte l2fwd test result has been added to compare instead.
It appears that the drivers/net/ethernet/ti/am65-* files do not fall
under any MAINTAINERS entry. Please add one or extend the existing CPSW
entry as the first patch of the series.
On 11/10/25 21:42, Alex Williamson wrote:
> On Thu, 6 Nov 2025 16:16:45 +0200
> Leon Romanovsky <leon(a)kernel.org> wrote:
>
>> Changelog:
>> v7:
>> * Dropped restore_revoke flag and added vfio_pci_dma_buf_move
>> to reverse loop.
>> * Fixed spelling errors in documentation patch.
>> * Rebased on top of v6.18-rc3.
>> * Added include to stddef.h to vfio.h, to keep uapi header file independent.
>
> I think we're winding down on review comments. It'd be great to get
> p2pdma and dma-buf acks on this series. Otherwise it's been posted
> enough that we'll assume no objections. Thanks,
Already have it on my TODO list to take a closer look, but no idea when that will be.
This patch set is on place 4 or 5 on a rather long list of stuff to review/finish.
Christian.
>
> Alex
On (25/11/10 19:40), Andy Shevchenko wrote:
[..]
> + dev_dbg(smi_info->io.dev, "**%s: %ptSp\n", msg, &t);
Strictly speaking, this is not exactly equivalent to %lld.%9.9ld
or %lld.%6.6ld but I don't know if that's of any importance.