On Tue, Apr 24, 2018 at 05:46:52PM +0200, Michel DÃnzer wrote:
Adding the dri-devel list, since this is driver independent code.You want fatal_signal_pending() here, instead of inventing your own broken
On 2018-04-24 05:30 PM, Andrey Grodzovsky wrote:
Avoid calling wait_event_killable when you are possibly being calledMultiple typos here, "[...] already blocked in signal processing and [...]"?
from get_signal routine since in that case you end up in a deadlock
where you are alreay blocked in singla processing any trying to wait
on a new signal.
Signed-off-by: Andrey Grodzovsky <andrey.grodzovsky@xxxxxxx>
drivers/gpu/drm/scheduler/gpu_scheduler.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/scheduler/gpu_scheduler.c b/drivers/gpu/drm/scheduler/gpu_scheduler.c
index 088ff2b..09fd258 100644
@@ -227,9 +227,10 @@ void drm_sched_entity_do_release(struct drm_gpu_scheduler *sched,
* The client will not queue more IBs during this fini, consume existing
- * queued IBs or discard them on SIGKILL
+ * queued IBs or discard them when in death signal state since
+ * wait_event_killable can't receive signals in that state.
- if ((current->flags & PF_SIGNALED) && current->exit_code == SIGKILL)
+ if (current->flags & PF_SIGNALED)
But really this smells like a bug in wait_event_killable, sinceentity->fini_status = -ERESTARTSYS;
entity->fini_status = wait_event_killable(sched->job_scheduled,
wait_event_interruptible does not suffer from the same bug. It will return
immediately when there's a signal pending.
I think this should be fixed in core code, not papered over in some
Earthling Michel DÃnzer | http://www.amd.com
Libre software enthusiast | Mesa and X developer
dri-devel mailing list