Re: signal: break out of wait loops on kthread_stop()

From: Tvrtko Ursulin
Date: Wed Oct 19 2022 - 09:46:45 EST



Hi,

A question regarding a7c01fa93aeb ("signal: break out of wait loops on kthread_stop()") if I may.

We have a bunch code in i915, possibly limited to self tests (ie debug builds) but still important for our flows, which spawn kernel threads and exercises parts of the driver.

Problem we are hitting with this patch is that code did not really need to be signal aware until now. Well to say that more accurately - we were able to test the code which is normally executed from userspace, so is signal aware, but not worry about -ERESTARTSYS or -EINTR within the test cases itself.

For example threads which exercise an internal API for a while until the parent calls kthread_stop. Now those tests can hit unexpected errors.

Question is how to best approach working around this change. It is of course technically possible to rework our code in more than one way, although with some cost and impact already felt due reduced pass rates in our automated test suites.

Maybe an opt out kthread flag from this new behavior? Would that be acceptable as a quick fix? Or any other comments?

Regards,

Tvrtko