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 PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Fri, 21 Mar 2014 11:05:59 +0000 From: Catalin Marinas <catalin.marinas@....com> To: Viresh Kumar <viresh.kumar@...aro.org> Cc: "Srivatsa S. Bhat" <srivatsa.bhat@...ux.vnet.ibm.com>, "Rafael J. Wysocki" <rjw@...ysocki.net>, Lists linaro-kernel <linaro-kernel@...ts.linaro.org>, "cpufreq@...r.kernel.org" <cpufreq@...r.kernel.org>, "linux-pm@...r.kernel.org" <linux-pm@...r.kernel.org>, Linux Kernel Mailing List <linux-kernel@...r.kernel.org>, "ego@...ux.vnet.ibm.com" <ego@...ux.vnet.ibm.com> Subject: Re: [PATCH V4 1/3] cpufreq: Make sure frequency transitions are serialized On Fri, Mar 21, 2014 at 09:21:02AM +0000, Viresh Kumar wrote: > @Catalin: We have a problem here and need your expert advice. After changing > CPU frequency we need to call this code: > > cpufreq_notify_post_transition(); > policy->transition_ongoing = false; > > And the sequence must be like this only. Is this guaranteed without any > memory barriers? cpufreq_notify_post_transition() isn't touching > transition_ongoing at all.. The above sequence doesn't say much. As rmk said, the compiler wouldn't reorder the transition_ongoing write before the function call. I think most architectures (not sure about Alpha) don't do speculative stores, so hardware wouldn't reorder them either. However, other stores inside the cpufreq_notify_post_transition() could be reordered after transition_ongoing store. The same for memory accesses after the transition_ongoing update, they could be reordered before. So what we actually need to know is what are the other relevant memory accesses that require strict ordering with transition_ongoing. What I find strange in your patch is that cpufreq_freq_transition_begin() uses spinlocks around transition_ongoing update but cpufreq_freq_transition_end() doesn't. -- Catalin -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@...r.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists