Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
Message-ID: <95677103-075b-62a8-8a6b-4de1f81b25e3@free.fr>
Date:   Thu, 21 Oct 2021 10:56:21 +0200
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101
 Thunderbird/91.1.2
Subject: Re: [PATCH] usb: atm: Make use of the helper macro kthread_run()
Content-Language: en-US
To:     Cai Huoqing <caihuoqing@baidu.com>
Cc:     Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
        linux-usb@vger.kernel.org, linux-kernel@vger.kernel.org
References: <20211021084351.2554-1-caihuoqing@baidu.com>
From:   Duncan Sands <duncan.sands@free.fr>
In-Reply-To: <20211021084351.2554-1-caihuoqing@baidu.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Precedence: bulk

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@baidu.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;
>