linux-kernel - Re: [PATCH] sched: fix double normalization of vruntime

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Wed, 26 Feb 2014 12:59:35 -0600
From:	George McCollister <george.mccollister@...il.com>
To:	Peter Zijlstra <peterz@...radead.org>
Cc:	linux-kernel@...r.kernel.org
Subject: Re: [PATCH] sched: fix double normalization of vruntime

On Wed, Feb 26, 2014 at 7:28 AM, Peter Zijlstra <peterz@...radead.org> wrote:
> On Tue, Feb 18, 2014 at 05:56:51PM -0600, George McCollister wrote:
>> dequeue_entity() is called when p->on_rq and sets se->on_rq = 0
>> which appears to guarentee that the !se->on_rq condition is met.
>> If the task has done set_current_state(TASK_INTERRUPTIBLE) without
>> schedule() the second condition will be met and vruntime will be
>> incorrectly adjusted twice.
>>
>> In certain cases this can result in the task's vruntime never increasing
>> past the vruntime of other tasks on the CFS' run queue, starving them of
>> CPU time.
>>
>> This patch changes switched_from_fair() to use !p->on_rq instead of
>> !se->on_rq.
>>
>> I'm able to cause a task with a priority of 120 to starve all other
>> tasks with the same priority on an ARM platform running 3.2.51-rt72
>> PREEMPT RT by writing one character at time to a serial tty (16550 UART)
>> in a tight loop. I'm also able to verify making this change corrects the
>> problem on that platform and kernel version.
>>
>> I haven't and not sure I will have an opportunity to get a newer kernel
>> version running on the platform mentioned above and have yet to
>> reproduce the problem on another platform.
>
> Yes, I think you're quite right. Another way to look at this is that
> p->on_rq is the one matching p->state.
Yes, correct

>
> Can I have (or add) your Signed-off-by for this patch?

Go ahead and add my sign off. I didn't want to add it before
discussing the issue with someone.

Thanks,
George McCollister
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/