On Wed, 11 Feb 2026 16:20:15 +0100
Philipp Stanner [off-list ref] wrote:

On Wed, 2026-02-11 at 15:17 +0000, Alice Ryhl wrote:

quoted

On Wed, Feb 11, 2026 at 03:07:38PM +0100, Boris Brezillon wrote:  

quoted

Back to this particular job dependencies use case: we have to embed the
DmaFence pointer in some wrapper with the ListLinks element anyway,
because DmaFences can be inserted in multiple of those lists in
parallel.  

Okay, if that's the case, then the linked list is *really* not the right
tool for the job.  

We have to distinguish what we are talking about here.

For the JobQueue, it takes over a cloned DmaFence and stuffs that into
its own list. Problem solved.

Whether the driver has other clones of that fence in other list is not
relevant because it's not the same list head.

JQ's lists and list heads are internal.

I don't see a problem.

Both the list and xarray-based implementions will work, but what you end
up with when you use a list is items that look like:

struct Dependency {
	// Two pointers to insert the element in the list
	link: ListLinks,

	// The pointer to your fence
	fence: ARef<DmaFence>,
}

vs just the ARef<DmaFence> that's stored as a ForeignOwnable pointer in
some xarray entry. So the list overhead is still very much present, with
none of the benefits of the direct access you'd get if you were having
something like:

struct DmaFence {
	// Two pointers to insert the element in the list dependency
	list link: ListLinks,

	// Put the rest of the DmaFence stuff there
	...
}

which you can't have because a DmaFence can be in multiple dependency
lists at the same time.