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]

Message-ID: <20140226132852.GB30956@twins.programming.kicks-ass.net>
Date:	Wed, 26 Feb 2014 14:28:52 +0100
From:	Peter Zijlstra <peterz@...radead.org>
To:	George McCollister <george.mccollister@...il.com>
Cc:	linux-kernel@...r.kernel.org
Subject: Re: [PATCH] sched: fix double normalization of vruntime

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.

Can I have (or add) your Signed-off-by for this patch?
--
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/