From: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com>
To: "Jason A. Donenfeld" <Jason@zx2c4.com>,
"Eric W. Biederman" <ebiederm@xmission.com>
Cc: linux-kernel@vger.kernel.org,
"Intel-gfx@lists.freedesktop.org"
<Intel-gfx@lists.freedesktop.org>,
"Ville Syrjälä" <ville.syrjala@linux.intel.com>
Subject: Re: signal: break out of wait loops on kthread_stop()
Date: Wed, 19 Oct 2022 14:31:01 +0100 [thread overview]
Message-ID: <0029af41-bf24-9972-10ac-f52e1bdcbf08@linux.intel.com> (raw)
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
next reply other threads:[~2022-10-19 13:46 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-10-19 13:31 Tvrtko Ursulin [this message]
2022-10-19 16:00 ` signal: break out of wait loops on kthread_stop() Jason A. Donenfeld
2022-10-19 16:01 ` Jason A. Donenfeld
2022-10-19 17:57 ` Tvrtko Ursulin
2022-10-19 18:16 ` Jason A. Donenfeld
2022-10-19 19:05 ` Sultan Alsawaf
2022-10-19 20:09 ` Tvrtko Ursulin
2022-10-19 20:19 ` [Intel-gfx] " Jason A. Donenfeld
2022-10-20 13:45 ` Tvrtko Ursulin
2022-11-28 18:22 ` Eric W. Biederman
2022-11-28 18:27 ` Jason A. Donenfeld
2022-11-30 15:26 ` Eric W. Biederman
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=0029af41-bf24-9972-10ac-f52e1bdcbf08@linux.intel.com \
--to=tvrtko.ursulin@linux.intel.com \
--cc=Intel-gfx@lists.freedesktop.org \
--cc=Jason@zx2c4.com \
--cc=ebiederm@xmission.com \
--cc=linux-kernel@vger.kernel.org \
--cc=ville.syrjala@linux.intel.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox