On Tue, Aug 04, 2015 at 05:32:28PM +0200, Luigi Rizzo wrote:
> On Tue, Aug 4, 2015 at 4:53 PM, Konstantin Belousov <kostik...@gmail.com> 
> wrote:
> > 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.
> thanks for the answer.
> i do not really know what is the difference between a "kernel thread"
> and a "thread".
> Could you clarify what is the distinctive feature between the two ?
> Perhaps being owned by pid 0 ?
No.  I probably having troubles answering this exact question.  TDP_KTHREAD
is used as a shortcut in several places, mostly to avoid some specific
actions that are useless for the real kernel process.  E.g. the amd64
context switch code avoids setting some CPU registers when switching to
the kernel thread.  Hacks to not switch address spaces when switching 
to the kthread were already removed.

Overall, claiming that a thread of the normal user process (i.e. process
which executes in userspace) is kernel thread is fragile and, if not
breaking in your tests, could break later.
> This specific thread is created within a system call by invoking kthread_add()
> and associated with the user process.
Did you tried the other approach, by creating the thread from userspace,
and then executing the syscall which would loop ?  This is how things are
done by e.g. nfsd.

Still, if you looping in the kernel, you must call thread_suspend_check()
> >
> > You must call thread_suspend_check() in any in-kernel loop to allow the
> > stops and process exit to work.
> so does it mean that the kthread_suspend_check() is incorrect and we should
> use thread_suspend_check() instead ?
Most likely yes.
freebsd-current@freebsd.org mailing list
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Reply via email to