> Date: Mon, 21 Jul 2025 11:36:15 +0300
> From: Vitaliy Makkoveev <mvs@openbsd.org>
> 
> On Mon, Jul 21, 2025 at 05:10:45PM +1000, Jonathan Gray wrote:
> > On Fri, Jul 18, 2025 at 11:31:05PM +0300, Vitaliy Makkoveev wrote:
> > > The resurrection my old diff. No reason for X to stuck in kernel lock
> > > while polling.
> > > 
> > > The `event_lock' mutex(9) is already protects `event_list' checked by
> > > filt_drmread(), so use it to protect the `drmread_filtops' too.
> > > 
> > > The filt_drmkms() doesn't touch any data and could be easily converted
> > > to always return 1, so the lock is only required for `drm_filtops'.
> > > Introduce the new `note_mtx' mutex(9) for that purpose.
> > > 
> > > I have no radeondrm(4), so tested with inteldrm(4) only. Previous time I
> > > had successful reports from people with radeondrm(4) too.
> > 
> > I'm not sure of the best way to test this or what any problems would
> > look like.
> > 
> > In general I'm concerned about unlocking drm due to rcu.
> > 
> > on t500 with rv635 radeondrm and this patch
> > 
> > 7747 tests into 44335 on piglit
> > 
> > drm:pid11671:radeon_ring_test_lockup *ERROR* ring 0 stalled for more than 10170msec
> > drm:pid11671:radeon_fence_check_lockup *WARNING* GPU lockup (current fence id 0x0000000000088108 last fence id 0x0000000000088114 on ring 0)
> > ..
> > [drm] *ERROR* radeon: fence wait failed (-11).
> > [drm] *ERROR* radeon: failed testing IB on GFX ring (-11).
> > 
> > and windows in X stop updating, cursor still moves, and can switch vt
> > 
> > on reboot
> > WARNING bo->pin_count failed at /usr/src/sys/dev/pci/drm/ttm/ttm_bo.c:252
> > 
> > Without the patch I also see the ring stalls around the same place.
> > But the entire screen is black, which doesn't change on switching vt.
> 
> This is not the whole DRM unlocking, this diff only unlocks the userland
> event notification interface, to poll() or kevent() do not stuck into
> kernel lock. The rest is locked as is.
> 
> Please note, the filt_drmread() already takes the `event_lock' mutex(9),
> so this diff brings nothing new in this path. The filt_drmkms()
> touches no shared data, the mutex(9) required only to protect kevent
> data.

But it does change the timing of those events.