summaryrefslogtreecommitdiffstats
path: root/drivers/i2c/i2c-core.c
diff options
context:
space:
mode:
authorNeilBrown <neilb@suse.de>2014-12-11 10:02:10 +1100
committerNeilBrown <neilb@suse.de>2014-12-11 10:02:10 +1100
commitf851b60db0fd83a10034c5cc9d9e58c758457b1c (patch)
treed357ab883cb0d0f80830350587901073783e5bfe /drivers/i2c/i2c-core.c
parent7d7e64f2ecd4a863b5fbc1fe998bb39d6423664a (diff)
downloadop-kernel-dev-f851b60db0fd83a10034c5cc9d9e58c758457b1c.zip
op-kernel-dev-f851b60db0fd83a10034c5cc9d9e58c758457b1c.tar.gz
md: Check MD_RECOVERY_RUNNING as well as ->sync_thread.
A recent change to md started the ->sync_thread from a asynchronously from a work_queue rather than synchronously. This means that there can be a small window between the time when MD_RECOVERY_RUNNING is set and when ->sync_thread is set. So code that checks ->sync_thread might now conclude that the thread has not been started and (because a lock is held) will not be started. That is no longer the case. Most of those places are best fixed by testing MD_RECOVERY_RUNNING as well. To make this completely reliable, we wake_up(&resync_wait) after clearing that flag as well as after clearing ->sync_thread. Other places are better served by flushing the relevant workqueue to ensure that that if the sync thread was starting, it has now started. This is particularly best if we are about to stop the sync thread. Fixes: ac05f256691fe427a3e84c19261adb0b67dd73c0 Signed-off-by: NeilBrown <neilb@suse.de>
Diffstat (limited to 'drivers/i2c/i2c-core.c')
0 files changed, 0 insertions, 0 deletions
OpenPOWER on IntegriCloud