linuxkpi: populate the acquire context field of a ww_mutex

[val_packett.cool]

Summary

The ww_mutex API in Linux is supposed to implement the "Wound/Wait Deadlock-Proof Mutex" thing. Seems like we have a different deadlock-proof mutex in its place, which might be fine (I'm not a locking expert), but we definitely have to respect the API. Specifically, consumers expect the ctx field to actually be populated with the ctx the locking function was called with!

 /* Double check that the BO is reserved by this CS */ 
 if (dma_resv_locking_ctx((*bo)->tbo.base.resv) != &parser->ticket) 
 	return -EINVAL;

// where dma_resv_locking_ctx(obj) just returns READ_ONCE(obj->lock.ctx)

When this fails (and it's failing due to ctx always being zero), VAAPI video codec acceleration on amdgpu breaks.
https://github.com/freebsd/drm-kmod/issues/32

---

For reference, DragonFly has a "basic, unoptimized implementation of wound/wait mutexes" that actually does use the context for the locking algorithm, and does not have a global mutex or the thread list stuff..

https://github.com/DragonFlyBSD/DragonFlyBSD/blob/master/sys/dev/drm/linux_wwmutex.c
https://github.com/DragonFlyBSD/DragonFlyBSD/blob/master/sys/dev/drm/include/linux/ww_mutex.h

*Maybe* adopting their thing would be more "correct"? But let's do the hot fix for the video acceleration first.

Test Plan

Running e.g. mpv -v --hwdec=vaapi some-thing.mp4 on an AMD GPU (older than Raven, Navi etc. — the newest "Video Core Next" codec hardware doesn't use this code path) easily hits the check failure.

[• hselasky]

Looks good. You need someone to commit this?

Was the testing OK?

--HPS

[bz]

Looks okay to me as well. The two minor things may be ignored.

sys/compat/linuxkpi/common/include/linux/ww_mutex.h

79 ↗

(On Diff #77840)

The extern wasn't needed before and neither now. Ideally the prototype is before the first function.

sys/compat/linuxkpi/common/src/linux_lock.c

74 ↗

(On Diff #77840)

possibly wrap the long line.