On 02/20/2014 02:10 AM, Sasha Levin wrote:
> On 02/17/2014 09:26 PM, Michael wang wrote:
>> On 02/17/2014 05:20 PM, Peter Zijlstra wrote:
>> [snip]
>> static void switched_to_fair(struct rq *rq, struct task_struct *p)
>> {
>>-if (!p->se.on_rq)
>>+struct sched_entity *s
On 02/20/2014 12:16 AM, Peter Zijlstra wrote:
[snip]
>>
>>
>>
>> diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
>> index 235cfa7..4445e56 100644
>> --- a/kernel/sched/fair.c
>> +++ b/kernel/sched/fair.c
>> @@ -7317,7 +7317,11 @@ static void switched_from_fair(struct rq *rq, struct
>> task_
On Wed, Feb 19, 2014 at 01:10:22PM -0500, Sasha Levin wrote:
> On 02/17/2014 09:26 PM, Michael wang wrote:
> >On 02/17/2014 05:20 PM, Peter Zijlstra wrote:
> >[snip]
> > static void switched_to_fair(struct rq *rq, struct task_struct *p)
> > {
> >-if (!p->se.on_rq)
> >+
On 02/17/2014 09:26 PM, Michael wang wrote:
On 02/17/2014 05:20 PM, Peter Zijlstra wrote:
[snip]
>> static void switched_to_fair(struct rq *rq, struct task_struct *p)
>> {
>>- if (!p->se.on_rq)
>>+ struct sched_entity *se = &p->se;
>>+#ifdef CONFIG_FAIR_GROUP_SCHED
>>+ se->de
On Mon, Feb 17, 2014 at 04:11:09PM +0800, Michael wang wrote:
> > While fuzzing with trinity inside a KVM tools guest running latest -next
> > kernel, I've
> > stumbled on the following:
>
> I've reproduced the same issue with tip/master, and below patch fixed the
> problem on my box along with so
On 02/18/2014 05:07 AM, Sasha Levin wrote:
[snip]
>
> I *think* it works. There seems to be another sched issue that causes
> lockups,
> so I can't say for certain that this one doesn't occur anymore.
>
> I'm still working on collecting data for the other issue, I'll mail
> about it soon.
Thanks
On 02/17/2014 05:20 PM, Peter Zijlstra wrote:
[snip]
>> static void switched_to_fair(struct rq *rq, struct task_struct *p)
>> {
>> -if (!p->se.on_rq)
>> +struct sched_entity *se = &p->se;
>> +#ifdef CONFIG_FAIR_GROUP_SCHED
>> +se->depth = se->parent ? se->parent->depth + 1 : 0;
>> +#e
On 02/17/2014 03:11 AM, Michael wang wrote:
Hi, Sasha
On 02/16/2014 07:27 AM, Sasha Levin wrote:
Hi folks,
While fuzzing with trinity inside a KVM tools guest running latest -next
kernel, I've
stumbled on the following:
I've reproduced the same issue with tip/master, and below patch fixed th
On Mon, Feb 17, 2014 at 04:11:09PM +0800, Michael wang wrote:
> BTW, I reproduced it by steps:
> 1. change current to RT
> 2. move to a different depth cpu-cgroup
> 3. change it back to FAIR
>
> Seems like it was caused by that RT has no task_move_group() implemented
> which could maintain depth,
Hi, Sasha
On 02/16/2014 07:27 AM, Sasha Levin wrote:
> Hi folks,
>
> While fuzzing with trinity inside a KVM tools guest running latest -next
> kernel, I've
> stumbled on the following:
I've reproduced the same issue with tip/master, and below patch fixed the
problem on my box along with some rc
On Sat, Feb 15, 2014 at 06:27:52PM -0500, Sasha Levin wrote:
> Hi folks,
>
> While fuzzing with trinity inside a KVM tools guest running latest -next
> kernel, I've
> stumbled on the following:
>
> [ 522.645288] BUG: unable to handle kernel NULL pointer dereference at
> 0150
> [ 5
On 02/15/2014 06:27 PM, Sasha Levin wrote:
Hi folks,
While fuzzing with trinity inside a KVM tools guest running latest -next
kernel, I've
stumbled on the following:
As soon as I've finished writing that mail I've hit it again, with a different (but similar) stack
trace.
[ 770.993016] BUG
Hi folks,
While fuzzing with trinity inside a KVM tools guest running latest -next
kernel, I've
stumbled on the following:
[ 522.645288] BUG: unable to handle kernel NULL pointer dereference at
0150
[ 522.646271] IP: [] check_preempt_wakeup+0x11f/0x210
[ 522.646976] PGD b0a79067
13 matches
Mail list logo
