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 G
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 t
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 befo
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 ta
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 ->mems_allo
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 inc
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 cpus
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_a
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:
> >> pytho
(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
>> kerne
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] in
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: py
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] CP
15 matches
Mail list logo
