linux-kernel - Re: [RFC PATCHC 2/3] idle: store the idle state the cpu is

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: <534D3F80.9010902@linaro.org>
Date:	Tue, 15 Apr 2014 16:17:36 +0200
From:	Daniel Lezcano <daniel.lezcano@...aro.org>
To:	Peter Zijlstra <peterz@...radead.org>
CC:	linux-kernel@...r.kernel.org, mingo@...e.hu, rjw@...ysocki.net,
	nicolas.pitre@...aro.org, linux-pm@...r.kernel.org,
	alex.shi@...aro.org, vincent.guittot@...aro.org,
	morten.rasmussen@....com
Subject: Re: [RFC PATCHC 2/3] idle: store the idle state the cpu is

On 04/15/2014 02:44 PM, Peter Zijlstra wrote:
> On Tue, Apr 15, 2014 at 02:43:30PM +0200, Peter Zijlstra wrote:
>> On Fri, Mar 28, 2014 at 01:29:55PM +0100, Daniel Lezcano wrote:
>>> @@ -143,6 +145,10 @@ static int cpuidle_idle_call(void)
>>>   			if (!ret) {
>>>   				trace_cpu_idle_rcuidle(next_state, dev->cpu);
>>>
>>> +				*power = &drv->states[next_state].power;
>>> +
>>> +				wmb();
>>> +
>>
>> I very much suspect you meant: smp_wmb(), as I don't see the hardware
>> reading that pointer, therefore UP wouldn't care. Also, any and all
>> barriers should come with a comment that describes the data ordering and
>> points to the matchin barriers.
>
> Furthermore, this patch fails to describe the life-time rules of the
> object placed there. Can the objected pointed to ever disappear?

Hi Peter,

thanks for reviewing the patches.

There are a couple of situations where a cpuidle state can disappear:

1. For x86/acpi with dynamic c-states, when a laptop switches from 
battery to AC that could result on removing the deeper idle state. The 
acpi driver triggers:

'acpi_processor_cst_has_changed' which will call 
'cpuidle_pause_and_lock'. This one will call 
'cpuidle_uninstall_idle_handler' which in turn calls 'kick_all_cpus_sync'.

All cpus will exit their idle state and the pointed object will be set 
to NULL again.

2. The cpuidle driver is unloaded. Logically that could happen but not 
in practice because the drivers are always compiled in and 95% of the 
drivers are not coded to unregister the driver. Anyway ...

The unloading code must call 'cpuidle_unregister_device', that calls 
'cpuidle_pause_and_lock' leading to 'kick_all_cpus_sync'.

IIUC, the race can happen if we take the pointer and then one of these 
two situation occurs at the same moment.

As the function 'find_idlest_cpu' is inside a rcu_read_lock may be a 
rcu_barrier in 'cpuidle_pause_and_lock' or 
'cpuidle_uninstall_idle_handler' should suffice, no ?

Thanks

   -- Daniel

-- 
  <http://www.linaro.org/> Linaro.org │ Open source software for ARM SoCs

Follow Linaro:  <http://www.facebook.com/pages/Linaro> Facebook |
<http://twitter.com/#!/linaroorg> Twitter |
<http://www.linaro.org/linaro-blog/> Blog

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