PM / Wakeup: Combine atomic counters to avoid reordering issues
authorRafael J. Wysocki <rjw@sisk.pl>
Mon, 31 Jan 2011 10:06:39 +0000 (11:06 +0100)
committerRafael J. Wysocki <rjw@sisk.pl>
Mon, 14 Mar 2011 23:43:13 +0000 (00:43 +0100)
commit023d3779145ec6b7a0f38f19672a347b92feb74e
tree1ec78dc731dad2b8155faf6625617284f1b3b76d
parentdc1b83ab08f1954335692cdcd499f78c94f4c42a
PM / Wakeup: Combine atomic counters to avoid reordering issues

The memory barrier in wakeup_source_deactivate() is supposed to
prevent the callers of pm_wakeup_pending() and pm_get_wakeup_count()
from seeing the new value of events_in_progress (0, in particular)
and the old value of event_count at the same time.  However, if
wakeup_source_deactivate() is executed by CPU0 and, for instance,
pm_wakeup_pending() is executed by CPU1, where both processors can
reorder operations, the memory barrier in wakeup_source_deactivate()
doesn't affect CPU1 which can reorder reads.  In that case CPU1 may
very well decide to fetch event_count before it's modified and
events_in_progress after it's been updated, so pm_wakeup_pending()
may fail to detect a wakeup event.  This issue can be addressed by
using a single atomic variable to store both events_in_progress
and event_count, so that they can be updated together in a single
atomic operation.

Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
drivers/base/power/wakeup.c