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
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