public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Andrea Arcangeli <andrea@suse.de>
To: David Mosberger <davidm@hpl.hp.com>
Cc: linux-kernel@vger.kernel.org
Subject: Re: [patch] proposed fix for ptrace() SMP race
Date: Fri, 7 Sep 2001 03:28:01 +0200	[thread overview]
Message-ID: <20010907032801.N11329@athlon.random> (raw)
In-Reply-To: <200109062300.QAA27430@napali.hpl.hp.com> <20010907021900.L11329@athlon.random> <15256.6038.599811.557582@napali.hpl.hp.com>
In-Reply-To: <15256.6038.599811.557582@napali.hpl.hp.com>; from davidm@hpl.hp.com on Thu, Sep 06, 2001 at 05:40:54PM -0700

On Thu, Sep 06, 2001 at 05:40:54PM -0700, David Mosberger wrote:
>   Andrea> abusing cpus_allowed to forbid scheduling is racy so quite
>   Andrea> unacceptable, we want to preserve the cpus_allowed field for
>   Andrea> the administrator (he could as well set it during the
>   Andrea> ptrace).
> 
> As long as the CPU manipulates cpus_allowed in an atomic fashion (xchg
> or cmpxchg) this will be fine.  I'd argue it has to do this anyhow
> (unless a task is changing its own cpus_allowed field).

atomic updates of cpus_allowed it's not the point I was making, it's
still racy:

	ptrace				admin via /proc
	--------------			---------------
	save and clear
					set cpus_allowed to something
	restore cpus_allowed <destroy modification>

the modification of the user is been destroyed if he sets cpus_allowed
inside ptrace, this is the race condition I was thinking about.
	
> If you don't like the cpus_allowed approach, please propose another
> solution that ensures that the task does not get woken up while ptrace

For making sure the task isn't wakenup while it's under ptrace we should
just do that in kernel/signal.c::ignored_signal() as far I can tell.

To ensure the task just sleeps I suggest the one I mentioned in the
previous email. here a patch (possibly breaks PTRACE_KILL, I didn't
backed out the PTRACE_KILL change yet):

--- 2.4.10pre4aa1/arch/i386/kernel/ptrace.c.~1~	Sat Jul 21 00:04:05 2001
+++ 2.4.10pre4aa1/arch/i386/kernel/ptrace.c	Fri Sep  7 03:19:53 2001
@@ -171,12 +171,15 @@
 	ret = -ESRCH;
 	if (!(child->ptrace & PT_PTRACED))
 		goto out_tsk;
-	if (child->state != TASK_STOPPED) {
-		if (request != PTRACE_KILL)
-			goto out_tsk;
-	}
+	if (child->state != TASK_STOPPED && child->state != TASK_ZOMBIE)
+		goto out_tsk;
 	if (child->p_pptr != current)
 		goto out_tsk;
+#ifdef CONFIG_SMP
+	rmb(); /* read child->has_cpu after child->state */
+	while (child->has_cpu);
+	mb(); /* allowed to work on the task only when the task is been descheduled */
+#endif
 	switch (request) {
 	/* when I and D space are separate, these will need to be fixed. */
 	case PTRACE_PEEKTEXT: /* read word at location addr. */ 


Andrea


  reply	other threads:[~2001-09-07  1:27 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2001-09-06 23:00 [patch] proposed fix for ptrace() SMP race David Mosberger
2001-09-07  0:19 ` Andrea Arcangeli
2001-09-07  0:40   ` David Mosberger
2001-09-07  1:28     ` Andrea Arcangeli [this message]
2001-09-07  1:41       ` Alan Cox
2001-09-07 13:34         ` Andrea Arcangeli
2001-09-07  5:21       ` David Mosberger
2001-09-07 13:28         ` Andrea Arcangeli
2001-09-07 15:35           ` David Mosberger
2001-09-08 17:11             ` Andrea Arcangeli
2001-09-10 17:20               ` David Mosberger
  -- strict thread matches above, loose matches on Subject: below --
2001-09-10 17:54 Manfred Spraul

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=20010907032801.N11329@athlon.random \
    --to=andrea@suse.de \
    --cc=davidm@hpl.hp.com \
    --cc=linux-kernel@vger.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