All of lore.kernel.org
 help / color / mirror / Atom feed
From: Oleg Nesterov <oleg@tv-sign.ru>
To: "Eric W. Biederman" <ebiederm@xmission.com>
Cc: Roland McGrath <roland@redhat.com>,
	linux-kernel@vger.kernel.org, Ingo Molnar <mingo@elte.hu>,
	"Paul E. McKenney" <paulmck@us.ibm.com>,
	Andrew Morton <akpm@osdl.org>, Lee Revell <rlrevell@joe-job.com>
Subject: Re: [PATCH rc1-mm 2/3] coredump: shutdown current process first
Date: Fri, 14 Apr 2006 19:33:36 +0400	[thread overview]
Message-ID: <20060414153336.GB131@oleg> (raw)
In-Reply-To: <m1hd4w4m84.fsf@ebiederm.dsl.xmission.com>

On 04/14, Eric W. Biederman wrote:
>
> Oleg Nesterov <oleg@tv-sign.ru> writes:
> 
> > On 04/10, Roland McGrath wrote:
> >>
> >> I would be inclined to restructure the inner loop something like this:
> >> 
> >> 		p = g;
> >> 		while (unlikely(p->mm == NULL)) {
> >> 			p = next_thread(p);
> >> 			if (p == g)
> >> 				break;
> >> 		}
> >> 		if (p->mm == mm) {
> >> 			/*
> >> 			 * p->sighand can't disappear, but
> >> 			 * may be changed by de_thread()
> >> 			 */
> >> 			lock_task_sighand(p, &flags);
> >> 			zap_process(p);
> >> 			unlock_task_sighand(p, &flags);
> >> 		}
> >
> > Yes, I agree, this is much more understandable.
> 
> There is one piece of zap_threads that still makes me uncomfortable.
> 
> task_lock is used to protect p->mm.
> Therefore killing a process based upon p->mm == mm is racy
> with respect to sys_unshare I believe if we don't take
> task_lock.

Well, unshare(CLONE_VM) is not yet supported. Currently (as I see
it) mm->mmap_sem is enough to protect against changing ->mm. Yes,
exit_mm/exec_mmap take task_lock too, so it can be used as well.
Please correct my understanding.

I think it is better to take ->mmap_sem in sys_unshare, this path
is rare.

Oleg.


  reply	other threads:[~2006-04-14 11:36 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-04-09  0:11 [PATCH rc1-mm 2/3] coredump: shutdown current process first Oleg Nesterov
2006-04-10  7:08 ` Roland McGrath
2006-04-10 14:01   ` Oleg Nesterov
2006-04-14  8:04     ` Eric W. Biederman
2006-04-14 15:33       ` Oleg Nesterov [this message]
2006-04-14 17:02         ` Eric W. Biederman
2006-06-09 17:24 ` [PATCH] 2.6.17-rc4 bugfix with initramfs Nickolay
2006-06-10  7:07   ` Sam Ravnborg

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=20060414153336.GB131@oleg \
    --to=oleg@tv-sign.ru \
    --cc=akpm@osdl.org \
    --cc=ebiederm@xmission.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@elte.hu \
    --cc=paulmck@us.ibm.com \
    --cc=rlrevell@joe-job.com \
    --cc=roland@redhat.com \
    /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.