One of us is missing the point (and I'm the newbie so blame me ;-)), so
here goes:
Only the calls from the block layer to the request_fn are serialized by
ide_lock. Not the actual data transfers. Here's the scenario:
Firstly, an I/O request is queued by ide_do_request(), and then it
returns. Let's assume that DMA is now in progress. Once
ide_do_request() returns, the lock is released by the block layer. Now
the corruption scenario: another request can come in for the other
channel while our first I/O is in flight, and since the ide_lock isn't
held, and the second channel isn't BUSY, ide_do_request() will be happy
to try and start an I/O on that channel too. BOOM.
Or is there a dumb mistake in my logic?
Neil
PS: I appreciate that your code is in a transition phase but I think
it's desirable to avoid badly broken 2.5's all the same.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/