Re: [PATCH v4] sched/numa: fix unsafe get_task_struct() in task_numa_assign()

2014-11-18 Thread Sasha Levin
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:

Re: [PATCH v4] sched/numa: fix unsafe get_task_struct() in task_numa_assign()

2014-11-18 Thread Sasha Levin
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:

Re: [PATCH v4] sched/numa: fix unsafe get_task_struct() in task_numa_assign()

2014-11-14 Thread Sasha Levin
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 >

Re: [PATCH v4] sched/numa: fix unsafe get_task_struct() in task_numa_assign()

2014-11-14 Thread Sasha Levin
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

Re: [PATCH v4] sched/numa: fix unsafe get_task_struct() in task_numa_assign()

2014-11-12 Thread Kirill Tkhai
В Пн, 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 > >> > >>

Re: [PATCH v4] sched/numa: fix unsafe get_task_struct() in task_numa_assign()

2014-11-12 Thread Kirill Tkhai
В Пн, 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

Re: [PATCH v4] sched/numa: fix unsafe get_task_struct() in task_numa_assign()

2014-11-10 Thread 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 >> >>  cpumask_test_cpu(cpu, tsk_cpus_allowed(env->p) >> >>  may be true. >> >>  So,

Re: [PATCH v4] sched/numa: fix unsafe get_task_struct() in task_numa_assign()

2014-11-10 Thread 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, we dereference wrong rq in task_numa_compare(). It's

Re: [PATCH v4] sched/numa: fix unsafe get_task_struct() in task_numa_assign()

2014-11-10 Thread Kirill Tkhai
В Пн, 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,

Re: [PATCH v4] sched/numa: fix unsafe get_task_struct() in task_numa_assign()

2014-11-10 Thread Peter Zijlstra
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,

Re: [PATCH v4] sched/numa: fix unsafe get_task_struct() in task_numa_assign()

2014-11-10 Thread 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: dead4ead, .owner: > > trinity-c594/11067, .owner_cpu:

Re: [PATCH v4] sched/numa: fix unsafe get_task_struct() in task_numa_assign()

2014-11-10 Thread Sasha Levin
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 > >

Re: [PATCH v4] sched/numa: fix unsafe get_task_struct() in task_numa_assign()

2014-11-10 Thread 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 Ooh, look at that. CPU#10 vs .owner_cpu: 13 on the _same_

Re: [PATCH v4] sched/numa: fix unsafe get_task_struct() in task_numa_assign()

2014-11-10 Thread Peter Zijlstra
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); > > > > /* > >

Re: [PATCH v4] sched/numa: fix unsafe get_task_struct() in task_numa_assign()

2014-11-10 Thread Sasha Levin
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

Re: [PATCH v4] sched/numa: fix unsafe get_task_struct() in task_numa_assign()

2014-11-10 Thread Peter Zijlstra
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

Re: [PATCH v4] sched/numa: fix unsafe get_task_struct() in task_numa_assign()

2014-11-10 Thread Peter Zijlstra
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

Re: [PATCH v4] sched/numa: fix unsafe get_task_struct() in task_numa_assign()

2014-11-10 Thread Sasha Levin
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 +

Re: [PATCH v4] sched/numa: fix unsafe get_task_struct() in task_numa_assign()

2014-11-10 Thread Peter Zijlstra
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); /* +*

Re: [PATCH v4] sched/numa: fix unsafe get_task_struct() in task_numa_assign()

2014-11-10 Thread 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 Ooh, look at that. CPU#10 vs .owner_cpu: 13 on the _same_

Re: [PATCH v4] sched/numa: fix unsafe get_task_struct() in task_numa_assign()

2014-11-10 Thread Sasha Levin
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

Re: [PATCH v4] sched/numa: fix unsafe get_task_struct() in task_numa_assign()

2014-11-10 Thread 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: dead4ead, .owner: trinity-c594/11067, .owner_cpu: 13

Re: [PATCH v4] sched/numa: fix unsafe get_task_struct() in task_numa_assign()

2014-11-10 Thread Peter Zijlstra
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:

Re: [PATCH v4] sched/numa: fix unsafe get_task_struct() in task_numa_assign()

2014-11-10 Thread Kirill Tkhai
В Пн, 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:

Re: [PATCH v4] sched/numa: fix unsafe get_task_struct() in task_numa_assign()

2014-11-10 Thread 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, we dereference wrong rq in task_numa_compare(). It's not rq at

Re: [PATCH v4] sched/numa: fix unsafe get_task_struct() in task_numa_assign()

2014-11-10 Thread 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  cpumask_test_cpu(cpu, tsk_cpus_allowed(env-p)  may be true.  So, we

Re: [PATCH v4] sched/numa: fix unsafe get_task_struct() in task_numa_assign()

2014-11-09 Thread Kirill Tkhai
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

Re: [PATCH v4] sched/numa: fix unsafe get_task_struct() in task_numa_assign()

2014-11-09 Thread Kirill Tkhai
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

Re: [PATCH v4] sched/numa: fix unsafe get_task_struct() in task_numa_assign()

2014-11-07 Thread 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 the code a while back

Re: [PATCH v4] sched/numa: fix unsafe get_task_struct() in task_numa_assign()

2014-11-07 Thread 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 the code a while back (https://lkml.org/lkml/2014/5/12/508)

[PATCH v4] sched/numa: fix unsafe get_task_struct() in task_numa_assign()

2014-10-22 Thread Kirill Tkhai
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; ...

[PATCH v4] sched/numa: fix unsafe get_task_struct() in task_numa_assign()

2014-10-22 Thread Kirill Tkhai
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; ...