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
| ||
|
Date: Tue, 12 Jan 2016 16:54:52 -0800 From: Michael Turquette <mturquette@...libre.com> To: Viresh Kumar <viresh.kumar@...aro.org>, "Juri Lelli" <juri.lelli@....com> Cc: linux-kernel@...r.kernel.org, linux-pm@...r.kernel.org, peterz@...radead.org, rjw@...ysocki.net, steve.muckle@...aro.org, vincent.guittot@...aro.org, morten.rasmussen@....com, dietmar.eggemann@....com Subject: Re: [RFC PATCH 18/19] cpufreq: remove transition_lock Hi Viresh, Quoting Viresh Kumar (2016-01-12 03:24:09) > On 11-01-16, 17:35, Juri Lelli wrote: > > From: Michael Turquette <mturquette@...libre.com> > > > > transition_lock was introduced to serialize cpufreq transition > > notifiers. Instead of using a different lock for protecting concurrent > > modifications of policy, it is better to require that callers of > > transition notifiers implement appropriate locking (this is already the > > case AFAICS). Removing transition_lock also simplifies current locking > > scheme. > > So, are you saying that the reasoning mentioned in this patch are all > wrong? > > commit 12478cf0c55e ("cpufreq: Make sure frequency transitions are > serialized") No, that's not what I'm saying. Quoting that patch: """ The key challenge is to allow drivers to begin the transition from one thread and end it in a completely different thread (this is to enable drivers that do asynchronous POSTCHANGE notification from bottom-halves, to also use the same interface). To achieve this, a 'transition_ongoing' flag, a 'transition_lock' spinlock and a wait-queue are added per-policy. The flag and the wait-queue are used in conjunction to create an "uninterrupted flow" from _begin() to _end(). The spinlock is used to ensure that only one such "flow" is in flight at any given time. Put together, this provides us all the necessary synchronization. """ So the transition_onging flag and wait-queue are all good. That stuff is just great. This patch doesn't touch it. What it does change is that it removes a superfluous spinlock that should never have needed to exist in the first place. cpufreq_freq_transition_begin is called directly by driver target callbacks, and it is called by __cpufreq_driver_target. __cpufreq_driver_target should be using a per-policy lock. Any other behavior is just insane. I haven't gone through this thread to see if that change has been made by Juri, but we need to get there either in this series or the follow-up series that introduces some RCU locking. Regards, Mike > > -- > viresh
Powered by blists - more mailing lists