Re: Racy manipulation of task_struct->flags in cgroups code causes hard to reproduce kernel panics

2014-09-21 Thread Zefan Li
>> On Sat, Sep 20, 2014 at 01:55:54PM +0800, Zefan Li wrote: Then, what made current->flags to unexpectedly preserve PF_USED_MATH flag? The user is running cgrulesengd process in order to utilize cpuset cgroup. Thus, cpuset_update_task_spread_flag() is called when cgrulesengd

Re: Racy manipulation of task_struct-flags in cgroups code causes hard to reproduce kernel panics

2014-09-21 Thread Zefan Li
On Sat, Sep 20, 2014 at 01:55:54PM +0800, Zefan Li wrote: Then, what made current-flags to unexpectedly preserve PF_USED_MATH flag? The user is running cgrulesengd process in order to utilize cpuset cgroup. Thus, cpuset_update_task_spread_flag() is called when cgrulesengd process writes

Re: Racy manipulation of task_struct->flags in cgroups code causes hard to reproduce kernel panics

2014-09-20 Thread Tetsuo Handa
Tejun Heo wrote: > Hello, > > On Sat, Sep 20, 2014 at 01:55:54PM +0800, Zefan Li wrote: > > > Then, what made current->flags to unexpectedly preserve PF_USED_MATH flag? > > > The user is running cgrulesengd process in order to utilize cpuset cgroup. > > > Thus, cpuset_update_task_spread_flag() is

Re: Racy manipulation of task_struct->flags in cgroups code causes hard to reproduce kernel panics

2014-09-20 Thread Peter Zijlstra
On Sat, Sep 20, 2014 at 10:15:50AM -0700, Kees Cook wrote: > On Sat, Sep 20, 2014 at 7:30 AM, Peter Zijlstra wrote: > > On Sat, Sep 20, 2014 at 01:55:54PM +0800, Zefan Li wrote: > >> We should make the updating of this flag atomic. > > > >> /* Per-process atomic flags. */ > >> #define

Re: Racy manipulation of task_struct->flags in cgroups code causes hard to reproduce kernel panics

2014-09-20 Thread Tejun Heo
Hello, On Sat, Sep 20, 2014 at 01:55:54PM +0800, Zefan Li wrote: > > Then, what made current->flags to unexpectedly preserve PF_USED_MATH flag? > > The user is running cgrulesengd process in order to utilize cpuset cgroup. > > Thus, cpuset_update_task_spread_flag() is called when cgrulesengd

Re: Racy manipulation of task_struct->flags in cgroups code causes hard to reproduce kernel panics

2014-09-20 Thread Kees Cook
On Sat, Sep 20, 2014 at 7:30 AM, Peter Zijlstra wrote: > On Sat, Sep 20, 2014 at 01:55:54PM +0800, Zefan Li wrote: >> We should make the updating of this flag atomic. > >> /* Per-process atomic flags. */ >> #define PFA_NO_NEW_PRIVS 0x0001 /* May not gain new privileges. */ >> +#define

Re: Racy manipulation of task_struct->flags in cgroups code causes hard to reproduce kernel panics

2014-09-20 Thread Peter Zijlstra
On Sat, Sep 20, 2014 at 01:55:54PM +0800, Zefan Li wrote: > We should make the updating of this flag atomic. > /* Per-process atomic flags. */ > #define PFA_NO_NEW_PRIVS 0x0001 /* May not gain new privileges. */ > +#define PFA_SPREAD_PAGE 0x0002 /* Spread page cache over cpuset */ >

Re: Racy manipulation of task_struct-flags in cgroups code causes hard to reproduce kernel panics

2014-09-20 Thread Peter Zijlstra
On Sat, Sep 20, 2014 at 01:55:54PM +0800, Zefan Li wrote: We should make the updating of this flag atomic. /* Per-process atomic flags. */ #define PFA_NO_NEW_PRIVS 0x0001 /* May not gain new privileges. */ +#define PFA_SPREAD_PAGE 0x0002 /* Spread page cache over cpuset */

Re: Racy manipulation of task_struct-flags in cgroups code causes hard to reproduce kernel panics

