lkml.org 
[lkml]   [2008]   [Feb]   [7]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    From
    SubjectRe: [PATCH][USBATM]: convert heavy init dances to kthread API
    Date
    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.

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

    \
     
     \ /
      Last update: 2008-02-07 11:01    [W:0.051 / U:335.864 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site