On Tue, Apr 28, 2020 at 02:54:00AM +0000, Satya Tangirala wrote: > It's modified by additions in the next patch in the series and I > thought I should introduce the function with the final type from the > get go - is that alright? It is probably ok, let me review the next patch in more detail. > > > __blk_queue_split(q, &bio, &nr_segs); > > > @@ -2011,6 +2015,15 @@ static blk_qc_t blk_mq_make_request(struct request_queue *q, struct bio *bio) > > > > > > blk_mq_bio_to_request(rq, bio, nr_segs); > > > > > > + ret = blk_crypto_init_request(rq); > > > + if (ret != BLK_STS_OK) { > > > + bio->bi_status = ret; > > > + bio_endio(bio); > > > + blk_mq_free_request(rq); > > > + return BLK_QC_T_NONE; > > > + } > > > > Didn't Eric have a comment last round that we shoul dtry this before > > attaching the bio to simplify error handling? > > > In the previous round, I believe Eric commented that I should call > blk_crypto_init_request after bio_to_request so that we can do away > with some of the arguments to blk_crypto_init_request and also a > boilerplate function used only while calling blk_crypto_init_request. > I realize you wrote "And we can fail just the request on an error, so > yes this doesn't seem too bad." in response to this particular > comment of Eric's, and it seems I might not actually have understood > what that meant - did you have something in mind different from what I'm > doing here? No, this looks ok, sorry for the noise.