call task_del() from destroy_work_on_stack()
authorjsg <jsg@openbsd.org>
Sat, 14 Aug 2021 03:12:51 +0000 (03:12 +0000)
committerjsg <jsg@openbsd.org>
Sat, 14 Aug 2021 03:12:51 +0000 (03:12 +0000)
commitea7e6ab010a57eec5559d382527ec3e6772492b9
tree617c837170936ae9930c82d1a9f00d2b6a155379
parent28a7cae827fddbcf788e073b25512aeb91d295db
call task_del() from destroy_work_on_stack()

prompted by jcs@ reporting a protection fault trap in
drm_mode_rmfb_work_fn() while playing a youtube video in firefox on a
kaby lake machine.  He later saw the same trace on tiger lake.

The previous attempt to avoid this situation by changing work flush
functions from taskq_barrier() to taskq_del_barrier() resulted in
suspend sometimes not working on various intel based thinkpads.

The only code we build which calls destroy_work_on_stack() is in
drm_framebuffer.c so the scope of this change is more limited.
Linux only uses destroy_work_on_stack() for debugging so the workqueue
behaviour still doesn't match.

This version is confirmed to not break suspend on x260 by sthen@ and
x280 by tb@ and still avoids the original problem according to jcs@
sys/dev/pci/drm/include/linux/workqueue.h