[lkml]   [2009]   [Jan]   [31]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [PATCH 3/4] kthreads: rework kthread_stop()
    On Friday 30 January 2009 23:20:58 Oleg Nesterov wrote:
    > On 01/30, Oleg Nesterov wrote:
    > >
    > > With this patch kthread() allocates all neccesary data (struct kthread)
    > > on its own stack, globals kthread_stop_xxx are deleted. ->vfork_done
    > > is used as a pointer into "struct kthread", this means kthread_stop()
    > > can easily wait for kthread's exit.
    > To simplify the review, please see the code with the patch applied.

    Hmm, I thought about using the parent-child relationship and fairly normal
    wait() semantics, but this looks simpler.

    > struct kthread {
    > int should_stop;
    > struct completion exited;
    > };

    Mildly prefer bool in new code.

    > #define to_kthread(tsk) \
    > container_of((tsk)->vfork_done, struct kthread, exited)

    This needs a comment. Especially since to_xxx(yyy) is usually simply a
    container_of(yyy, xxx, member). This one is special.

    > int kthread_stop(struct task_struct *k)
    > {
    > struct kthread *kthread;
    > int ret;
    > trace_sched_kthread_stop(k);
    > get_task_struct(k);
    > kthread = to_kthread(k);
    > barrier(); /* it might have exited */
    > if (k->vfork_done != NULL) {
    > kthread->should_stop = 1;
    > wake_up_process(k);
    > wait_for_completion(&kthread->exited);
    > }
    > ret = k->exit_code;

    I don't think this works. How does do_exit() preserve a stack var, other
    than for a few cycles longer? Sure, the vfork_done will be OK, but this code
    here will not be. I think you'd need a get_task_struct(current) before the
    do_exit(ret) (the case where the kthread fn calls do_exit() is fine: you're
    not allowed to call kthread stop on such threads).

    In which case using vfork_done is really just a convenience pointer inside
    struct task_struct to stash the struct kthread. And that's horribly ugly, which is why I stuck with a simple global. Changing to a linked-list of things to stop would avoid the deadlock you mentioned where a kthread stops another kthread.


     \ /
      Last update: 2009-01-31 13:19    [W:0.023 / U:148.412 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site