Merge tag 'md/3.19-fixes' of git://neil.brown.name/md

Pull two fixes for md from Neil Brown: - Another live lock, needs backporting - work-around false positive with new warnings. * tag 'md/3.19-fixes' of git://neil.brown.name/md: md/bitmap: fix a might_sleep() warning. md/raid5: fix another livelock caused by non-aligned writes.

Merge tag 'md/3.19-fixes' of git://neil.brown.name/md
Pull two fixes for md from Neil Brown: - Another live lock, needs backporting - work-around false positive with new warnings. * tag 'md/3.19-fixes' of git://neil.brown.name/md: md/bitmap: fix a might_sleep() warning. md/raid5: fix another livelock caused by non-aligned writes.
Linus Torvalds
2 parents 0f98c38d72 d959014334
Showing 2 changed files Side-by-side Diff
drivers/md/bitmap.c
drivers/md/raid5.c
@@ -72,6 +72,19 @@
 	/* this page has not been allocated yet */
  
 	spin_unlock_irq(&bitmap->lock);
+	/* It is possible that this is being called inside a
+	 * prepare_to_wait/finish_wait loop from raid5c:make_request().
+	 * In general it is not permitted to sleep in that context as it
+	 * can cause the loop to spin freely.
+	 * That doesn't apply here as we can only reach this point
+	 * once with any loop.
+	 * When this function completes, either bp[page].map or
+	 * bp[page].hijacked.  In either case, this function will
+	 * abort before getting to this point again.  So there is
+	 * no risk of a free-spin, and so it is safe to assert
+	 * that sleeping here is allowed.
+	 */
+	sched_annotate_sleep();
 	mappage = kzalloc(PAGE_SIZE, GFP_NOIO);
 	spin_lock_irq(&bitmap->lock);
  
@@ -3195,6 +3195,11 @@
 					  (unsigned long long)sh->sector,
 					  rcw, qread, test_bit(STRIPE_DELAYED, &sh->state));
 	}
+
+	if (rcw > disks && rmw > disks &&
+	    !test_bit(STRIPE_PREREAD_ACTIVE, &sh->state))
+		set_bit(STRIPE_DELAYED, &sh->state);
+
 	/* now if nothing is locked, and if we have enough data,
 	 * we can start a write request
 	 */
...	...	@@ -72,6 +72,19 @@
72	72	/* this page has not been allocated yet */
73	73
74	74	spin_unlock_irq(&bitmap->lock);
	75	+ /* It is possible that this is being called inside a
	76	+ * prepare_to_wait/finish_wait loop from raid5c:make_request().
	77	+ * In general it is not permitted to sleep in that context as it
	78	+ * can cause the loop to spin freely.
	79	+ * That doesn't apply here as we can only reach this point
	80	+ * once with any loop.
	81	+ * When this function completes, either bp[page].map or
	82	+ * bp[page].hijacked. In either case, this function will
	83	+ * abort before getting to this point again. So there is
	84	+ * no risk of a free-spin, and so it is safe to assert
	85	+ * that sleeping here is allowed.
	86	+ */
	87	+ sched_annotate_sleep();
75	88	mappage = kzalloc(PAGE_SIZE, GFP_NOIO);
76	89	spin_lock_irq(&bitmap->lock);
77	90
...	...	@@ -3195,6 +3195,11 @@
3195	3195	(unsigned long long)sh->sector,
3196	3196	rcw, qread, test_bit(STRIPE_DELAYED, &sh->state));
3197	3197	}
	3198	+
	3199	+ if (rcw > disks && rmw > disks &&
	3200	+ !test_bit(STRIPE_PREREAD_ACTIVE, &sh->state))
	3201	+ set_bit(STRIPE_DELAYED, &sh->state);
	3202	+
3198	3203	/* now if nothing is locked, and if we have enough data,
3199	3204	* we can start a write request
3200	3205	*/