LKML Archive on lore.kernel.org
help / color / mirror / Atom feed
From: Pavel Emelyanov <xemul@openvz.org>
To: Duncan Sands <baldrick.bulk@free.fr>
Cc: linux-usb@vger.kernel.org,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH][USBATM]: convert heavy init dances to kthread API
Date: Thu, 07 Feb 2008 13:08:06 +0300	[thread overview]
Message-ID: <47AAD886.2000606@openvz.org> (raw)
In-Reply-To: <200802071057.41201.baldrick.bulk@free.fr>

Duncan Sands wrote:
> Hi Pavel,
> 
>>>> @@ -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.
> 
> I don't see why it helps.  The race I mentioned occurs when the kthread creating thread
> runs too fast compared to the kthread.  Let C (creator) be the thread running
> usbatm_heavy_init, and K (kthread) be the created kthread.  When C calls wake_up_process,
> thread K starts running, however on an SMP system C may also be running.  Now suppose
> that for some reason K takes a long time to execute the command "allow_signal(SIGTERM);",
> but that C runs very fast and immediately executes the disconnect callback, and sends the
> signal to K before K manages to execute allow_signal.  This is the race, and it can only
> be fixed by making C run slower (thus the completion).  Of course this is fantastically
> unlikely which is why I described it as tiny, but as far as I can see it is a theoretical
> possibility.  I don't see that wake_up_process fixes it, it just makes it even less likely.

Oh, I see. You're right - this race is possible... I'll fix that up
if this patch works.

>>> 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.
> 
> I think your patch should go in, since I'm not likely to ever implement the
> scheme I suggested - I don't use this hardware anymore and have lost interest
> in the driver.

:)

> Best wishes,
> 
> Duncan.
> 
> 


  reply	other threads:[~2008-02-07 10:15 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-02-06 16:15 Pavel Emelyanov
2008-02-06 17:20 ` Duncan Sands
2008-02-07  9:23   ` Pavel Emelyanov
2008-02-07  9:57     ` Duncan Sands
2008-02-07 10:08       ` Pavel Emelyanov [this message]
2008-02-10 20:30         ` Duncan Sands
2008-02-11 11:22           ` Pavel Emelyanov
2008-02-11 11:51             ` Duncan Sands
2008-02-07 16:18     ` Alan Stern
2008-02-07 16:37       ` Pavel Emelyanov
2008-02-11 12:26 [PATCH] Usbatm: " Pavel Emelyanov
2008-02-11 12:39 ` Duncan Sands

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=47AAD886.2000606@openvz.org \
    --to=xemul@openvz.org \
    --cc=baldrick.bulk@free.fr \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-usb@vger.kernel.org \
    --subject='Re: [PATCH][USBATM]: convert heavy init dances to kthread API' \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).