linux-kernel - Re: [tip:sched/urgent] nohz/full, sched/rt: Fix missed tick-reenabling bug in sched_can_stop

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] [day] [month] [year] [list]

Message-ID: <20160428133007.GB14497@lerouge>
Date:	Thu, 28 Apr 2016 15:30:10 +0200
From:	Frederic Weisbecker <fweisbec@...il.com>
To:	cl@...ux.com, alexander.shishkin@...ux.intel.com, mingo@...nel.org,
	tglx@...utronix.de, viresh.kumar@...aro.org, cmetcalf@...lanox.com,
	linux-kernel@...r.kernel.org, eranian@...gle.com, hpa@...or.com,
	riel@...hat.com, jolsa@...hat.com, vincent.weaver@...ne.edu,
	kernellwp@...il.com, lcapitulino@...hat.com, peterz@...radead.org,
	acme@...hat.com, efault@....de
Cc:	linux-tip-commits@...r.kernel.org
Subject: Re: [tip:sched/urgent] nohz/full, sched/rt: Fix missed
 tick-reenabling bug in sched_can_stop_tick()

On Thu, Apr 28, 2016 at 03:24:43AM -0700, tip-bot for Peter Zijlstra wrote:
> Commit-ID:  2548d546d40c0014efdde88a53bf7896e917dcce
> Gitweb:     http://git.kernel.org/tip/2548d546d40c0014efdde88a53bf7896e917dcce
> Author:     Peter Zijlstra <peterz@...radead.org>
> AuthorDate: Thu, 21 Apr 2016 18:03:15 +0200
> Committer:  Ingo Molnar <mingo@...nel.org>
> CommitDate: Thu, 28 Apr 2016 10:28:55 +0200
> 
> nohz/full, sched/rt: Fix missed tick-reenabling bug in sched_can_stop_tick()
> 
> Chris Metcalf reported a that sched_can_stop_tick() sometimes fails to
> re-enable the tick.
> 
> His observed problem is that rq->cfs.nr_running can be 1 even though
> there are multiple runnable CFS tasks. This happens in the cgroup
> case, in which case cfs.nr_running is the number of runnable entities
> for that level.
> 
> If there is a single runnable cgroup (which can have an arbitrary
> number of runnable child entries itself) rq->cfs.nr_running will be 1.
> 
> However, looking at that function I think there's more problems with it.
> 
> It seems to assume that if there's FIFO tasks, those will run. This is
> incorrect. The FIFO task can have a lower prio than an RR task, in which
> case the RR task will run.
> 
> So the whole fifo_nr_running test seems misplaced, it should go after
> the rr_nr_running tests. That is, only if !rr_nr_running, can we use
> fifo_nr_running like this.

Thanks for this patch. I indeed made confusions around SCHED_RR and SCHED_FIFO priorities.

Too late for me to ACK but I would have. Thanks!