FLUSH mechanism implementation in block layer

[Tanya Brokhman <tlinder@codeaurora.org>]

Hello Tejun,

I'm writing to you since you're signed on the blk-flush.c file, hoping 
you could answer a flush-related question for me. Please excuse me if 
you're not the right person to address this to.

I've been looking into the flush implementation, trying to understand 
how it works. FLUSH command can be used for two purposes:
1. Flush the data to the non-volatile memory from the card cache
2. Keep an order of requests: req_A.... req_D, FLUSH, req_C...req_X
Unfortunately I don't understand how the second purpose of FLUSH is 
implemented. If to simplify the question, let take for example a card 
that doesn't implement a writeback cache (doesn't support FLUSH/FUA) and 
the following example:

The application inserts req_A...req_D to the block layer (and the 
scheduler) and issues req_FLUSH that contains data. What is expected in 
this situation is that req_A..req_D will be written to the non-volatile 
memory before req_FLUSH.
According to the code at blk_insert_flush() the req_FLUSH request will 
be marked as SOFTBARRIER and added to the tail of the dispatch queue.
But what guaranties that by the time it's added to the dispatch queue 
req_A..req_D have been dispatched as well? It's possible that they are 
still in scheduler and will be dispatched only after req_FLUSH is 
completed...

One possible solution to this is if the application waits to get a 
completion callback on req_A..req_D before issuing the req_FLUSH. Is 
this indeed the case? I didn't find any documentation on it on the web.

Thanks,
Tanya Brokhman

-- 
QUALCOMM ISRAEL, on behalf of Qualcomm Innovation Center, Inc. is a 
member of Code Aurora Forum, hosted by The Linux Foundation