Repalce kthread_create/wake_up_process() with kthread_run()
to simplify the code.
Signed-off-by: Cai Huoqing <[email protected]>
---
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);
wait_for_completion(&instance->thread_started);
return 0;
--
2.25.1
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 <[email protected]>
> ---
> 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;
>