linux-kernel - Re: [PATCH] usb: atm: Make use of the helper macro kthread

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: <95677103-075b-62a8-8a6b-4de1f81b25e3@free.fr>
Date:   Thu, 21 Oct 2021 10:56:21 +0200
From:   Duncan Sands <duncan.sands@...e.fr>
To:     Cai Huoqing <caihuoqing@...du.com>
Cc:     Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        linux-usb@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] usb: atm: Make use of the helper macro kthread_run()

Hi Cai Huoqing,

On 21/10/2021 10:43, Cai Huoqing wrote:
> Repalce kthread_create/wake_up_process() with kthread_run()
> to simplify the code.
> 
> Signed-off-by: Cai Huoqing <caihuoqing@...du.com>
> ---
>   drivers/usb/atm/usbatm.c | 3 +--
>   1 file changed, 1 insertion(+), 2 deletions(-)
> 
> diff --git a/drivers/usb/atm/usbatm.c b/drivers/usb/atm/usbatm.c
> index da17be1ef64e..b1ea3c6384f9 100644
> --- a/drivers/usb/atm/usbatm.c
> +++ b/drivers/usb/atm/usbatm.c
> @@ -976,7 +976,7 @@ static int usbatm_heavy_init(struct usbatm_data *instance)
>   {
>   	struct task_struct *t;
>   
> -	t = kthread_create(usbatm_do_heavy_init, instance, "%s",
> +	t = kthread_run(usbatm_do_heavy_init, instance, "%s",
>   			instance->driver->driver_name);
>   	if (IS_ERR(t)) {
>   		usb_err(instance, "%s: failed to create kernel_thread (%ld)!\n",
> @@ -985,7 +985,6 @@ static int usbatm_heavy_init(struct usbatm_data *instance)
>   	}
>   
>   	instance->thread = t;
> -	wake_up_process(t);

doesn't this mean that the thread may now start running before instance->thread 
has been assigned?  It's not clear to me what race conditions this may open up, 
if any (I haven't looked at the code in a long time), but it does need to be 
carefully analyzed.  So I can't sign off on this as it stands.

Best wishes, Duncan.

>   	wait_for_completion(&instance->thread_started);
>   
>   	return 0;
>