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.
> @@ -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,
Duncan.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
