From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755446AbdDLUUJ (ORCPT ); Wed, 12 Apr 2017 16:20:09 -0400 Received: from Galois.linutronix.de ([146.0.238.70]:35325 "EHLO Galois.linutronix.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752450AbdDLUUH (ORCPT ); Wed, 12 Apr 2017 16:20:07 -0400 Message-Id: <20170412200726.941336635@linutronix.de> User-Agent: quilt/0.63-1 Date: Wed, 12 Apr 2017 22:07:26 +0200 From: Thomas Gleixner To: LKML Cc: Peter Zijlstra , Ingo Molnar , Sebastian Siewior , Benjamin Herrenschmidt , "David S. Miller" , Fenghua Yu , Herbert Xu , Lai Jiangshan , Len Brown , Michael Ellerman , "Rafael J. Wysocki" , Tejun Heo , Tony Luck , Viresh Kumar Subject: [patch 00/13] sched/treewide: Clean up various racy task affinity issues Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org While dealing with the fallout of the scheduler cleanups on RT, we found several racy usage sites of the following scheme: cpumask_copy(&save_cpus_allowed, ¤t->cpus_allowed); set_cpus_allowed_ptr(current, cpumask_of(cpu)); do_stuff(); set_cpus_allowed_ptr(current, &save_cpus_allowed); That's racy in two aspects: 1) Nothing prevents the CPU from being unplugged after the temporary affinity setting is in place. This results on code being executed on the wrong CPU(s). 2) Nothing prevents a concurrent affinity setting from user space. That also results in code being executed on the wrong CPU(s) and the restore of the previous affinity setting overwrites the new one. Various variants of cleanups: - Removal, because the calling thread is already guaranteed to run on the correct CPU. - Conversion to smp function calls (simple register read/write) - Conversion to work_on_cpu(). There were even files containing comments to that effect. - The rest needs seperate hotplug protection for work_on_cpu(). To avoid open coding the get_online_cpus(); if (cpu_online(cpu)) ret = do_stuff(); else ret = -ENODEV; put_online_cpus(); scheme this series provides a new helper function work_on_cpu_safe() which implements the above. Aside of fixing these races this allows to restrict the access to current->cpus_allowed with a follow up series. Thanks, tglx --- arch/ia64/kernel/salinfo.c | 31 ++++------- arch/ia64/kernel/topology.c | 6 -- arch/ia64/sn/kernel/sn2/sn_hwperf.c | 16 +++--- arch/powerpc/kernel/smp.c | 26 ++++------ arch/sparc/kernel/sysfs.c | 36 +++---------- drivers/acpi/processor_driver.c | 10 +++ drivers/acpi/processor_throttling.c | 31 +++++------ drivers/cpufreq/ia64-acpi-cpufreq.c | 91 ++++++++++++++--------------------- drivers/cpufreq/sh-cpufreq.c | 45 ++++++++++------- drivers/cpufreq/sparc-us2e-cpufreq.c | 45 ++++++++--------- drivers/cpufreq/sparc-us3-cpufreq.c | 46 ++++++----------- drivers/crypto/n2_core.c | 31 ++++++----- include/linux/workqueue.h | 5 + kernel/workqueue.c | 23 ++++++++ 14 files changed, 209 insertions(+), 233 deletions(-)