public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Rusty Russell <rusty@rustcorp.com.au>
To: Oleg Nesterov <oleg@redhat.com>
Cc: Andrew Morton <akpm@linux-foundation.org>,
	Christoph Hellwig <hch@lst.de>,
	"Eric W. Biederman" <ebiederm@xmission.com>,
	Ingo Molnar <mingo@elte.hu>, Pavel Emelyanov <xemul@openvz.org>,
	Vitaliy Gusev <vgusev@openvz.org>,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH 3/4] kthreads: rework kthread_stop()
Date: Sat, 31 Jan 2009 22:46:07 +1030	[thread overview]
Message-ID: <200901312246.07737.rusty@rustcorp.com.au> (raw)
In-Reply-To: <20090130125058.GA26931@redhat.com>

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.

Thanks,
Rusty.

  reply	other threads:[~2009-01-31 12:16 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-01-30 12:33 [PATCH 3/4] kthreads: rework kthread_stop() Oleg Nesterov
2009-01-30 12:50 ` Oleg Nesterov
2009-01-31 12:16   ` Rusty Russell [this message]
2009-02-01 10:21     ` Oleg Nesterov
2009-02-02 17:57       ` Eric W. Biederman
2009-02-02 19:41         ` Oleg Nesterov
2009-02-03  3:25           ` Eric W. Biederman
2009-02-03 13:41             ` Paul E. McKenney
2009-02-04  5:10               ` Eric W. Biederman
2009-02-04 11:04                 ` Rusty Russell
2009-02-04 15:59                   ` Eric W. Biederman
2009-02-05  1:03                     ` Rusty Russell
2009-02-04 20:46                   ` Jon Masters
2009-01-30 21:47 ` Andrew Morton
2009-02-01 10:49   ` Oleg Nesterov

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=200901312246.07737.rusty@rustcorp.com.au \
    --to=rusty@rustcorp.com.au \
    --cc=akpm@linux-foundation.org \
    --cc=ebiederm@xmission.com \
    --cc=hch@lst.de \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@elte.hu \
    --cc=oleg@redhat.com \
    --cc=vgusev@openvz.org \
    --cc=xemul@openvz.org \
    /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
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox