From: Vitaliy Makkoveev Subject: Re: mp-safe drm*_filtops To: Mark Kettenis Cc: tech@openbsd.org Date: Mon, 21 Jul 2025 13:29:26 +0300 On Mon, Jul 21, 2025 at 11:45:33AM +0200, Mark Kettenis wrote: > > Date: Mon, 21 Jul 2025 11:36:15 +0300 > > From: Vitaliy Makkoveev > > > > 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. You really think those timings are determined?