linux-kernel - [PATCH 3.16.y-ckt 041/129] vmstat: explicitly schedule per-cpu work on the CPU we need it to run on

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: <1456482100-4667-42-git-send-email-luis.henriques@canonical.com>
Date:	Fri, 26 Feb 2016 10:20:12 +0000
From:	Luis Henriques <luis.henriques@...onical.com>
To:	linux-kernel@...r.kernel.org, stable@...r.kernel.org,
	kernel-team@...ts.ubuntu.com
Cc:	Christoph Lameter <cl@...ux.com>, Tejun Heo <tj@...nel.org>,
	Mike Galbraith <mgalbraith@...e.com>,
	Michal Hocko <mhocko@...e.com>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Jiri Slaby <jslaby@...e.cz>,
	Kamal Mostafa <kamal@...onical.com>,
	Luis Henriques <luis.henriques@...onical.com>
Subject: [PATCH 3.16.y-ckt 041/129] vmstat: explicitly schedule per-cpu work on the CPU we need it to run on

3.16.7-ckt25 -stable review patch.  If anyone has any objections, please let me know.

---8<------------------------------------------------------------

From: Linus Torvalds <torvalds@...ux-foundation.org>

commit 176bed1de5bf977938cad26551969eca8f0883b1 upstream.

The vmstat code uses "schedule_delayed_work_on()" to do the initial
startup of the delayed work on the right CPU, but then once it was
started it would use the non-cpu-specific "schedule_delayed_work()" to
re-schedule it on that CPU.

That just happened to schedule it on the same CPU historically (well, in
almost all situations), but the code _requires_ this work to be per-cpu,
and should say so explicitly rather than depend on the non-cpu-specific
scheduling to schedule on the current CPU.

The timer code is being changed to not be as single-minded in always
running things on the calling CPU.

See also commit 874bbfe600a6 ("workqueue: make sure delayed work run in
local cpu") that for now maintains the local CPU guarantees just in case
there are other broken users that depended on the accidental behavior.

js: 3.12 backport

Cc: Christoph Lameter <cl@...ux.com>
Cc: Tejun Heo <tj@...nel.org>
Cc: Mike Galbraith <mgalbraith@...e.com>
Cc: Michal Hocko <mhocko@...e.com>
Signed-off-by: Linus Torvalds <torvalds@...ux-foundation.org>
Signed-off-by: Jiri Slaby <jslaby@...e.cz>
[ kamal: backport to 3.16-stable: use queue_delayed_work_on() ]
Signed-off-by: Kamal Mostafa <kamal@...onical.com>
Signed-off-by: Luis Henriques <luis.henriques@...onical.com>
---
 mm/vmstat.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/mm/vmstat.c b/mm/vmstat.c
index 038f9418b234..8c0c76083562 100644
--- a/mm/vmstat.c
+++ b/mm/vmstat.c
@@ -1233,7 +1233,8 @@ int sysctl_stat_interval __read_mostly = HZ;
 static void vmstat_update(struct work_struct *w)
 {
 	refresh_cpu_vm_stats();
-	queue_delayed_work(vmstat_wq, this_cpu_ptr(&vmstat_work),
+	queue_delayed_work_on(smp_processor_id(), vmstat_wq,
+		this_cpu_ptr(&vmstat_work),
 		round_jiffies_relative(sysctl_stat_interval));
 }