LKML Archive on
help / color / mirror / Atom feed
From: Duncan Sands <>
To: Pavel Emelyanov <>
	Linux Kernel Mailing List <>
Subject: Re: [PATCH][USBATM]: convert heavy init dances to kthread API
Date: Wed, 6 Feb 2008 18:20:53 +0100	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <>


> 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.

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

>  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
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...

Best wishes,


  reply	other threads:[~2008-02-06 17:47 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 [this message]
2008-02-07  9:23   ` Pavel Emelyanov
2008-02-07  9:57     ` Duncan Sands
2008-02-07 10:08       ` Pavel Emelyanov
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:

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

  git send-email \ \ \ \ \ \
    --subject='Re: [PATCH][USBATM]: convert heavy init dances to kthread API' \

* 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).