diff options
author | Guoqing Jiang <gqjiang@suse.com> | 2016-05-03 22:22:13 -0400 |
---|---|---|
committer | Shaohua Li <shli@fb.com> | 2016-05-09 09:24:02 -0700 |
commit | 85ad1d13ee9b3db00615ea24b031c15e5ba14fd1 (patch) | |
tree | ff8cd0a32ae44fa7d306cee622c9eea96a9de076 /drivers/md/bitmap.c | |
parent | fe67d19a2d7b31f1c29efbe1819c921d4a9bb012 (diff) | |
download | op-kernel-dev-85ad1d13ee9b3db00615ea24b031c15e5ba14fd1.zip op-kernel-dev-85ad1d13ee9b3db00615ea24b031c15e5ba14fd1.tar.gz |
md: set MD_CHANGE_PENDING in a atomic region
Some code waits for a metadata update by:
1. flagging that it is needed (MD_CHANGE_DEVS or MD_CHANGE_CLEAN)
2. setting MD_CHANGE_PENDING and waking the management thread
3. waiting for MD_CHANGE_PENDING to be cleared
If the first two are done without locking, the code in md_update_sb()
which checks if it needs to repeat might test if an update is needed
before step 1, then clear MD_CHANGE_PENDING after step 2, resulting
in the wait returning early.
So make sure all places that set MD_CHANGE_PENDING are atomicial, and
bit_clear_unless (suggested by Neil) is introduced for the purpose.
Cc: Martin Kepplinger <martink@posteo.de>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Denys Vlasenko <dvlasenk@redhat.com>
Cc: Sasha Levin <sasha.levin@oracle.com>
Cc: <linux-kernel@vger.kernel.org>
Reviewed-by: NeilBrown <neilb@suse.com>
Signed-off-by: Guoqing Jiang <gqjiang@suse.com>
Signed-off-by: Shaohua Li <shli@fb.com>
Diffstat (limited to 'drivers/md/bitmap.c')
0 files changed, 0 insertions, 0 deletions