lkml.org 
[lkml]   [2008]   [Feb]   [7]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH][USBATM]: convert heavy init dances to kthread API
Duncan Sands wrote:
> Hi,
>
>> The problem is that I couldn't find the maintainer for the code
>> in drivers/usb/atm/.
>
> that would be me (though since I haven't used this modem in years I would
> be more than happy to hand it off to someone else).
>
>> Besides, I don't have a proper hardware to test this.
>
> I will try to find where I put my old modem and test your patch this weekend.

Oh, that would be great :)

>> @@ -1014,11 +1015,7 @@ static int usbatm_do_heavy_init(void *arg)
>> struct usbatm_data *instance = arg;
>> int ret;
>>
>> - daemonize(instance->driver->driver_name);
>> allow_signal(SIGTERM);
>> - instance->thread_pid = current->pid;
>> -
>> - complete(&instance->thread_started);
>
> One reason the completion existed to make sure that the thread was not
> sent SIGTERM before the above call to allow_signal(SIGTERM). So I think
> you have opened up a (tiny) race by deleting it.

Nope. See my answer below :)

>> static int usbatm_heavy_init(struct usbatm_data *instance)
>> {
>> - int ret = kernel_thread(usbatm_do_heavy_init, instance, CLONE_FS | CLONE_FILES);
>> -
>> - if (ret < 0) {
>> - usb_err(instance, "%s: failed to create kernel_thread (%d)!\n", __func__, ret);
>
> Please don't delete this message.
>
>> - return ret;
>> - }
>> + struct task_struct *t;
>>
>> - wait_for_completion(&instance->thread_started);
>> + t = kthread_create(usbatm_do_heavy_init, instance,
>> + instance->driver->driver_name);
>> + if (IS_ERR(t))
>> + return PTR_ERR(t);
>>
>> + instance->thread = t;
>> + wake_up_process(t);
>
> Does the kthread API guarantee that the kthread is not running until you call

It does. That's why the race, you mentioned above is impossible.

> wake_up_process? Because if not then what is to stop the kthread finishing before
> this thread does "instance->thread = t", resulting in an attempt to send a signal
> to a dead process later on in disconnect?
>
> Otherwise it looks fine - thanks!
>
> By the way, the right thing to do is (I think) to replace the thread with a workqueue
> and have users of usbatm register a "shut_down" callback rather than using signals: the
> disconnect method would call shut_down rathering than trying to kill the thread. That
> way all this mucking around with pids etc wouldn't be needed. All users of usbatm would
> need to be modified. I managed to convince myself once that they could all be fixed up
> in a fairly simple manner thanks to a few tricks and a completion or two, but I don't
> recall the details...

Well, that would be also great, since kill_proc will be gone - that's what
I'm trying to achieve.

> Best wishes,
>
> Duncan.
>

Thanks,
Pavel


\
 
 \ /
  Last update: 2008-02-07 10:31    [W:0.052 / U:2.200 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site