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.
Attachment:
pgpF0EW3rsGIw.pgp
Description: PGP signature
_______________________________________________ Kernelnewbies mailing list Kernelnewbies@xxxxxxxxxxxxxxxxx https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
