Re: proper way to terminate a kthread when the parent process dies ?

From: Konstantin Belousov <kostikbel_at_gmail.com>
Date: Tue, 4 Aug 2015 17:53:11 +0300
On Tue, Aug 04, 2015 at 04:38:14PM +0200, Luigi Rizzo wrote:
> Hi,
> we have a doubt on the proper way to terminate a kernel thread that
> has been associated to a user process U within a system call with
> 
>         kthread_add( .. , .., p, ... )
> 
> (p is the struct proc * of the calling process, U)
> 
> When U terminates and goes into kern_exit.c :: exit1()
> the kernel thread sees the following conditions:
> 
>         P_SHOULDSTOP(td->td_proc) is TRUE
> 
> td->td_flags has TDF_ASTPENDING | TDF_NEEDSUSPCHK set
> 
> We are not sure what is the proper way to terminate
> our kernel thread, whose body is the following:
> 
>         while (must_run) { // someone will set must_run = 0
>                 <check_for_forced_termination>
>                 kthread_suspend_check(); // void
>                 work_or_short_tsleep(); // potentially se
>         }
>         kthread_exit();
> 
> We have seen different ways for the <check_for_forced_termination>
> 
> 1.      if (P_SHOULDSTOP(td->td_proc)
>                 break; // kthread_exit() is called outside the loop
> 
> 2.      if (P_SHOULDSTOP(td->td_proc)
>                 thread_suspend_check(0); // which then terminates the thread
>         // this is done in sys/rpc/svc.c
> 
> We are a bit unsure whether calling the thread_*() function in a kthread
> is correct -- but there is an example in the kernel.
> 
> Variants involve locking td->td_proc (but is it necessary ? The process
> won't go away until all child threads die), or checking the td_tdflags
> instead of the parent process' flags.
> 
> So what is the correct way ?

If this is a thread of the normal user process, then it is not a kernel
thread, even if it never leaves the kernel mode.

You must call thread_suspend_check() in any in-kernel loop to allow the
stops and process exit to work.
Received on Tue Aug 04 2015 - 12:53:20 UTC

This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:40:59 UTC