linux-kernel - Re: [PATCH v2 5/8] sched,x86: Enable Turbo Boost Max Technology

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: <20160908182215.GA10153@twins.programming.kicks-ass.net>
Date:   Thu, 8 Sep 2016 20:22:15 +0200
From:   Peter Zijlstra <peterz@...radead.org>
To:     Tim Chen <tim.c.chen@...ux.intel.com>
Cc:     Srinivas Pandruvada <srinivas.pandruvada@...ux.intel.com>,
        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
Subject: Re: [PATCH v2 5/8] sched,x86: Enable Turbo Boost Max Technology

On Thu, Sep 08, 2016 at 11:09:28AM -0700, Tim Chen wrote:
> On Thu, Sep 08, 2016 at 09:59:55AM +0200, Peter Zijlstra wrote:
> > 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);
> 
> Peter,
> 
> Since enable_sched_itmt is only used by sched_itmt_update_handler,
> I've moved the mutex locking to sched_itmt_update_handler to eliminate
> the race condition in the code path you mentioned.

That is indeed simpler. Thanks!