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.