Thread (13 messages) 13 messages, 2 authors, 2012-06-21

Re: [patch 5/9 v2] raid5: reduce chance release_stripe() taking device_lock

From: Shaohua Li <shli@kernel.org>
Date: 2012-06-21 01:34:36

On Wed, Jun 20, 2012 at 05:56:25PM -0700, Dan Williams wrote:
On Mon, Jun 18, 2012 at 6:59 PM, Shaohua Li [off-list ref] wrote:
quoted
release_stripe() is a place conf->device_lock is heavily contended. We take the
lock even stripe count isn't 1, which isn't required. On the on the other hand,
decreasing count first and taking lock if count is 0 can expose races:
1. bewteen dec count and taking lock, another thread hits the stripe in cache,
so increase count. The stripe will be deleted from any list. In this case
stripe count isn't 0.
2. between dec count and taking lock, another thread hits the stripe in cache
and release it. In this case the stripe is already in specific list. We do
list_move to adjust its position.
So both cases are fixable to me.
These "1" and "2" comments no longer apply right?  atomic_dec_and_lock
is equivalently safe to lock+dec_and_test.
Oh, I misunderstand atomic_dec_and_lock is dec and lock instead of lock and
dec, so there is no race. The other two deletion isn't required too. I'll
repost this patch.

Thanks,
Shaohua
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help