2014-09-20 Thread Kees Cook
On Sat, Sep 20, 2014 at 7:30 AM, Peter Zijlstra pet...@infradead.org wrote: On Sat, Sep 20, 2014 at 01:55:54PM +0800, Zefan Li wrote: We should make the updating of this flag atomic. /* Per-process atomic flags. */ #define PFA_NO_NEW_PRIVS 0x0001 /* May not gain new privileges. */

Re: Racy manipulation of task_struct-flags in cgroups code causes hard to reproduce kernel panics

2014-09-20 Thread Tejun Heo
Hello, On Sat, Sep 20, 2014 at 01:55:54PM +0800, Zefan Li wrote: Then, what made current-flags to unexpectedly preserve PF_USED_MATH flag? The user is running cgrulesengd process in order to utilize cpuset cgroup. Thus, cpuset_update_task_spread_flag() is called when cgrulesengd process

Re: Racy manipulation of task_struct-flags in cgroups code causes hard to reproduce kernel panics

2014-09-20 Thread Peter Zijlstra
On Sat, Sep 20, 2014 at 10:15:50AM -0700, Kees Cook wrote: On Sat, Sep 20, 2014 at 7:30 AM, Peter Zijlstra pet...@infradead.org wrote: On Sat, Sep 20, 2014 at 01:55:54PM +0800, Zefan Li wrote: We should make the updating of this flag atomic. /* Per-process atomic flags. */ #define

Re: Racy manipulation of task_struct-flags in cgroups code causes hard to reproduce kernel panics

2014-09-20 Thread Tetsuo Handa
Tejun Heo wrote: Hello, On Sat, Sep 20, 2014 at 01:55:54PM +0800, Zefan Li wrote: Then, what made current-flags to unexpectedly preserve PF_USED_MATH flag? The user is running cgrulesengd process in order to utilize cpuset cgroup. Thus, cpuset_update_task_spread_flag() is called when

Re: Racy manipulation of task_struct->flags in cgroups code causes hard to reproduce kernel panics

2014-09-19 Thread Zefan Li
> Then, what made current->flags to unexpectedly preserve PF_USED_MATH flag? > The user is running cgrulesengd process in order to utilize cpuset cgroup. > Thus, cpuset_update_task_spread_flag() is called when cgrulesengd process > writes someone's pid to /cgroup/cpuset/$group/tasks interface. >

Re: Racy manipulation of task_struct->flags in cgroups code causes hard to reproduce kernel panics

2014-09-19 Thread Peter Zijlstra
On Fri, Sep 19, 2014 at 08:53:33PM +0900, Tetsuo Handa wrote: > cpuset_update_task_spread_flag() is updating other thread's > "struct task_struct"->flags without exclusion control or atomic > operations! > > -- linux-2.6.32-358.23.2.el6/kernel/cpuset.c -- > 300:/* > 301: * update

Racy manipulation of task_struct->flags in cgroups code causes hard to reproduce kernel panics

2014-09-19 Thread Tetsuo Handa
A user is experiencing kernel panic described at https://access.redhat.com/solutions/640843 . It turned out that the root cause seems to be a race condition between clear_used_math() and cpuset_attach_task(). I'm reporting this problem here because this race condition remains in current upstream

Racy manipulation of task_struct-flags in cgroups code causes hard to reproduce kernel panics

2014-09-19 Thread Tetsuo Handa
A user is experiencing kernel panic described at https://access.redhat.com/solutions/640843 . It turned out that the root cause seems to be a race condition between clear_used_math() and cpuset_attach_task(). I'm reporting this problem here because this race condition remains in current upstream

Re: Racy manipulation of task_struct-flags in cgroups code causes hard to reproduce kernel panics

2014-09-19 Thread Peter Zijlstra
On Fri, Sep 19, 2014 at 08:53:33PM +0900, Tetsuo Handa wrote: cpuset_update_task_spread_flag() is updating other thread's struct task_struct-flags without exclusion control or atomic operations! -- linux-2.6.32-358.23.2.el6/kernel/cpuset.c -- 300:/* 301: * update task's

Re: Racy manipulation of task_struct-flags in cgroups code causes hard to reproduce kernel panics

2014-09-19 Thread Zefan Li
Then, what made current-flags to unexpectedly preserve PF_USED_MATH flag? The user is running cgrulesengd process in order to utilize cpuset cgroup. Thus, cpuset_update_task_spread_flag() is called when cgrulesengd process writes someone's pid to /cgroup/cpuset/$group/tasks interface.