Re: [PATCH] usb: atm: Make use of the helper macro kthread_run()

[Duncan Sands]

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@xxxxxxxxx>
> ---
>   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;