From: Andrew Morton <akpm@linux-foundation.org>
To: Oleg Nesterov <oleg@redhat.com>
Cc: apw@canonical.com, arjan@linux.intel.com, fhrbata@redhat.com,
john.johansen@canonical.com, penguin-kernel@I-love.SAKURA.ne.jp,
rientjes@google.com, rusty@rustcorp.com.au, tj@kernel.org,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH 1/4] introduce complete_vfork_done()
Date: Thu, 16 Feb 2012 16:35:44 -0800 [thread overview]
Message-ID: <20120216163544.4e41e5a5.akpm@linux-foundation.org> (raw)
In-Reply-To: <20120216172647.GB30393@redhat.com>
On Thu, 16 Feb 2012 18:26:47 +0100
Oleg Nesterov <oleg@redhat.com> wrote:
> No functional changes.
>
> Move the clear-and-complete-vfork_done code into the new trivial
> helper, complete_vfork_done().
>
> ...
>
> --- a/fs/exec.c
> +++ b/fs/exec.c
> @@ -1915,7 +1915,6 @@ static int coredump_wait(int exit_code, struct core_state *core_state)
> {
> struct task_struct *tsk = current;
> struct mm_struct *mm = tsk->mm;
> - struct completion *vfork_done;
> int core_waiters = -EBUSY;
>
> init_completion(&core_state->startup);
> @@ -1934,11 +1933,8 @@ static int coredump_wait(int exit_code, struct core_state *core_state)
> * Make sure nobody is waiting for us to release the VM,
> * otherwise we can deadlock when we wait on each other
> */
> - vfork_done = tsk->vfork_done;
> - if (vfork_done) {
> - tsk->vfork_done = NULL;
> - complete(vfork_done);
> - }
> + if (tsk->vfork_done)
> + complete_vfork_done(tsk);
>
> if (core_waiters)
> wait_for_completion(&core_state->startup);
>
> ...
>
> --- a/kernel/fork.c
> +++ b/kernel/fork.c
> @@ -667,6 +667,14 @@ struct mm_struct *mm_access(struct task_struct *task, unsigned int mode)
> return mm;
> }
>
> +void complete_vfork_done(struct task_struct *tsk)
> +{
> + struct completion *vfork_done = tsk->vfork_done;
> +
> + tsk->vfork_done = NULL;
> + complete(vfork_done);
> +}
> +
> /* Please note the differences between mmput and mm_release.
> * mmput is called whenever we stop holding onto a mm_struct,
> * error success whatever.
> @@ -682,8 +690,6 @@ struct mm_struct *mm_access(struct task_struct *task, unsigned int mode)
> */
> void mm_release(struct task_struct *tsk, struct mm_struct *mm)
> {
> - struct completion *vfork_done = tsk->vfork_done;
> -
> /* Get rid of any futexes when releasing the mm */
> #ifdef CONFIG_FUTEX
> if (unlikely(tsk->robust_list)) {
> @@ -703,11 +709,8 @@ void mm_release(struct task_struct *tsk, struct mm_struct *mm)
> /* Get rid of any cached register state */
> deactivate_mm(tsk, mm);
>
> - /* notify parent sleeping on vfork() */
> - if (vfork_done) {
> - tsk->vfork_done = NULL;
> - complete(vfork_done);
> - }
> + if (tsk->vfork_done)
> + complete_vfork_done(tsk);
This all looks somewhat smelly.
- Why do we zero tsk->vfork_done in this manner? It *looks* like
it's done to prevent the kernel from running complete() twice against
a single task in a race situation. If this is the case then it's
pretty lame, isn't it? We'd need external locking to firm that up
and I'm not seeing it.
- Moving the test for non-null tsk->vfork_done into
complete_vfork_done() would simplify things a bit?
- The complete_vfork_done() interface isn't wonderful. What prevents
tsk from getting freed? Presumably the caller must have pinned it in
some fashion? Or must hold some lock? Or it's always run against
`current', in which case it would be clearer to not pass the
task_struct arg at all?
next prev parent reply other threads:[~2012-02-17 0:35 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-02-14 16:47 [PATCH 0/6] make request_module() killable Oleg Nesterov
2012-02-14 16:47 ` [PATCH 1/6] usermodehelper: introduce umh_complete(sub_info) Oleg Nesterov
2012-02-14 16:48 ` [PATCH 2/6] usermodehelper: implement UMH_KILLABLE Oleg Nesterov
2012-02-14 16:48 ` [PATCH 3/6] usermodehelper: kill umh_wait, renumber UMH_* constants Oleg Nesterov
2012-02-15 1:09 ` Rusty Russell
2012-02-15 18:12 ` Oleg Nesterov
2012-02-14 16:48 ` [PATCH 4/6] usermodehelper: ____call_usermodehelper() doesn't need do_exit() Oleg Nesterov
2012-02-14 16:48 ` [PATCH 5/6] kmod: introduce call_modprobe() helper Oleg Nesterov
2012-02-14 16:49 ` [PATCH 6/6] kmod: make __request_module() killable Oleg Nesterov
2012-02-15 20:30 ` Andrew Morton
2012-02-16 15:04 ` Oleg Nesterov
2012-02-16 17:26 ` [PATCH 0/4] make vfork() killable Oleg Nesterov
2012-02-16 17:26 ` [PATCH 1/4] introduce complete_vfork_done() Oleg Nesterov
2012-02-17 0:35 ` Andrew Morton [this message]
2012-02-17 14:37 ` Oleg Nesterov
2012-02-16 17:27 ` [PATCH 2/4] vfork: make it killable Oleg Nesterov
2012-02-17 0:39 ` Andrew Morton
2012-02-17 14:44 ` Oleg Nesterov
2012-02-16 17:27 ` [PATCH 3/4] coredump_wait: don't call complete_vfork_done() Oleg Nesterov
2012-02-16 17:27 ` [PATCH 4/4] kill PF_STARTING Oleg Nesterov
2012-02-17 0:26 ` [PATCH 0/4] make vfork() killable Andrew Morton
2012-02-17 2:45 ` Stephen Rothwell
2012-02-17 14:46 ` Oleg Nesterov
[not found] ` <20120216173233.GF30393@redhat.com>
[not found] ` <201202172211.CGH81726.OStOJFLFHQVMFO@I-love.SAKURA.ne.jp>
[not found] ` <20120217150726.GD22440@redhat.com>
2012-02-17 18:00 ` [PATCH 0/1] hung_task: fix the broken rcu_lock_break() logic Oleg Nesterov
2012-02-17 18:00 ` [PATCH 1/1] " 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=20120216163544.4e41e5a5.akpm@linux-foundation.org \
--to=akpm@linux-foundation.org \
--cc=apw@canonical.com \
--cc=arjan@linux.intel.com \
--cc=fhrbata@redhat.com \
--cc=john.johansen@canonical.com \
--cc=linux-kernel@vger.kernel.org \
--cc=oleg@redhat.com \
--cc=penguin-kernel@I-love.SAKURA.ne.jp \
--cc=rientjes@google.com \
--cc=rusty@rustcorp.com.au \
--cc=tj@kernel.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;
as well as URLs for NNTP newsgroup(s).