From: Oleg Nesterov <oleg@redhat.com>
To: "Eric W. Biederman" <ebiederm@xmission.com>
Cc: Rusty Russell <rusty@rustcorp.com.au>,
Andrew Morton <akpm@linux-foundation.org>,
Christoph Hellwig <hch@lst.de>, 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: Mon, 2 Feb 2009 20:41:05 +0100 [thread overview]
Message-ID: <20090202194105.GA23141@redhat.com> (raw)
In-Reply-To: <m1wsc82033.fsf@fess.ebiederm.org>
On 02/02, Eric W. Biederman wrote:
>
> Oleg on that note we should not need a barrier at all. We should be
> able to simply say:
>
> cmplp = k->vfork_done;
> if (cmplp){
> /* if vfork_done is NULL we have passed mm_release */
> kthread = container_of(cmplp, struct kthread, exited);
> kthread->should_stop = 1;
> wake_up_process(k);
> wait_for_completion(&kthread->exited);
> }
Yes, but the compiler can read ->vfork_done twice, and turn this code
into
cmplp = k->vfork_done;
if (cmplp){
kthread = container_of(k->vfork_done, struct kthread, exited);
...
and when we read k->vfork_done again it can be already NULL.
Probably we could use ACCESS_ONCE() instead.
Perhaps this barrier() is not needed in practice, but just to be safe.
And in fact I saw the bug report with this code:
ac.ac_tty = current->signal->tty ?
old_encode_dev(tty_devnum(current->signal->tty)) : 0;
this code is wrong anyway, but ->tty was read twice. I specially
asked for .s file because I wasn't able to believe the bug manifests
itself this way.
> Thinking of it I wish we had someplace we could store a pointer
> that would not be cleared so we could remove that whole confusing
> conditional. I just looked through task_struct and there doesn't
> appear to be anything promising.
>
> Perhaps we could rename vfork_done mm_done and not clear it in
> mm_release.
Yes, in that case we don't need the barrier().
I was thinking about changing mm_release() too, but we should clear
->vfork_done (or whatever) in exec_mmap() anyway.
Oleg.
next prev parent reply other threads:[~2009-02-02 19:44 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
2009-02-01 10:21 ` Oleg Nesterov
2009-02-02 17:57 ` Eric W. Biederman
2009-02-02 19:41 ` Oleg Nesterov [this message]
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=20090202194105.GA23141@redhat.com \
--to=oleg@redhat.com \
--cc=akpm@linux-foundation.org \
--cc=ebiederm@xmission.com \
--cc=hch@lst.de \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@elte.hu \
--cc=rusty@rustcorp.com.au \
--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