evie/android_kernel_oneplus_msm8998
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions

md/bitmap: fix a might_sleep() warning.

Browse source 
commit 8eb23b9f35
    sched: Debug nested sleeps

causes false-positive warnings in RAID5 code.

This annotation removes them and adds a comment
explaining why there is no real problem.

Reported-by: Fengguang Wu <fengguang.wu@intel.com>
Signed-off-by: NeilBrown <neilb@suse.de>
This commit is contained in:
NeilBrown 2015-02-02 17:08:03 +11:00
parent b1b02fe97f
commit d959014334
1 changed files with 13 additions and 0 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

13
drivers/md/bitmap.c
View file

@ -72,6 +72,19 @@ __acquires(bitmap->lock)
/* this page has not been allocated yet */ /* this page has not been allocated yet */
spin_unlock_irq(&bitmap->lock); spin_unlock_irq(&bitmap->lock);
/* It is possible that this is being called inside a
* prepare_to_wait/finish_wait loop from raid5c:make_request().
* In general it is not permitted to sleep in that context as it
* can cause the loop to spin freely.
* That doesn't apply here as we can only reach this point
* once with any loop.
* When this function completes, either bp[page].map or
* bp[page].hijacked. In either case, this function will
* abort before getting to this point again. So there is
* no risk of a free-spin, and so it is safe to assert
* that sleeping here is allowed.
*/
sched_annotate_sleep();
mappage = kzalloc(PAGE_SIZE, GFP_NOIO); mappage = kzalloc(PAGE_SIZE, GFP_NOIO);
spin_lock_irq(&bitmap->lock); spin_lock_irq(&bitmap->lock);