From: Nick Piggin <nickpiggin@yahoo.com.au>
To: Andrew Morton <akpm@osdl.org>
Cc: bstroesser@fujitsu-siemens.com, roland@redhat.com,
jdike@addtoit.com, blaisorblade_spam@yahoo.it,
user-mode-linux-devel@lists.sourceforge.net,
linux-kernel@vger.kernel.org
Subject: [uml-devel] Re: Race condition in ptrace
Date: Sat, 05 Feb 2005 15:35:35 +1100 [thread overview]
Message-ID: <42044D17.5040703@yahoo.com.au> (raw)
In-Reply-To: <4204020F.2000501@yahoo.com.au>
[-- Attachment #1: Type: text/plain, Size: 801 bytes --]
Nick Piggin wrote:
> Andrew Morton wrote:
>
>> Nick Piggin <nickpiggin@yahoo.com.au> wrote:
>>
>>> Andrew, IMO this is another bug to hold 2.6.11 for.
>>
>>
>>
>> Sure. I wouldn't consider Bodo's patch to be the one to use though..
>
>
> No. Something similar could be done that works on all architectures
> and all wait_task_inactive callers (and is confined to sched.c). That
> would still be more or less a hack to work around smtnice's unfortunate
> locking though.
>
Something like the following (untested) extension of Bodo's work
could be the minimal fix for 2.6.11. As I've said though, I'd
consider it a hack and prefer to do something about the locking.
That could be done after 2.6.11 though. Depends how you feel.
Bodo, I wonder if this looks like a suitable fix for your problem?
[-- Attachment #2: sched-fixup-locking.patch --]
[-- Type: text/plain, Size: 2795 bytes --]
---
linux-2.6-npiggin/include/linux/init_task.h | 1 +
linux-2.6-npiggin/include/linux/sched.h | 1 +
linux-2.6-npiggin/kernel/sched.c | 12 ++++++++++--
3 files changed, 12 insertions(+), 2 deletions(-)
diff -puN include/linux/sched.h~sched-fixup-locking include/linux/sched.h
--- linux-2.6/include/linux/sched.h~sched-fixup-locking 2005-02-05 15:24:00.000000000 +1100
+++ linux-2.6-npiggin/include/linux/sched.h 2005-02-05 15:24:39.000000000 +1100
@@ -533,6 +533,7 @@ struct task_struct {
unsigned long ptrace;
int lock_depth; /* Lock depth */
+ int on_cpu; /* Is the task on the CPU, or in a ctxsw */
int prio, static_prio;
struct list_head run_list;
diff -puN kernel/sched.c~sched-fixup-locking kernel/sched.c
--- linux-2.6/kernel/sched.c~sched-fixup-locking 2005-02-05 15:24:02.000000000 +1100
+++ linux-2.6-npiggin/kernel/sched.c 2005-02-05 15:34:37.000000000 +1100
@@ -294,7 +294,7 @@ static DEFINE_PER_CPU(struct runqueue, r
#ifndef prepare_arch_switch
# define prepare_arch_switch(rq, next) do { } while (0)
# define finish_arch_switch(rq, next) spin_unlock_irq(&(rq)->lock)
-# define task_running(rq, p) ((rq)->curr == (p))
+# define task_running(rq, p) ((p)->on_cpu)
#endif
/*
@@ -867,7 +867,7 @@ void wait_task_inactive(task_t * p)
repeat:
rq = task_rq_lock(p, &flags);
/* Must be off runqueue entirely, not preempted. */
- if (unlikely(p->array)) {
+ if (unlikely(p->array || p->on_cpu)) {
/* If it's preempted, we yield. It could be a while. */
preempted = !task_running(rq, p);
task_rq_unlock(rq, &flags);
@@ -2805,11 +2805,18 @@ switch_tasks:
rq->curr = next;
++*switch_count;
+ next->on_cpu = 1;
prepare_arch_switch(rq, next);
prev = context_switch(rq, prev, next);
barrier();
finish_task_switch(prev);
+ /*
+ * Some architectures release the runqueue lock before
+ * context switching. Make sure this isn't reordered.
+ */
+ smp_wmb();
+ prev->on_cpu = 0;
} else
spin_unlock_irq(&rq->lock);
@@ -4055,6 +4062,7 @@ void __devinit init_idle(task_t *idle, i
set_task_cpu(idle, cpu);
spin_lock_irqsave(&rq->lock, flags);
+ idle->on_cpu = 1;
rq->curr = rq->idle = idle;
set_tsk_need_resched(idle);
spin_unlock_irqrestore(&rq->lock, flags);
diff -puN include/linux/init_task.h~sched-fixup-locking include/linux/init_task.h
--- linux-2.6/include/linux/init_task.h~sched-fixup-locking 2005-02-05 15:24:56.000000000 +1100
+++ linux-2.6-npiggin/include/linux/init_task.h 2005-02-05 15:25:07.000000000 +1100
@@ -73,6 +73,7 @@ extern struct group_info init_groups;
.usage = ATOMIC_INIT(2), \
.flags = 0, \
.lock_depth = -1, \
+ .on_cpu = 0, \
.prio = MAX_PRIO-20, \
.static_prio = MAX_PRIO-20, \
.policy = SCHED_NORMAL, \
_
WARNING: multiple messages have this Message-ID (diff)
From: Nick Piggin <nickpiggin@yahoo.com.au>
To: Andrew Morton <akpm@osdl.org>
Cc: bstroesser@fujitsu-siemens.com, roland@redhat.com,
jdike@addtoit.com, blaisorblade_spam@yahoo.it,
user-mode-linux-devel@lists.sourceforge.net,
linux-kernel@vger.kernel.org
Subject: Re: Race condition in ptrace
Date: Sat, 05 Feb 2005 15:35:35 +1100 [thread overview]
Message-ID: <42044D17.5040703@yahoo.com.au> (raw)
In-Reply-To: <4204020F.2000501@yahoo.com.au>
[-- Attachment #1: Type: text/plain, Size: 801 bytes --]
Nick Piggin wrote:
> Andrew Morton wrote:
>
>> Nick Piggin <nickpiggin@yahoo.com.au> wrote:
>>
>>> Andrew, IMO this is another bug to hold 2.6.11 for.
>>
>>
>>
>> Sure. I wouldn't consider Bodo's patch to be the one to use though..
>
>
> No. Something similar could be done that works on all architectures
> and all wait_task_inactive callers (and is confined to sched.c). That
> would still be more or less a hack to work around smtnice's unfortunate
> locking though.
>
Something like the following (untested) extension of Bodo's work
could be the minimal fix for 2.6.11. As I've said though, I'd
consider it a hack and prefer to do something about the locking.
That could be done after 2.6.11 though. Depends how you feel.
Bodo, I wonder if this looks like a suitable fix for your problem?
[-- Attachment #2: sched-fixup-locking.patch --]
[-- Type: text/plain, Size: 2795 bytes --]
---
linux-2.6-npiggin/include/linux/init_task.h | 1 +
linux-2.6-npiggin/include/linux/sched.h | 1 +
linux-2.6-npiggin/kernel/sched.c | 12 ++++++++++--
3 files changed, 12 insertions(+), 2 deletions(-)
diff -puN include/linux/sched.h~sched-fixup-locking include/linux/sched.h
--- linux-2.6/include/linux/sched.h~sched-fixup-locking 2005-02-05 15:24:00.000000000 +1100
+++ linux-2.6-npiggin/include/linux/sched.h 2005-02-05 15:24:39.000000000 +1100
@@ -533,6 +533,7 @@ struct task_struct {
unsigned long ptrace;
int lock_depth; /* Lock depth */
+ int on_cpu; /* Is the task on the CPU, or in a ctxsw */
int prio, static_prio;
struct list_head run_list;
diff -puN kernel/sched.c~sched-fixup-locking kernel/sched.c
--- linux-2.6/kernel/sched.c~sched-fixup-locking 2005-02-05 15:24:02.000000000 +1100
+++ linux-2.6-npiggin/kernel/sched.c 2005-02-05 15:34:37.000000000 +1100
@@ -294,7 +294,7 @@ static DEFINE_PER_CPU(struct runqueue, r
#ifndef prepare_arch_switch
# define prepare_arch_switch(rq, next) do { } while (0)
# define finish_arch_switch(rq, next) spin_unlock_irq(&(rq)->lock)
-# define task_running(rq, p) ((rq)->curr == (p))
+# define task_running(rq, p) ((p)->on_cpu)
#endif
/*
@@ -867,7 +867,7 @@ void wait_task_inactive(task_t * p)
repeat:
rq = task_rq_lock(p, &flags);
/* Must be off runqueue entirely, not preempted. */
- if (unlikely(p->array)) {
+ if (unlikely(p->array || p->on_cpu)) {
/* If it's preempted, we yield. It could be a while. */
preempted = !task_running(rq, p);
task_rq_unlock(rq, &flags);
@@ -2805,11 +2805,18 @@ switch_tasks:
rq->curr = next;
++*switch_count;
+ next->on_cpu = 1;
prepare_arch_switch(rq, next);
prev = context_switch(rq, prev, next);
barrier();
finish_task_switch(prev);
+ /*
+ * Some architectures release the runqueue lock before
+ * context switching. Make sure this isn't reordered.
+ */
+ smp_wmb();
+ prev->on_cpu = 0;
} else
spin_unlock_irq(&rq->lock);
@@ -4055,6 +4062,7 @@ void __devinit init_idle(task_t *idle, i
set_task_cpu(idle, cpu);
spin_lock_irqsave(&rq->lock, flags);
+ idle->on_cpu = 1;
rq->curr = rq->idle = idle;
set_tsk_need_resched(idle);
spin_unlock_irqrestore(&rq->lock, flags);
diff -puN include/linux/init_task.h~sched-fixup-locking include/linux/init_task.h
--- linux-2.6/include/linux/init_task.h~sched-fixup-locking 2005-02-05 15:24:56.000000000 +1100
+++ linux-2.6-npiggin/include/linux/init_task.h 2005-02-05 15:25:07.000000000 +1100
@@ -73,6 +73,7 @@ extern struct group_info init_groups;
.usage = ATOMIC_INIT(2), \
.flags = 0, \
.lock_depth = -1, \
+ .on_cpu = 0, \
.prio = MAX_PRIO-20, \
.static_prio = MAX_PRIO-20, \
.policy = SCHED_NORMAL, \
_
next prev parent reply other threads:[~2005-02-05 4:35 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-02-03 12:51 [uml-devel] Race condition in ptrace Bodo Stroesser
2005-02-03 12:51 ` Bodo Stroesser
2005-02-04 0:27 ` [uml-devel] " Nick Piggin
2005-02-04 0:27 ` Nick Piggin
2005-02-04 12:35 ` [uml-devel] " Bodo Stroesser
2005-02-04 12:35 ` Bodo Stroesser
2005-02-04 22:15 ` [uml-devel] " Nick Piggin
2005-02-04 22:15 ` Nick Piggin
2005-02-04 22:39 ` [uml-devel] " Andrew Morton
2005-02-04 22:39 ` Andrew Morton
2005-02-04 23:15 ` [uml-devel] " Nick Piggin
2005-02-04 23:15 ` Nick Piggin
2005-02-05 4:35 ` Nick Piggin [this message]
2005-02-05 4:35 ` Nick Piggin
2005-02-06 3:26 ` [uml-devel] [PATCH] fix wait_task_inactive race (was Re: Race condition in ptrace) Nick Piggin
2005-02-06 3:26 ` Nick Piggin
2005-02-06 7:19 ` [uml-devel] " Ingo Molnar
2005-02-06 7:19 ` Ingo Molnar
2005-02-06 7:36 ` [uml-devel] " Nick Piggin
2005-02-06 7:36 ` Nick Piggin
2005-02-06 7:47 ` [uml-devel] " Nick Piggin
2005-02-06 7:47 ` Nick Piggin
2005-02-14 16:07 ` [uml-devel] " Bodo Stroesser
2005-02-14 16:07 ` Bodo Stroesser
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=42044D17.5040703@yahoo.com.au \
--to=nickpiggin@yahoo.com.au \
--cc=akpm@osdl.org \
--cc=blaisorblade_spam@yahoo.it \
--cc=bstroesser@fujitsu-siemens.com \
--cc=jdike@addtoit.com \
--cc=linux-kernel@vger.kernel.org \
--cc=roland@redhat.com \
--cc=user-mode-linux-devel@lists.sourceforge.net \
/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.