https://bugzilla.kernel.org/show_bug.cgi?id=200835 --- Comment #9 from Mike Snitzer (snitzer@xxxxxxxxxx) --- (In reply to Mike Snitzer from comment #8) > init_crypt() does the allocation with: > gfp = req->base.flags & CRYPTO_TFM_REQ_MAY_SLEEP ? GFP_KERNEL : > GFP_ATOMIC; > > So another option would be for DM-crypt to _not_ set > CRYPTO_TFM_REQ_MAY_SLEEP in struct skcipher_request *req's base.flags (I > wonder if it defaults to setting it?) > > The crypto code gets opaque quite quickly.. not yet sure where the relevant > dm-crypt code is that would be able to ensure CRYPTO_TFM_REQ_MAY_SLEEP is > _not_ set in skcipher_request req->base.flags drivers/md/dm-crypt.c:crypt_alloc_req_skcipher() is calling skcipher_request_set_callback() with CRYPTO_TFM_REQ_MAY_SLEEP set. But there are quite a few other modes that also set CRYPTO_TFM_REQ_MAY_SLEEP. And most crypto code uses GFP_KERNEL if that is set. In any case, it would seem commit f1c131b45410a ("crypto: xts - Convert to skcipher") is what ushered in the use of GFP_KERNEL underneath dm-crypt's IO path. > In any case, it really does seem to make sense to change xts.c:init_crypt() > to use GDP_NOIO instead of GFP_KERNEL. I still think switching to GFP_NOIO here needs further thought and review by the crypto/XTS developers. -- You are receiving this mail because: You are watching the assignee of the bug.
