On 11/14/2014 09:38 PM, Sasha Levin wrote:
> On 11/10/2014 11:03 AM, Peter Zijlstra wrote:
>> > On Fri, Nov 07, 2014 at 10:48:27PM -0500, Sasha Levin wrote:
>> > [ 829.539183] BUG: spinlock recursion on CPU#10, trinity-c594/11067
>> > [ 829.539203] lock: 0x880631dd6b80, .magic:
On 11/14/2014 09:38 PM, Sasha Levin wrote:
On 11/10/2014 11:03 AM, Peter Zijlstra wrote:
On Fri, Nov 07, 2014 at 10:48:27PM -0500, Sasha Levin wrote:
[ 829.539183] BUG: spinlock recursion on CPU#10, trinity-c594/11067
[ 829.539203] lock: 0x880631dd6b80, .magic: dead4ead, .owner:
On 11/10/2014 11:03 AM, Peter Zijlstra wrote:
> On Fri, Nov 07, 2014 at 10:48:27PM -0500, Sasha Levin wrote:
>> > [ 829.539183] BUG: spinlock recursion on CPU#10, trinity-c594/11067
>> > [ 829.539203] lock: 0x880631dd6b80, .magic: dead4ead, .owner:
>> > trinity-c594/11067, .owner_cpu: 13
>
On 11/10/2014 11:03 AM, Peter Zijlstra wrote:
On Fri, Nov 07, 2014 at 10:48:27PM -0500, Sasha Levin wrote:
[ 829.539183] BUG: spinlock recursion on CPU#10, trinity-c594/11067
[ 829.539203] lock: 0x880631dd6b80, .magic: dead4ead, .owner:
trinity-c594/11067, .owner_cpu: 13
Ooh, look
В Пн, 10/11/2014 в 23:01 +0300, Kirill Tkhai пишет:
>
> 10.11.2014, 19:45, "Sasha Levin" :
> > On 11/10/2014 11:36 AM, Kirill Tkhai wrote:
> >> I mean task_numa_find_cpu(). If a garbage is in
> >> cpumask_of_node(env->dst_nid)
> >> and cpu is bigger than mask, the check
> >>
> >>
В Пн, 10/11/2014 в 23:01 +0300, Kirill Tkhai пишет:
10.11.2014, 19:45, Sasha Levin sasha.le...@oracle.com:
On 11/10/2014 11:36 AM, Kirill Tkhai wrote:
I mean task_numa_find_cpu(). If a garbage is in
cpumask_of_node(env-dst_nid)
and cpu is bigger than mask, the check
10.11.2014, 19:45, "Sasha Levin" :
> On 11/10/2014 11:36 AM, Kirill Tkhai wrote:
>> I mean task_numa_find_cpu(). If a garbage is in
>> cpumask_of_node(env->dst_nid)
>> and cpu is bigger than mask, the check
>>
>> cpumask_test_cpu(cpu, tsk_cpus_allowed(env->p)
>>
>> may be true.
>>
>> So,
On 11/10/2014 11:36 AM, Kirill Tkhai wrote:
> I mean task_numa_find_cpu(). If a garbage is in cpumask_of_node(env->dst_nid)
> and cpu is bigger than mask, the check
>
> cpumask_test_cpu(cpu, tsk_cpus_allowed(env->p)
>
> may be true.
>
> So, we dereference wrong rq in task_numa_compare(). It's
В Пн, 10/11/2014 в 19:10 +0300, Kirill Tkhai пишет:
> В Пн, 10/11/2014 в 17:03 +0100, Peter Zijlstra пишет:
> > On Fri, Nov 07, 2014 at 10:48:27PM -0500, Sasha Levin wrote:
> > > [ 829.539183] BUG: spinlock recursion on CPU#10, trinity-c594/11067
> > > [ 829.539203] lock: 0x880631dd6b80,
On Mon, Nov 10, 2014 at 11:09:29AM -0500, Sasha Levin wrote:
> On 11/10/2014 11:03 AM, Peter Zijlstra wrote:
> > On Fri, Nov 07, 2014 at 10:48:27PM -0500, Sasha Levin wrote:
> >> [ 829.539183] BUG: spinlock recursion on CPU#10, trinity-c594/11067
> >> [ 829.539203] lock: 0x880631dd6b80,
В Пн, 10/11/2014 в 17:03 +0100, Peter Zijlstra пишет:
> On Fri, Nov 07, 2014 at 10:48:27PM -0500, Sasha Levin wrote:
> > [ 829.539183] BUG: spinlock recursion on CPU#10, trinity-c594/11067
> > [ 829.539203] lock: 0x880631dd6b80, .magic: dead4ead, .owner:
> > trinity-c594/11067, .owner_cpu:
On 11/10/2014 11:03 AM, Peter Zijlstra wrote:
> On Fri, Nov 07, 2014 at 10:48:27PM -0500, Sasha Levin wrote:
>> [ 829.539183] BUG: spinlock recursion on CPU#10, trinity-c594/11067
>> [ 829.539203] lock: 0x880631dd6b80, .magic: dead4ead, .owner:
>> trinity-c594/11067, .owner_cpu: 13
>
>
On Fri, Nov 07, 2014 at 10:48:27PM -0500, Sasha Levin wrote:
> [ 829.539183] BUG: spinlock recursion on CPU#10, trinity-c594/11067
> [ 829.539203] lock: 0x880631dd6b80, .magic: dead4ead, .owner:
> trinity-c594/11067, .owner_cpu: 13
Ooh, look at that. CPU#10 vs .owner_cpu: 13 on the _same_
On Mon, Nov 10, 2014 at 10:48:28AM -0500, Sasha Levin wrote:
> On 11/10/2014 05:03 AM, Peter Zijlstra wrote:
> > --- a/kernel/sched/fair.c
> > +++ b/kernel/sched/fair.c
> > @@ -1268,6 +1268,13 @@ static void task_numa_compare(struct tas
> > raw_spin_unlock_irq(_rq->lock);
> >
> > /*
> >
On 11/10/2014 05:03 AM, Peter Zijlstra wrote:
> --- a/kernel/sched/fair.c
> +++ b/kernel/sched/fair.c
> @@ -1268,6 +1268,13 @@ static void task_numa_compare(struct tas
> raw_spin_unlock_irq(_rq->lock);
>
> /*
> + * Because we have preemption enabled we can get migrated around
On Sun, Nov 09, 2014 at 05:07:00PM +0300, Kirill Tkhai wrote:
> > I've complained about an unrelated issue in that part of the code
> > a while back (https://lkml.org/lkml/2014/5/12/508) which PeterZ
> > ended up fixing (https://lkml.org/lkml/2014/5/21/428) but it seems
> > that both of us forgot
On Sun, Nov 09, 2014 at 05:07:00PM +0300, Kirill Tkhai wrote:
I've complained about an unrelated issue in that part of the code
a while back (https://lkml.org/lkml/2014/5/12/508) which PeterZ
ended up fixing (https://lkml.org/lkml/2014/5/21/428) but it seems
that both of us forgot to
On 11/10/2014 05:03 AM, Peter Zijlstra wrote:
--- a/kernel/sched/fair.c
+++ b/kernel/sched/fair.c
@@ -1268,6 +1268,13 @@ static void task_numa_compare(struct tas
raw_spin_unlock_irq(dst_rq-lock);
/*
+ * Because we have preemption enabled we can get migrated around and
+
On Mon, Nov 10, 2014 at 10:48:28AM -0500, Sasha Levin wrote:
On 11/10/2014 05:03 AM, Peter Zijlstra wrote:
--- a/kernel/sched/fair.c
+++ b/kernel/sched/fair.c
@@ -1268,6 +1268,13 @@ static void task_numa_compare(struct tas
raw_spin_unlock_irq(dst_rq-lock);
/*
+*
On Fri, Nov 07, 2014 at 10:48:27PM -0500, Sasha Levin wrote:
[ 829.539183] BUG: spinlock recursion on CPU#10, trinity-c594/11067
[ 829.539203] lock: 0x880631dd6b80, .magic: dead4ead, .owner:
trinity-c594/11067, .owner_cpu: 13
Ooh, look at that. CPU#10 vs .owner_cpu: 13 on the _same_
On 11/10/2014 11:03 AM, Peter Zijlstra wrote:
On Fri, Nov 07, 2014 at 10:48:27PM -0500, Sasha Levin wrote:
[ 829.539183] BUG: spinlock recursion on CPU#10, trinity-c594/11067
[ 829.539203] lock: 0x880631dd6b80, .magic: dead4ead, .owner:
trinity-c594/11067, .owner_cpu: 13
Ooh, look
В Пн, 10/11/2014 в 17:03 +0100, Peter Zijlstra пишет:
On Fri, Nov 07, 2014 at 10:48:27PM -0500, Sasha Levin wrote:
[ 829.539183] BUG: spinlock recursion on CPU#10, trinity-c594/11067
[ 829.539203] lock: 0x880631dd6b80, .magic: dead4ead, .owner:
trinity-c594/11067, .owner_cpu: 13
On Mon, Nov 10, 2014 at 11:09:29AM -0500, Sasha Levin wrote:
On 11/10/2014 11:03 AM, Peter Zijlstra wrote:
On Fri, Nov 07, 2014 at 10:48:27PM -0500, Sasha Levin wrote:
[ 829.539183] BUG: spinlock recursion on CPU#10, trinity-c594/11067
[ 829.539203] lock: 0x880631dd6b80, .magic:
В Пн, 10/11/2014 в 19:10 +0300, Kirill Tkhai пишет:
В Пн, 10/11/2014 в 17:03 +0100, Peter Zijlstra пишет:
On Fri, Nov 07, 2014 at 10:48:27PM -0500, Sasha Levin wrote:
[ 829.539183] BUG: spinlock recursion on CPU#10, trinity-c594/11067
[ 829.539203] lock: 0x880631dd6b80, .magic:
On 11/10/2014 11:36 AM, Kirill Tkhai wrote:
I mean task_numa_find_cpu(). If a garbage is in cpumask_of_node(env-dst_nid)
and cpu is bigger than mask, the check
cpumask_test_cpu(cpu, tsk_cpus_allowed(env-p)
may be true.
So, we dereference wrong rq in task_numa_compare(). It's not rq at
10.11.2014, 19:45, Sasha Levin sasha.le...@oracle.com:
On 11/10/2014 11:36 AM, Kirill Tkhai wrote:
I mean task_numa_find_cpu(). If a garbage is in
cpumask_of_node(env-dst_nid)
and cpu is bigger than mask, the check
cpumask_test_cpu(cpu, tsk_cpus_allowed(env-p)
may be true.
So, we
Hi,
В Пт, 07/11/2014 в 22:48 -0500, Sasha Levin пишет:
> On 10/22/2014 03:17 AM, Kirill Tkhai wrote:
> > Unlocked access to dst_rq->curr in task_numa_compare() is racy.
> > If curr task is exiting this may be a reason of use-after-free:
> [...]
>
> I've complained about an unrelated issue in
Hi,
В Пт, 07/11/2014 в 22:48 -0500, Sasha Levin пишет:
On 10/22/2014 03:17 AM, Kirill Tkhai wrote:
Unlocked access to dst_rq-curr in task_numa_compare() is racy.
If curr task is exiting this may be a reason of use-after-free:
[...]
I've complained about an unrelated issue in that part of
On 10/22/2014 03:17 AM, Kirill Tkhai wrote:
> Unlocked access to dst_rq->curr in task_numa_compare() is racy.
> If curr task is exiting this may be a reason of use-after-free:
[...]
I've complained about an unrelated issue in that part of the code
a while back
On 10/22/2014 03:17 AM, Kirill Tkhai wrote:
Unlocked access to dst_rq-curr in task_numa_compare() is racy.
If curr task is exiting this may be a reason of use-after-free:
[...]
I've complained about an unrelated issue in that part of the code
a while back (https://lkml.org/lkml/2014/5/12/508)
Unlocked access to dst_rq->curr in task_numa_compare() is racy.
If curr task is exiting this may be a reason of use-after-free:
task_numa_compare()do_exit()
...current->flags |= PF_EXITING;
...
Unlocked access to dst_rq-curr in task_numa_compare() is racy.
If curr task is exiting this may be a reason of use-after-free:
task_numa_compare()do_exit()
...current-flags |= PF_EXITING;
...
32 matches
Mail list logo