Hi Yin Xiujiang, please see my earlier reply to Cai Huoqing for the same patch
below. Did you do the analysis?
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.
On 27/01/2022 08:47, Yin Xiujiang wrote:
Repalce kthread_create/wake_up_process() with kthread_run()
to simplify the code.
Signed-off-by: Yin Xiujiang <yinxiujiang@xxxxxxxxxx>
---
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 e3a49d837609..24ba739a85e0 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;
