summaryrefslogtreecommitdiff
path: root/include
diff options
context:
space:
mode:
authorNeil Brown <neilb@suse.de>2007-02-08 09:28:28 +1100
committerGreg Kroah-Hartman <gregkh@suse.de>2007-03-09 10:50:20 -0800
commitbf6c995d1541c8513876158a5550799ae7cd39fe (patch)
treed9802a869a4cc102b4617cecae400345a430a127 /include
parentc8d8a5e0f09db90f9ce46edd6c5601335d0f21ff (diff)
md: Avoid possible BUG_ON in md bitmap handling.
md/bitmap tracks how many active write requests are pending on blocks associated with each bit in the bitmap, so that it knows when it can clear the bit (when count hits zero). The counter has 14 bits of space, so if there are ever more than 16383, we cannot cope. Currently the code just calles BUG_ON as "all" drivers have request queue limits much smaller than this. However is seems that some don't. Apparently some multipath configurations can allow more than 16383 concurrent write requests. So, in this unlikely situation, instead of calling BUG_ON we now wait for the count to drop down a bit. This requires a new wait_queue_head, some waiting code, and a wakeup call. Tested by limiting the counter to 20 instead of 16383 (writes go a lot slower in that case...). Signed-off-by: Neil Brown <neilb@suse.de> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de> diff .prev/drivers/md/bitmap.c ./drivers/md/bitmap.c
Diffstat (limited to 'include')
-rw-r--r--include/linux/raid/bitmap.h1
1 files changed, 1 insertions, 0 deletions
diff --git a/include/linux/raid/bitmap.h b/include/linux/raid/bitmap.h
index ebd42a3710b4..6db9a4c15355 100644
--- a/include/linux/raid/bitmap.h
+++ b/include/linux/raid/bitmap.h
@@ -247,6 +247,7 @@ struct bitmap {
atomic_t pending_writes; /* pending writes to the bitmap file */
wait_queue_head_t write_wait;
+ wait_queue_head_t overflow_wait;
};