>> 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
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
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
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
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
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
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 */
>
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 */
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. */
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
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
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
> 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.
>
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
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
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
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
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.
18 matches
Mail list logo