Hello Jens!
I came across the below while investigating some other problem.
Something here doesn't seem right. This looks like an obvious bug and
something roughly along the lines of my patch would fix it. But I
must be in the wrong decade to find such a bug in the block layer.
Is this for real? Or if not, what am I missing?
Jörn
--
If __get_request() returns NULL, get_request will call
prepare_to_wait_exclusive() followed by io_schedule(). Not rechecking
the sleep condition after prepare_to_wait_exclusive() leaves a race
where the condition changes before prepare_to_wait_exclusive(), but
not after and accordingly this thread never gets woken up.
The race must be exceedingly hard to hit, otherwise I cannot explain how
such a classic race could outlive the last millenium.
Signed-off-by: Joern Engel <jo...@logfs.org>
---
block/blk-core.c | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/block/blk-core.c b/block/blk-core.c
index 3275353957f0..00aa6c7abe5a 100644
--- a/block/blk-core.c
+++ b/block/blk-core.c
@@ -1068,6 +1068,11 @@ retry:
trace_block_sleeprq(q, bio, rw_flags & 1);
+ rq = __get_request(rl, rw_flags, bio, gfp_mask);
+ if (rq) {
+ finish_wait(&rl->wait[is_sync], &wait);
+ return rq;
+ }
spin_unlock_irq(q->queue_lock);
io_schedule();
--
2.0.0.rc0.1.g7b2ba98
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
