Re: [Drbd-dev] FLUSH/FUA documentation & code discrepancy

[Joseph Glanville <joseph.glanville@orionvm.com.au>]

On 13 September 2012 09:53, Joseph Glanville
<joseph.glanville@orionvm.com.au> wrote:
> On 13 September 2012 09:20, Tejun Heo <tj@kernel.org> wrote:
>> On Thu, Sep 13, 2012 at 09:12:25AM +1000, Joseph Glanville wrote:
>>> diff --git a/block/blk-core.c b/block/blk-core.c
>>> index 4b4dbdf..68b5671 100644
>>> --- a/block/blk-core.c
>>> +++ b/block/blk-core.c
>>> @@ -1809,6 +1809,9 @@ EXPORT_SYMBOL(generic_make_request);
>>>   * uses that function to do most of the work. Both are fairly rough
>>>   * interfaces; @bio must be presetup and ready for I/O.
>>>   *
>>> + * Ordering of requests is not guaranteed, callers should drain the queue
>>> + * and issue a flush before submission of any dependent bios.
>>
>> I think using "requests" here is confusing given that struct request
>> means something else in the block layer.  Also, the caller doesn't
>
> Agreed, my bad.
>
>> have to drain the whole queue but just the ones involved in the
>> dependency and flush doesn't really matter here although mentioning
>> that flush too doesn't have any ordering guarantee would be nice.
>
> Will do.
> Would you prefer it being added to the top of the file describing the
> semantics or the blkdev_issue_flush function itself?
>
>> Also, updating submit_bio() comment too would be nice - something
>> simple about lack of ordering and then reference to
>> generic_make_request().
>
> Will do.
>
>>
>> Thanks.
>>
>> --
>> tejun
>> --
>> 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/
>
>
>
> --
> CTO | Orion Virtualisation Solutions | www.orionvm.com.au
> Phone: 1300 56 99 52 | Mobile: 0428 754 846

diff --git a/block/blk-core.c b/block/blk-core.c
index 4b4dbdf..b3559d8 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)

-- 
CTO | Orion Virtualisation Solutions | www.orionvm.com.au
Phone: 1300 56 99 52 | Mobile: 0428 754 846