Linus et-al,
Russell Coker reported to linux-kernel that raid1 would lock up for
him when running bonnie++ - thanks Russell.
I managed to reproduce this and, at least for me, it is caused by a
deadlock when kflushd tries to write out data via raid1, raid1 tries
to allocate memory, which blocks waiting for kflushd to free up some
memory.
The structure is in place to avoid this deadlock, it just didn't work
properly because I hadn't made the effort to understand the different
flavours for GFP_*.
The following patch uses GFP_ATOMIC at the appropriate times so that
raid1 won't block waiting for kflushd. It will instead block waiting
for some other raid1 request to complete and release it's memory.
Russell : could you check if this fixes your problem please?
Other people reported similar problems with raid0 and raid5. This
patch does not address them. (I haven't found them yet, but then I
haven't looked).
NeilBrown
--- ./drivers/block/raid1.c 2000/07/18 02:00:54 1.1
+++ ./drivers/block/raid1.c 2000/07/18 02:02:36
@@ -75,7 +75,7 @@
md_spin_unlock_irq(&conf->device_lock);
if (cnt == 0)
break;
- t = (struct buffer_head *)kmalloc(sizeof(struct buffer_head),
GFP_KERNEL);
+ t = (struct buffer_head *)kmalloc(sizeof(struct buffer_head),
+GFP_ATOMIC);
if (t) {
memset(t, 0, sizeof(*t));
t->b_next = bh;
@@ -165,7 +165,7 @@
if (r1_bh)
return r1_bh;
r1_bh = (struct raid1_bh *) kmalloc(sizeof(struct raid1_bh),
- GFP_KERNEL);
+ GFP_ATOMIC);
if (r1_bh) {
memset(r1_bh, 0, sizeof(*r1_bh));
return r1_bh;
