Re: [PATCH] sched/idle: Make forced polling state race-safe

[Hui Su]

> This is about cpu_idle_poll_ctr(), right? Is there any actual
> concurrency on that thing? Afaict there is just init time twiddling
> there.

Yes, cpu_idle_poll_ctrl(). There is an in-tree reader/writer path during
system suspend. OMAP4 calls omap_common_suspend_init(omap4_pm_suspend),
which installs omap_pm_ops; its .begin callback, omap_pm_begin(), calls
cpu_idle_poll_ctrl(true).

platform_suspend_begin() invokes that callback from
suspend_devices_and_enter() before suspend_enter() calls
pm_sleep_disable_secondary_cpus(). A secondary CPU can therefore still
be in do_idle() and read cpu_idle_force_poll while the suspend CPU updates
it.

I haven't found an in-tree pair of concurrent cpu_idle_poll_ctrl()
writers. The two-worker stress test exercised the counter's behavior with
concurrent writers; it does not establish an in-tree caller pair.

If cpu_idle_poll_ctrl() writers are expected to be serialized, I can
rework the patch around the actual reader/writer concurrency instead.

Thanks,
Hui