From: Joseph Glanville <joseph.glanvi...@orionvm.com.au>
It is worth noting here that the block layer makes no attempt
to preserve the order of requests and that upper layers like
journaling filesystems that require such ordering need to do so
explicity.
Signed-off-by: Joseph Glanville <joseph.glanvi...@orionvm.com.au>
---
block/blk-core.c | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/block/blk-core.c b/block/blk-core.c
index 4b4dbdf..14b8be6 100644
--- a/block/blk-core.c
+++ b/block/blk-core.c
@@ -1749,6 +1749,11 @@ end_io:
* bio happens to be merged with someone else, and may resubmit the bio to
* a lower device by calling into generic_make_request recursively, which
* means the bio should NOT be touched after the call to ->make_request_fn.
+ *
+ * Ordering is not guaranteed, callers of generic_make_request()
+ * that require ordering should ensure dependencies are first drained
+ * before submission of dependent bios.
+ *
*/
void generic_make_request(struct bio *bio)
{
@@ -1808,6 +1813,7 @@ EXPORT_SYMBOL(generic_make_request);
* submit_bio() is very similar in purpose to generic_make_request(), and
* uses that function to do most of the work. Both are fairly rough
* interfaces; @bio must be presetup and ready for I/O.
+ * Note: submit_bio() doesn't ensure ordering, see generic_make_request()
*
*/
void submit_bio(int rw, struct bio *bio)
--
1.7.12
--
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/
