linux-kernel - [PATCH 0/4] dma-buf/fence-chain: Speed up processing of rearmed callbacks

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Message-ID: <20250814094824.217142-6-janusz.krzysztofik@linux.intel.com>
Date: Thu, 14 Aug 2025 10:16:11 +0200
From: Janusz Krzysztofik <janusz.krzysztofik@...ux.intel.com>
To: Christian König <christian.koenig@....com>
Cc: Sumit Semwal <sumit.semwal@...aro.org>,
	Gustavo Padovan <gustavo@...ovan.org>,
	Chris Wilson <chris.p.wilson@...ux.intel.com>,
	linux-media@...r.kernel.org,
	dri-devel@...ts.freedesktop.org,
	linaro-mm-sig@...ts.linaro.org,
	linux-kernel@...r.kernel.org,
	intel-gfx@...ts.freedesktop.org,
	intel-xe@...ts.freedesktop.org,
	Janusz Krzysztofik <janusz.krzysztofik@...ux.intel.com>
Subject: [PATCH 0/4] dma-buf/fence-chain: Speed up processing of rearmed callbacks

CI results indicate excessive time spent on processing of wait_backward
selftest.  The test case enables signaling on each link of a 4096 links
long chain, then signals those links one after another in reverse order.
That scanario corresponds to user space potentially building a dma_fence
chain of an arbitrary length step by step, e.g. via drm_syncobj IOCTLs,
and each step waiting on a chain link it has added.

When first user starts waiting on a not yet signaled fence of a chain
link, or signaling is explicitly enabled on it, a dma_fence_chain callback
is added to a user fence of that link.  When the user fence of that chain
link is then signaled, the chain is traversed in search for a first not
signaled link and the callback is rearmed on a user fence of that link.
Each time an arbitrary user fence is signaled, all dma_fence_chain
callbacks added to it so far must be rearmed to another user fence of the
chain.  In extreme scenarios, when all N links of a chain are awaited and
then signaled in reverse order, the dma_fence_chain callback may be called
up to N * (N + 1) / 2 times (an arithmetic series).

To avoid that potential excessive accumulation of dma_fence_chain
callbacks, rearm a trimmed-down, signal only callback version to the base
fence of a previous link, if not yet signaled, otherwise just signal the
base fence of the current link instead of traversing the chain in search
for a first not signaled link and moving all callbacks collected so far to
a user fence of that link.

For more clear correspondence to a potential userspace scenario, update
the wait_* selftests so they actually wait on each link fence of the chain
instead of just enabling signaling.  For easy evaluation of the change
impact, report processing time of signaling loop of each wait_* test case.

Janusz Krzysztofik (4):
  dma-buf/fence-chain: Report time spent in wait_* test cases
  dma-buf/fence-chain: Let test cases decide which fence to wait on
  dma-buf/fence-chain: Wait on each tested chain link
  dma-buf/fence-chain: Speed up processing of rearmed callbacks

 drivers/dma-buf/dma-fence-chain.c    | 101 ++++++++++++++++----
 drivers/dma-buf/st-dma-fence-chain.c | 133 +++++++++++++++++++++------
 2 files changed, 189 insertions(+), 45 deletions(-)

-- 
2.50.1