[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20160908075955.GS10153@twins.programming.kicks-ass.net>
Date: Thu, 8 Sep 2016 09:59:55 +0200
From: Peter Zijlstra <peterz@...radead.org>
To: Srinivas Pandruvada <srinivas.pandruvada@...ux.intel.com>
Cc: rjw@...ysocki.net, tglx@...utronix.de, mingo@...hat.com,
bp@...e.de, x86@...nel.org, linux-pm@...r.kernel.org,
linux-kernel@...r.kernel.org, linux-acpi@...r.kernel.org,
tim.c.chen@...ux.intel.com
Subject: Re: [PATCH v2 5/8] sched,x86: Enable Turbo Boost Max Technology
On Thu, Sep 01, 2016 at 01:33:41PM -0700, Srinivas Pandruvada wrote:
> +static void enable_sched_itmt(bool enable_itmt)
> +{
> + mutex_lock(&itmt_update_mutex);
> +
> + sysctl_sched_itmt_enabled = enable_itmt;
> + x86_topology_update = true;
> + rebuild_sched_domains();
> +
> + mutex_unlock(&itmt_update_mutex);
> +}
> +
> +static int sched_itmt_update_handler(struct ctl_table *table, int write,
> + void __user *buffer, size_t *lenp, loff_t *ppos)
> +{
> + int ret;
> +
> + ret = proc_dointvec_minmax(table, write, buffer, lenp, ppos);
> +
> + if (ret || !write)
> + return ret;
> +
> + enable_sched_itmt(sysctl_sched_itmt_enabled);
> +
> + return ret;
> +}
I think there's a race here, if two tasks were to write to the sysctl
they'd both change the value before getting stuck on the mutex in
enable_sched_itmt().
One way around that is doing something like:
struct ctl_table t;
int val = sysctl_sched_itmt_enabled;
t = *table;
t.data = &val;
proc_dointvec_minmax(&t, ...);
/* and update the sysctl_sched_itmt_enabled value inside the mutex */
enable_sched_itmi(val);
Powered by blists - more mailing lists