linux/drivers/block/drbd/drbd_bitmap.c, branch v3.0.82

drbd: account bitmap IO during resync as resync-(related-)-io

2011-06-30T07:23:43Z

If we have a good resync rate, we will frequently update the on-disk bitmap, which, if not accounted for as resync io, may let an otherwise idle device appear to be "busy", and cause us to throttle resync. Signed-off-by: Philipp Reisner Signed-off-by: Lars Ellenberg

drbd: don't cond_resched_lock with IRQs disabled

2011-06-30T07:23:42Z

The last commit, drbd: add missing spinlock to bitmap receive, introduced a cond_resched_lock(), where the lock in question is taken with irqs disabled. As we must not schedule with IRQs disabled, and cond_resched_lock_irq() does not exist, yet, we re-aquire the spin_lock_irq() for each bitmap page processed in turn. Signed-off-by: Philipp Reisner Signed-off-by: Lars Ellenberg

drbd: add missing spinlock to bitmap receive

2011-06-30T07:23:41Z

During bitmap exchange, when using the RLE bitmap compression scheme, we have a code path that can set the whole bitmap at once. To avoid holding spin_lock_irq() for too long, we used to lock out other bitmap modifications during bitmap exchange by other means, and then, knowing we have exclusive access to the bitmap, modify it without the spinlock, and with IRQs enabled. Since we now allow local IO to continue, potentially setting additional bits during the bitmap receive phase, this is no longer true, and we get uncoordinated updates of bitmap members, causing bm_set to no longer accurately reflect the total number of set bits. To actually see this, you'd need to have a large bitmap, use RLE bitmap compression, and have busy IO during sync handshake and bitmap exchange. Fix this by taking the spin_lock_irq() in this code path as well, but calling cond_resched_lock() after each page worth of bits processed. Signed-off-by: Philipp Reisner Signed-off-by: Lars Ellenberg

drbd: Fix spelling

2011-05-24T08:21:29Z

Found these with the help of ispell -l. Signed-off-by: Bart Van Assche Signed-off-by: Lars Ellenberg Signed-off-by: Philipp Reisner

drbd: fix up merge error

2011-03-28T14:42:58Z

In commit 95a0f10cddbf ("drbd: store in-core bitmap little endian, regardless of architecture") drbd had made the sane choice to use little-endian bitmap functions everywhere. However, it used the horrible old functions names from , that were never really meant to be exported. In the meantime, things got cleaned up, and in commit c4945b9ed472 ("asm-generic: rename generic little-endian bitops functions") we renamed the LE bitops to something sane, exactly so that they could be used in random code without people gouging their eyes out when seeing the crazy jumble of letters that were the old internal names. As a result the drbd thing merged cleanly (commit 8d49a77568d1: "Merge branch 'for-2.6.39/drivers' of git://git.kernel.dk/linux-2.6-block"), since there was no data conflict - but the end result obviously doesn't actually compile. Reported-and-tested-by: Ingo Molnar Cc: Jens Axboe Cc: Stephen Rothwell Signed-off-by: Linus Torvalds

drbd: need include for bitops functions declarations

2011-03-17T14:02:51Z

Signed-off-by: Stephen Rothwell Signed-off-by: Jens Axboe

drbd: describe bitmap locking for bulk operation in finer detail

2011-03-10T10:48:02Z

Now that we do no longer in-place endian-swap the bitmap, we allow selected bitmap operations (testing bits, sometimes even settting bits) during some bulk operations. This caused us to hit a lot of FIXME asserts similar to FIXME asender in drbd_bm_count_bits, bitmap locked for 'write from resync_finished' by worker Which now is nonsense: looking at the bitmap is perfectly legal as long as it is not being resized. This cosmetic patch defines some flags to describe expectations in finer detail, so the asserts in e.g. bm_change_bits_to() can be skipped if appropriate. Signed-off-by: Philipp Reisner Signed-off-by: Lars Ellenberg

drbd: fix potential access of on-stack wait_queue_head_t after return

2011-03-10T10:45:08Z

I run into something declaring itself as "spinlock deadlock", BUG: spinlock lockup on CPU#1, kjournald/27816, ffff88000ad6bca0 Pid: 27816, comm: kjournald Tainted: G W 2.6.34.6 #2 Call Trace: [] do_raw_spin_lock+0x11e/0x14d [] _raw_spin_lock_irqsave+0x6a/0x81 [] ? __wake_up+0x22/0x50 [] __wake_up+0x22/0x50 [] bm_async_io_complete+0x258/0x299 [drbd] but the call traces do not fit at all, all other cpus are cpu_idle. I think it may be this race: drbd_bm_write_page wait_queue_head_t io_wait; atomic_t in_flight; bm_async_io submit_bio bm_async_io_complete if (atomic_dec_and_test(in_flight)) wait_event(io_wait, atomic_read(in_flight) == 0) return wake_up(io_wait) The wake_up now accesses the wait_queue_head_t spinlock, which is no longer valid, since the stack frame of drbd_bm_write_page has been clobbered now. Fix this by using struct completion, which does both the condition test as well as the wake_up inside its spinlock, so this race cannot happen. Signed-off-by: Philipp Reisner Signed-off-by: Lars Ellenberg

drbd: be less noisy with some log messages

2011-03-10T10:43:37Z

We expect changes to a bitmap page in drbd_bm_write_page, that's why we submit a copy page. If a page changes during global writeout, that would be unexpected, and reason to warn, though. Also, often page writeout can be skipped (on activity log transactions during normal operation, for example), no need to log that everytime. Signed-off-by: Philipp Reisner Signed-off-by: Lars Ellenberg

drbd: Removed a reference to debug macros removed long time ago

2011-03-10T10:43:27Z

Signed-off-by: Philipp Reisner Signed-off-by: Lars Ellenberg