The comment says "doesn't return to ret_after_fork()" but in fact it should
say "doesn't return from ret_from_fork()".

Plus the comment lacks some important details, and even "user space thread"
doesn't look accurate, if nothing else this doesn't match the comment about
PF_USER_WORKER in include/linux/sched.h.

Signed-off-by: Oleg Nesterov <oleg@redhat.com>
---
 arch/x86/kernel/process.c | 12 +++++++++---
 1 file changed, 9 insertions(+), 3 deletions(-)

diff --git a/arch/x86/kernel/process.c b/arch/x86/kernel/process.c
index e932e0e53972..cc4fe540d952 100644
--- a/arch/x86/kernel/process.c
+++ b/arch/x86/kernel/process.c
@@ -237,14 +237,20 @@ int copy_thread(struct task_struct *p, const struct kernel_clone_args *args)
 
 	if (unlikely(args->fn)) {
 		/*
-		 * A user space thread, but it doesn't return to
-		 * ret_after_fork().
+		 * A non-PF_KTHREAD thread, but it doesn't return from
+		 * ret_from_fork().
+		 *
+		 * Either a PF_USER_WORKER kernel thread, in this case
+		 * arg->fn() must not return.
+		 * Or a user space task created by user_mode_thread(), in
+		 * this case arg->fn() can only return after a successful
+		 * kernel_execve().
 		 *
 		 * In order to indicate that to tools like gdb,
 		 * we reset the stack and instruction pointers.
 		 *
 		 * It does the same kernel frame setup to return to a kernel
-		 * function that a kernel thread does.
+		 * function that a PF_KTHREAD thread does.
 		 */
 		childregs->sp = 0;
 		childregs->ip = 0;
-- 
2.25.1.362.g51ebf55

On 8/20/25 09:46, Oleg Nesterov wrote:
>  	if (unlikely(args->fn)) {
>  		/*
> -		 * A user space thread, but it doesn't return to
> -		 * ret_after_fork().
> +		 * A non-PF_KTHREAD thread, but it doesn't return from
> +		 * ret_from_fork().
> +		 *
> +		 * Either a PF_USER_WORKER kernel thread, in this case
> +		 * arg->fn() must not return.
> +		 * Or a user space task created by user_mode_thread(), in
> +		 * this case arg->fn() can only return after a successful
> +		 * kernel_execve().
>  		 *
>  		 * In order to indicate that to tools like gdb,
>  		 * we reset the stack and instruction pointers.
>  		 *
>  		 * It does the same kernel frame setup to return to a kernel
> -		 * function that a kernel thread does.
> +		 * function that a PF_KTHREAD thread does.
>  		 */

I'm not sure that comment clarifies things, especially the new
paragraph. This does _not_ seem like the place to me to be explaining
what the conventions are around arg->fn(). It would be better to put it
near the definition or 'kernel_clone_args' or the place the function
gets called, but not here.

On 08/20, Dave Hansen wrote:
>
> On 8/20/25 09:46, Oleg Nesterov wrote:
> >  	if (unlikely(args->fn)) {
> >  		/*
> > -		 * A user space thread, but it doesn't return to
> > -		 * ret_after_fork().
> > +		 * A non-PF_KTHREAD thread, but it doesn't return from
> > +		 * ret_from_fork().
> > +		 *
> > +		 * Either a PF_USER_WORKER kernel thread, in this case
> > +		 * arg->fn() must not return.
> > +		 * Or a user space task created by user_mode_thread(), in
> > +		 * this case arg->fn() can only return after a successful
> > +		 * kernel_execve().
> >  		 *
> >  		 * In order to indicate that to tools like gdb,
> >  		 * we reset the stack and instruction pointers.
> >  		 *
> >  		 * It does the same kernel frame setup to return to a kernel
> > -		 * function that a kernel thread does.
> > +		 * function that a PF_KTHREAD thread does.
> >  		 */
>
> I'm not sure that comment clarifies things,

OK, lets forger this patch then. But note that the 1st paragraph is
obviously wrong.

> especially the new
> paragraph.

I was going to fix the typos in the 1st paragraph, then decided to add more
details to clarify "doesn't return" and to "sync" this comment with the
related comment in ret_from_fork().

And to make it clear that PF_USER_WORKER can never return to usermode, this
connects to the recent discussion about PF_USER_WORKER && shstk.

> This does _not_ seem like the place to me to be explaining
> what the conventions are around arg->fn(). It would be better to put it
> near the definition or 'kernel_clone_args' or the place the function
> gets called, but not here.

Not sure. To me this comment is more about kthread_frame_init() and
ret_from_fork(). But I won't argue.

Oleg.