All of lore.kernel.org
 help / color / mirror / Atom feed
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?


  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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.