Satya Tangirala <satyat@xxxxxxxxxx> wrote: >On Tue, Sep 01, 2020 at 10:15:11PM -0700, Eric Biggers wrote: >> From: Eric Biggers <ebiggers@xxxxxxxxxx> >> >> Callers of bio_clone_fast() may use a gfp_mask that excludes >> GFP_DIRECT_RECLAIM. For example, map_request() uses GFP_ATOMIC. >> >> If this were to happen, the mempool_alloc() in __bio_crypt_clone() can >> fail, causing a NULL dereference. >The call to blk_crypto_rq_bio_prep() from blk_rq_prep_clone() could also fail for the same reason. So we may need to make blk_crypto_rq_bio_prep() also return a bool and handle the errors in the callers (the only other caller is I think blk_mq_bio_to_request(), which explicitly calls the function with GFP_NOIO, so maybe we could explicitly document the fact that blk_mq_bio_to_request will return true when called with a gfp_mask th at includes GFP_DIRECT_RECLAIM, and ignore the return value in blk_mq_bio_to_request()). (And maybe we should document the same for bio_crypt_set_ctx and bio_crypt_clone?) Agreed. Except for above suggestions, the patch looks good for me, many thanks. >> >> In reality map_request() currently never has to clone an encryption -- dm-devel mailing list dm-devel@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/dm-devel
