On 03/14/2018 05:23 PM, Coly Li wrote:
On 14/03/2018 4:08 PM, Lidong Zhong wrote:
I don't think it could cause any lock contention without this fix.
But as the comment said, it could bring optimisation when the array
is in frozen state.
Signed-off-by: Lidong Zhong <lzhong@xxxxxxxx>
Fix: 824e47daddbf(RAID1: avoid unnecessary spin locks in I/O barrier code)
---
drivers/md/raid1.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/md/raid1.c b/drivers/md/raid1.c
index fe872dc6712e..3d7edffaf85b 100644
--- a/drivers/md/raid1.c
+++ b/drivers/md/raid1.c
@@ -935,7 +935,7 @@ static void _wait_barrier(struct r1conf *conf, int idx)
* or be queued, no race will happen. See code comment in
* frozen_array().
*/
- if (!READ_ONCE(conf->array_frozen) &&
+ if (READ_ONCE(conf->array_frozen) &&
!atomic_read(&conf->barrier[idx]))
return;
Hi Lidong,
How do you think your change fixes a bug ? ^_^
Hi Coly,
I probably misunderstood the comments about the array is frozen and no
sync IO is undergoing. I will give an update after I do more tests.
Thanks,
Lidong
Coly Li
--
To unsubscribe from this list: send the line "unsubscribe linux-raid" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe linux-raid" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
