diff options
| author | NeilBrown <neilb@suse.com> | 2017-12-03 16:21:04 -0500 |
|---|---|---|
| committer | Shaohua Li <shli@fb.com> | 2017-12-11 11:52:34 -0500 |
| commit | 474beb575c03e0e7f1a704ac428916898f81b3cd (patch) | |
| tree | ce5695048133b58a6166df18f40f12e23ce00d78 /drivers/md/raid1.c | |
| parent | d5d885fd514fcebc9da5503c88aa0112df7514ef (diff) | |
md/raid1,raid10: silence warning about wait-within-wait
If you prepare_to_wait() after a previous prepare_to_wait(),
but before calling schedule(), you get warning:
do not call blocking ops when !TASK_RUNNING; state=2
This is appropriate as it is often a bug. The event that the
first prepare_to_wait() expects might wake up the schedule following
the second prepare_to_wait(), which could be confusing.
However if both prepare_to_wait()s are part of simple wait_event()
loops, and if the inner one is rarely called, then there is
no problem. The inner loop is too simple to get confused by
a stray wakeup, and the outer loop won't spin unduly because the
inner doesnt affect it often.
This pattern occurs in both raid1.c and raid10.c in the use of
flush_pending_writes().
The warning can be silenced by setting current->state to TASK_RUNNING.
Signed-off-by: NeilBrown <neilb@suse.com>
Signed-off-by: Shaohua Li <shli@fb.com>
Diffstat (limited to 'drivers/md/raid1.c')
| -rw-r--r-- | drivers/md/raid1.c | 11 |
1 files changed, 11 insertions, 0 deletions
diff --git a/drivers/md/raid1.c b/drivers/md/raid1.c index 6df398e3a008..b2eae332e1a2 100644 --- a/drivers/md/raid1.c +++ b/drivers/md/raid1.c | |||
| @@ -815,6 +815,17 @@ static void flush_pending_writes(struct r1conf *conf) | |||
| 815 | bio = bio_list_get(&conf->pending_bio_list); | 815 | bio = bio_list_get(&conf->pending_bio_list); |
| 816 | conf->pending_count = 0; | 816 | conf->pending_count = 0; |
| 817 | spin_unlock_irq(&conf->device_lock); | 817 | spin_unlock_irq(&conf->device_lock); |
| 818 | |||
| 819 | /* | ||
| 820 | * As this is called in a wait_event() loop (see freeze_array), | ||
| 821 | * current->state might be TASK_UNINTERRUPTIBLE which will | ||
| 822 | * cause a warning when we prepare to wait again. As it is | ||
| 823 | * rare that this path is taken, it is perfectly safe to force | ||
| 824 | * us to go around the wait_event() loop again, so the warning | ||
| 825 | * is a false-positive. Silence the warning by resetting | ||
| 826 | * thread state | ||
| 827 | */ | ||
| 828 | __set_current_state(TASK_RUNNING); | ||
| 818 | blk_start_plug(&plug); | 829 | blk_start_plug(&plug); |
| 819 | flush_bio_list(conf, bio); | 830 | flush_bio_list(conf, bio); |
| 820 | blk_finish_plug(&plug); | 831 | blk_finish_plug(&plug); |
