On Wed, Feb 12, 2020 at 02:00:10PM -0700, Andrzej Jakowski wrote: > On 2/11/20 2:13 PM, Keith Busch wrote: > > I must be missing something: md's make_request_fn always returns > > BLK_QC_T_NONE for the cookie, and that couldn't get past blk_poll's > > blk_qc_t_valid(cookie) check. How does the initial blk_poll() caller get > > a valid cookie for an md backing device's request_queue? And how is the > > same cookie valid for more than one request_queue? > > That's true md_make_request() always returns BLK_QC_T_NONE. md_make_request() > recursively calls generic_make_request() for the underlying device (e.g. nvme). > That block io request directed to member disk is added into bio_list and is > processed later by top level generic_make_request(). generic_make_request() > returns cookie that is returned by blk_mq_make_request(). > That cookie is later used to poll for completion. Okay, that's a nice subtlety. But it means the original caller gets the cookie from the last submission in the chain. If md recieves a single request that has to be split among more than one member disk, the cookie you're using to control the polling is valid only for one of the request_queue's and may break others.
