linux-kernel - Re: [PATCH] x86/process: fix the misleading comment about PF_USER_WORKERs in copy

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <7996ef64-59af-4146-be76-95a8aeccfc7a@intel.com>
Date: Wed, 20 Aug 2025 14:42:08 -0700
From: Dave Hansen <dave.hansen@...el.com>
To: Oleg Nesterov <oleg@...hat.com>, Borislav Petkov <bp@...en8.de>,
 Dave Hansen <dave.hansen@...ux.intel.com>, Ingo Molnar <mingo@...hat.com>,
 Peter Zijlstra <peterz@...radead.org>, Thomas Gleixner <tglx@...utronix.de>
Cc: Rick Edgecombe <rick.p.edgecombe@...el.com>,
 Mark Brown <broonie@...nel.org>, x86@...nel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] x86/process: fix the misleading comment about
 PF_USER_WORKERs in copy_thread()

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.