kthread_stop always returning -EINTR?

[valdis.kletnieks at vt.edu]

On Tue, 18 Jul 2017 17:11:19 -0300, Martin Galvan said:
> task_struct, it's not clear to me why I didn't get to see the thread
> function printks. If the thread function finished before reaching
> kthread_stop, I should be able to see them, right? The only way I can
> see them is by removing the call to kthread_stop altogether. This
> makes it seem like kthread_stop kills the new thread before it gets a
> chance to run, yet that goes against the description in the comments.

That's another way the race condition can play out - you wake it up,
then re-stop it, before it gets a first shot at running. Remember, waking
up and stopping processes is *not* a synchronous process.

There's also the possibility that with the busted kthread_stop, you're
managing to trample on something related to kernel logging.

Really - if that thread is gone, the kthread_stop() is corrupting random
memory, and all bets are off...

And of course, double-check that you've got your syslog/dmesg/etc actually
configured to log KERN_DEBUG messages - if changing them to KERN_ALERT makes
them magically appear, that's your problem.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 486 bytes
Desc: not available
Url : http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20170718/91fc3896/attachment.bin