Hi Tejun,
On 06/25/2014 04:58 AM, Tejun Heo wrote:
> Hello,
>
> On Tue, Jun 24, 2014 at 10:28:12AM +0800, Li Zefan wrote:
>>> I don't think the suggested patch breaks anything more than it was
>>> broken before and we should probably apply it for the time being. Li?
>>
>> Yeah, we should apply
Hello,
On Tue, Jun 24, 2014 at 10:28:12AM +0800, Li Zefan wrote:
> > I don't think the suggested patch breaks anything more than it was
> > broken before and we should probably apply it for the time being. Li?
>
> Yeah, we should apply Gu Zheng's patch any way.
Gu Zheng, can you please respin
Hello,
On Tue, Jun 24, 2014 at 10:28:12AM +0800, Li Zefan wrote:
I don't think the suggested patch breaks anything more than it was
broken before and we should probably apply it for the time being. Li?
Yeah, we should apply Gu Zheng's patch any way.
Gu Zheng, can you please respin the
Hi Tejun,
On 06/25/2014 04:58 AM, Tejun Heo wrote:
Hello,
On Tue, Jun 24, 2014 at 10:28:12AM +0800, Li Zefan wrote:
I don't think the suggested patch breaks anything more than it was
broken before and we should probably apply it for the time being. Li?
Yeah, we should apply Gu Zheng's
On 2014/6/21 5:01, Tejun Heo wrote:
> Hello, Li.
>
> Sorry about the long delay.
>
> On Tue, Jun 10, 2014 at 10:58:45AM +0800, Li Zefan wrote:
>> Yes, this is a long-standing issue. Besides the race you described, the child
>> task's mems_allowed can be wrong if the cpuset's nodemask changes
On 2014/6/21 5:01, Tejun Heo wrote:
Hello, Li.
Sorry about the long delay.
On Tue, Jun 10, 2014 at 10:58:45AM +0800, Li Zefan wrote:
Yes, this is a long-standing issue. Besides the race you described, the child
task's mems_allowed can be wrong if the cpuset's nodemask changes before the
Hello, Li.
Sorry about the long delay.
On Tue, Jun 10, 2014 at 10:58:45AM +0800, Li Zefan wrote:
> Yes, this is a long-standing issue. Besides the race you described, the child
> task's mems_allowed can be wrong if the cpuset's nodemask changes before the
> child has been added to the cgroup's
Hello, Li.
Sorry about the long delay.
On Tue, Jun 10, 2014 at 10:58:45AM +0800, Li Zefan wrote:
Yes, this is a long-standing issue. Besides the race you described, the child
task's mems_allowed can be wrong if the cpuset's nodemask changes before the
child has been added to the cgroup's
On Tue, 10 Jun 2014, Li Zefan wrote:
> > Yes, the rcu lock is not providing protection for any critical section
> > here that requires (1) the forker's cpuset to be stored in
> > cpuset_being_rebound or (2) the forked thread's cpuset to be rebound by
> > the cpuset nodemask update, and no race
On Tue, 10 Jun 2014, Li Zefan wrote:
Yes, the rcu lock is not providing protection for any critical section
here that requires (1) the forker's cpuset to be stored in
cpuset_being_rebound or (2) the forked thread's cpuset to be rebound by
the cpuset nodemask update, and no race
On 2014/6/9 17:13, David Rientjes wrote:
> On Mon, 9 Jun 2014, Gu Zheng wrote:
>
>>> I think your patch addresses the problem that you're reporting but misses
>>> the larger problem with cpuset.mems rebinding on fork(). When the
>>> forker's task_struct is duplicated (which includes
Hi David,
On 06/09/2014 05:13 PM, David Rientjes wrote:
> On Mon, 9 Jun 2014, Gu Zheng wrote:
>
>>> I think your patch addresses the problem that you're reporting but misses
>>> the larger problem with cpuset.mems rebinding on fork(). When the
>>> forker's task_struct is duplicated (which
On Mon, 9 Jun 2014, Gu Zheng wrote:
> > I think your patch addresses the problem that you're reporting but misses
> > the larger problem with cpuset.mems rebinding on fork(). When the
> > forker's task_struct is duplicated (which includes ->mems_allowed) and it
> > races with an update to
Hi David,
On 06/09/2014 06:47 AM, David Rientjes wrote:
> On Fri, 6 Jun 2014, Gu Zheng wrote:
>
When running with the kernel(3.15-rc7+), the follow bug occurs:
[ 9969.258987] BUG: sleeping function called from invalid context at
kernel/locking/mutex.c:586
[ 9969.359906]
Hi David,
On 06/09/2014 06:47 AM, David Rientjes wrote:
On Fri, 6 Jun 2014, Gu Zheng wrote:
When running with the kernel(3.15-rc7+), the follow bug occurs:
[ 9969.258987] BUG: sleeping function called from invalid context at
kernel/locking/mutex.c:586
[ 9969.359906] in_atomic(): 1,
On Mon, 9 Jun 2014, Gu Zheng wrote:
I think your patch addresses the problem that you're reporting but misses
the larger problem with cpuset.mems rebinding on fork(). When the
forker's task_struct is duplicated (which includes -mems_allowed) and it
races with an update to
Hi David,
On 06/09/2014 05:13 PM, David Rientjes wrote:
On Mon, 9 Jun 2014, Gu Zheng wrote:
I think your patch addresses the problem that you're reporting but misses
the larger problem with cpuset.mems rebinding on fork(). When the
forker's task_struct is duplicated (which includes
On 2014/6/9 17:13, David Rientjes wrote:
On Mon, 9 Jun 2014, Gu Zheng wrote:
I think your patch addresses the problem that you're reporting but misses
the larger problem with cpuset.mems rebinding on fork(). When the
forker's task_struct is duplicated (which includes -mems_allowed) and it
On Fri, 6 Jun 2014, Gu Zheng wrote:
> >> When running with the kernel(3.15-rc7+), the follow bug occurs:
> >> [ 9969.258987] BUG: sleeping function called from invalid context at
> >> kernel/locking/mutex.c:586
> >> [ 9969.359906] in_atomic(): 1, irqs_disabled(): 0, pid: 160655, name:
> >>
On Fri, 6 Jun 2014, Gu Zheng wrote:
When running with the kernel(3.15-rc7+), the follow bug occurs:
[ 9969.258987] BUG: sleeping function called from invalid context at
kernel/locking/mutex.c:586
[ 9969.359906] in_atomic(): 1, irqs_disabled(): 0, pid: 160655, name:
python
[
(cc'ing Li)
Hi Andrew,
Thanks for your comment.
On 06/06/2014 04:23 AM, Andrew Morton wrote:
> On Thu, 5 Jun 2014 16:28:52 +0800 Gu Zheng wrote:
>
>> When running with the kernel(3.15-rc7+), the follow bug occurs:
>> [ 9969.258987] BUG: sleeping function called from invalid context at
>>
Hi Greg,
On 06/05/2014 10:18 PM, Greg KH wrote:
> On Thu, Jun 05, 2014 at 04:28:52PM +0800, Gu Zheng wrote:
>> When running with the kernel(3.15-rc7+), the follow bug occurs:
>> [ 9969.258987] BUG: sleeping function called from invalid context at
>> kernel/locking/mutex.c:586
>> [ 9969.359906]
Hi Greg,
On 06/05/2014 10:18 PM, Greg KH wrote:
On Thu, Jun 05, 2014 at 04:28:52PM +0800, Gu Zheng wrote:
When running with the kernel(3.15-rc7+), the follow bug occurs:
[ 9969.258987] BUG: sleeping function called from invalid context at
kernel/locking/mutex.c:586
[ 9969.359906]
(cc'ing Li)
Hi Andrew,
Thanks for your comment.
On 06/06/2014 04:23 AM, Andrew Morton wrote:
On Thu, 5 Jun 2014 16:28:52 +0800 Gu Zheng guz.f...@cn.fujitsu.com wrote:
When running with the kernel(3.15-rc7+), the follow bug occurs:
[ 9969.258987] BUG: sleeping function called from invalid
On Thu, 5 Jun 2014 16:28:52 +0800 Gu Zheng wrote:
> When running with the kernel(3.15-rc7+), the follow bug occurs:
> [ 9969.258987] BUG: sleeping function called from invalid context at
> kernel/locking/mutex.c:586
> [ 9969.359906] in_atomic(): 1, irqs_disabled(): 0, pid: 160655, name: python
On Thu, Jun 05, 2014 at 04:28:52PM +0800, Gu Zheng wrote:
> When running with the kernel(3.15-rc7+), the follow bug occurs:
> [ 9969.258987] BUG: sleeping function called from invalid context at
> kernel/locking/mutex.c:586
> [ 9969.359906] in_atomic(): 1, irqs_disabled(): 0, pid: 160655, name:
When running with the kernel(3.15-rc7+), the follow bug occurs:
[ 9969.258987] BUG: sleeping function called from invalid context at
kernel/locking/mutex.c:586
[ 9969.359906] in_atomic(): 1, irqs_disabled(): 0, pid: 160655, name: python
[ 9969.441175] INFO: lockdep is turned off.
[ 9969.488184]
When running with the kernel(3.15-rc7+), the follow bug occurs:
[ 9969.258987] BUG: sleeping function called from invalid context at
kernel/locking/mutex.c:586
[ 9969.359906] in_atomic(): 1, irqs_disabled(): 0, pid: 160655, name: python
[ 9969.441175] INFO: lockdep is turned off.
[ 9969.488184]
On Thu, Jun 05, 2014 at 04:28:52PM +0800, Gu Zheng wrote:
When running with the kernel(3.15-rc7+), the follow bug occurs:
[ 9969.258987] BUG: sleeping function called from invalid context at
kernel/locking/mutex.c:586
[ 9969.359906] in_atomic(): 1, irqs_disabled(): 0, pid: 160655, name:
On Thu, 5 Jun 2014 16:28:52 +0800 Gu Zheng guz.f...@cn.fujitsu.com wrote:
When running with the kernel(3.15-rc7+), the follow bug occurs:
[ 9969.258987] BUG: sleeping function called from invalid context at
kernel/locking/mutex.c:586
[ 9969.359906] in_atomic(): 1, irqs_disabled(): 0, pid:
30 matches
Mail list logo
