diff options
| author | Eric Biggers <ebiggers@google.com> | 2020-09-16 05:53:14 +0200 |
|---|---|---|
| committer | Jens Axboe <axboe@kernel.dk> | 2020-10-05 18:47:43 +0200 |
| commit | 93f221ae08381e994ac9f9ff6aa743e612e49718 (patch) | |
| tree | fe3f7bb6254559fb0d7a84fc467389a5af30c821 /security | |
| parent | block: make bio_crypt_clone() able to fail (diff) | |
| download | linux-93f221ae08381e994ac9f9ff6aa743e612e49718.tar.xz linux-93f221ae08381e994ac9f9ff6aa743e612e49718.zip | |
block: make blk_crypto_rq_bio_prep() able to fail
blk_crypto_rq_bio_prep() assumes its gfp_mask argument always includes
__GFP_DIRECT_RECLAIM, so that the mempool_alloc() will always succeed.
However, blk_crypto_rq_bio_prep() might be called with GFP_ATOMIC via
setup_clone() in drivers/md/dm-rq.c.
This case isn't currently reachable with a bio that actually has an
encryption context. However, it's fragile to rely on this. Just make
blk_crypto_rq_bio_prep() able to fail.
Suggested-by: Satya Tangirala <satyat@google.com>
Signed-off-by: Eric Biggers <ebiggers@google.com>
Reviewed-by: Mike Snitzer <snitzer@redhat.com>
Reviewed-by: Satya Tangirala <satyat@google.com>
Cc: Miaohe Lin <linmiaohe@huawei.com>
Signed-off-by: Jens Axboe <axboe@kernel.dk>
Diffstat (limited to 'security')
0 files changed, 0 insertions, 0 deletions