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
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Fri, 21 Mar 2014 14:51:02 +0530
From:	Viresh Kumar <>
To:	"Srivatsa S. Bhat" <>,
	Catalin Marinas <>
Cc:	"Rafael J. Wysocki" <>,
	Lists linaro-kernel <>,
	"" <>,
	"" <>,
	Linux Kernel Mailing List <>,
	"" <>
Subject: Re: [PATCH V4 1/3] cpufreq: Make sure frequency transitions are serialized

On 21 March 2014 14:12, Srivatsa S. Bhat
<> wrote:
>> You can find some information on this in
>> Documentation/memory-barriers.txt
> Yep, I know, I have read it several times, but I'm no expert ;-)

Not me either :) .. That file has so complex stuff in there that its
difficult to
understand what's all it says.. I read it several times the last time I went for
a interview (Almost 2 years back) and don't remember anything now :)

> I found this interesting section on "SLEEP AND WAKE-UP FUNCTIONS". It
> says that doing:
> policy->transition_ongoing = false;
> wake_up(&policy->transition_wait);
> is safe (as long as some tasks are woken up). So we don't have to worry
> about that part.


> So only the first part remains to be solved: ensuring
> that the assignment occurs _after_ completing the invocation of the
> POSTCHANGE notifiers.
> For that, we can do:
> cpufreq_notify_post_transition();
> smp_mb();
> policy->transition_ongoing = false;
> That should take care of everything.
>> I don't think compiler or CPU will reorder calls to a function and
>> updates of a variable.
> I'm not sure about that. I think it is free to do so if it finds
> that there is no dependency that prevents it from reordering. In this
> case the update to the flag has no "visible" dependency on the call
> to post_transition().
>> And so this code might simply work. And
>> I hope there would be plenty of such code in kernel.
> Sure, there are plenty of examples in the kernel where we call functions
> and update variables. But in this particular case, our synchronization
> _depends_ on those operations happening in a particular order. Hence
> we need to ensure the ordering is right. Otherwise the synchronization
> might get broken.

I still don't buy that.. Lets call an expert :)

> Here are some examples where memory barriers are inserted to avoid
> reordering of variable updates and function calls:
> kernel/rcu/torture.c: rcu_torture_barrier_cbs()

rcutorture.c instead.

> kernel/smp.c: kick_all_cpus_sync()

These examples are a bit different than what we have here..

@Catalin: We have a problem here and need your expert advice. After changing
CPU frequency we need to call this code:

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..

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

Powered by blists - more mailing lists