* [PATCH v2 1/3] block: make bio_crypt_clone() able to fail
2020-09-16 3:53 [PATCH v2 0/3] block: fix up bio_crypt_ctx allocation Eric Biggers
@ 2020-09-16 3:53 ` Eric Biggers
2020-09-17 22:17 ` Satya Tangirala
2020-09-24 0:56 ` Mike Snitzer
2020-09-16 3:53 ` [PATCH v2 2/3] block: make blk_crypto_rq_bio_prep() " Eric Biggers
` (3 subsequent siblings)
4 siblings, 2 replies; 12+ messages in thread
From: Eric Biggers @ 2020-09-16 3:53 UTC (permalink / raw)
To: linux-block, Jens Axboe; +Cc: dm-devel, Satya Tangirala, Miaohe Lin
From: Eric Biggers <ebiggers@google.com>
bio_crypt_clone() assumes its gfp_mask argument always includes
__GFP_DIRECT_RECLAIM, so that the mempool_alloc() will always succeed.
However, bio_crypt_clone() might be called with GFP_ATOMIC via
setup_clone() in drivers/md/dm-rq.c, or with GFP_NOWAIT via
kcryptd_io_read() in drivers/md/dm-crypt.c.
Neither case is currently reachable with a bio that actually has an
encryption context. However, it's fragile to rely on this. Just make
bio_crypt_clone() able to fail, analogous to bio_integrity_clone().
Reported-by: Miaohe Lin <linmiaohe@huawei.com>
Cc: Satya Tangirala <satyat@google.com>
Signed-off-by: Eric Biggers <ebiggers@google.com>
---
block/bio.c | 20 +++++++++-----------
block/blk-crypto.c | 5 ++++-
block/bounce.c | 19 +++++++++----------
drivers/md/dm.c | 7 ++++---
include/linux/blk-crypto.h | 20 ++++++++++++++++----
5 files changed, 42 insertions(+), 29 deletions(-)
diff --git a/block/bio.c b/block/bio.c
index a9931f23d9332..b42e046b12eb3 100644
--- a/block/bio.c
+++ b/block/bio.c
@@ -713,20 +713,18 @@ struct bio *bio_clone_fast(struct bio *bio, gfp_t gfp_mask, struct bio_set *bs)
__bio_clone_fast(b, bio);
- bio_crypt_clone(b, bio, gfp_mask);
+ if (bio_crypt_clone(b, bio, gfp_mask) < 0)
+ goto err_put;
- if (bio_integrity(bio)) {
- int ret;
-
- ret = bio_integrity_clone(b, bio, gfp_mask);
-
- if (ret < 0) {
- bio_put(b);
- return NULL;
- }
- }
+ if (bio_integrity(bio) &&
+ bio_integrity_clone(b, bio, gfp_mask) < 0)
+ goto err_put;
return b;
+
+err_put:
+ bio_put(b);
+ return NULL;
}
EXPORT_SYMBOL(bio_clone_fast);
diff --git a/block/blk-crypto.c b/block/blk-crypto.c
index 2d5e60023b08b..a3f27a19067c9 100644
--- a/block/blk-crypto.c
+++ b/block/blk-crypto.c
@@ -95,10 +95,13 @@ void __bio_crypt_free_ctx(struct bio *bio)
bio->bi_crypt_context = NULL;
}
-void __bio_crypt_clone(struct bio *dst, struct bio *src, gfp_t gfp_mask)
+int __bio_crypt_clone(struct bio *dst, struct bio *src, gfp_t gfp_mask)
{
dst->bi_crypt_context = mempool_alloc(bio_crypt_ctx_pool, gfp_mask);
+ if (!dst->bi_crypt_context)
+ return -ENOMEM;
*dst->bi_crypt_context = *src->bi_crypt_context;
+ return 0;
}
EXPORT_SYMBOL_GPL(__bio_crypt_clone);
diff --git a/block/bounce.c b/block/bounce.c
index 431be88a02405..162a6eee89996 100644
--- a/block/bounce.c
+++ b/block/bounce.c
@@ -267,22 +267,21 @@ static struct bio *bounce_clone_bio(struct bio *bio_src, gfp_t gfp_mask,
break;
}
- bio_crypt_clone(bio, bio_src, gfp_mask);
+ if (bio_crypt_clone(bio, bio_src, gfp_mask) < 0)
+ goto err_put;
- if (bio_integrity(bio_src)) {
- int ret;
-
- ret = bio_integrity_clone(bio, bio_src, gfp_mask);
- if (ret < 0) {
- bio_put(bio);
- return NULL;
- }
- }
+ if (bio_integrity(bio_src) &&
+ bio_integrity_clone(bio, bio_src, gfp_mask) < 0)
+ goto err_put;
bio_clone_blkg_association(bio, bio_src);
blkcg_bio_issue_init(bio);
return bio;
+
+err_put:
+ bio_put(bio);
+ return NULL;
}
static void __blk_queue_bounce(struct request_queue *q, struct bio **bio_orig,
diff --git a/drivers/md/dm.c b/drivers/md/dm.c
index 3dedd9cc4fb65..5487c3ff74b51 100644
--- a/drivers/md/dm.c
+++ b/drivers/md/dm.c
@@ -1326,14 +1326,15 @@ static int clone_bio(struct dm_target_io *tio, struct bio *bio,
sector_t sector, unsigned len)
{
struct bio *clone = &tio->clone;
+ int r;
__bio_clone_fast(clone, bio);
- bio_crypt_clone(clone, bio, GFP_NOIO);
+ r = bio_crypt_clone(clone, bio, GFP_NOIO);
+ if (r < 0)
+ return r;
if (bio_integrity(bio)) {
- int r;
-
if (unlikely(!dm_target_has_integrity(tio->ti->type) &&
!dm_target_passes_integrity(tio->ti->type))) {
DMWARN("%s: the target %s doesn't support integrity data.",
diff --git a/include/linux/blk-crypto.h b/include/linux/blk-crypto.h
index e82342907f2b1..69b24fe92cbf1 100644
--- a/include/linux/blk-crypto.h
+++ b/include/linux/blk-crypto.h
@@ -112,12 +112,24 @@ static inline bool bio_has_crypt_ctx(struct bio *bio)
#endif /* CONFIG_BLK_INLINE_ENCRYPTION */
-void __bio_crypt_clone(struct bio *dst, struct bio *src, gfp_t gfp_mask);
-static inline void bio_crypt_clone(struct bio *dst, struct bio *src,
- gfp_t gfp_mask)
+int __bio_crypt_clone(struct bio *dst, struct bio *src, gfp_t gfp_mask);
+/**
+ * bio_crypt_clone - clone bio encryption context
+ * @dst: destination bio
+ * @src: source bio
+ * @gfp_mask: memory allocation flags
+ *
+ * If @src has an encryption context, clone it to @dst.
+ *
+ * Return: 0 on success, -ENOMEM if out of memory. -ENOMEM is only possible if
+ * @gfp_mask doesn't include %__GFP_DIRECT_RECLAIM.
+ */
+static inline int bio_crypt_clone(struct bio *dst, struct bio *src,
+ gfp_t gfp_mask)
{
if (bio_has_crypt_ctx(src))
- __bio_crypt_clone(dst, src, gfp_mask);
+ return __bio_crypt_clone(dst, src, gfp_mask);
+ return 0;
}
#endif /* __LINUX_BLK_CRYPTO_H */
--
2.28.0
^ permalink raw reply related [flat|nested] 12+ messages in thread* Re: [PATCH v2 1/3] block: make bio_crypt_clone() able to fail
2020-09-16 3:53 ` [PATCH v2 1/3] block: make bio_crypt_clone() able to fail Eric Biggers
@ 2020-09-17 22:17 ` Satya Tangirala
2020-09-24 0:56 ` Mike Snitzer
1 sibling, 0 replies; 12+ messages in thread
From: Satya Tangirala @ 2020-09-17 22:17 UTC (permalink / raw)
To: Eric Biggers; +Cc: linux-block, Jens Axboe, dm-devel, Miaohe Lin
On Tue, Sep 15, 2020 at 08:53:13PM -0700, Eric Biggers wrote:
> From: Eric Biggers <ebiggers@google.com>
>
> bio_crypt_clone() assumes its gfp_mask argument always includes
> __GFP_DIRECT_RECLAIM, so that the mempool_alloc() will always succeed.
>
> However, bio_crypt_clone() might be called with GFP_ATOMIC via
> setup_clone() in drivers/md/dm-rq.c, or with GFP_NOWAIT via
> kcryptd_io_read() in drivers/md/dm-crypt.c.
>
> Neither case is currently reachable with a bio that actually has an
> encryption context. However, it's fragile to rely on this. Just make
> bio_crypt_clone() able to fail, analogous to bio_integrity_clone().
>
> Reported-by: Miaohe Lin <linmiaohe@huawei.com>
> Cc: Satya Tangirala <satyat@google.com>
> Signed-off-by: Eric Biggers <ebiggers@google.com>
> ---
> block/bio.c | 20 +++++++++-----------
> block/blk-crypto.c | 5 ++++-
> block/bounce.c | 19 +++++++++----------
> drivers/md/dm.c | 7 ++++---
> include/linux/blk-crypto.h | 20 ++++++++++++++++----
> 5 files changed, 42 insertions(+), 29 deletions(-)
>
> diff --git a/block/bio.c b/block/bio.c
> index a9931f23d9332..b42e046b12eb3 100644
> --- a/block/bio.c
> +++ b/block/bio.c
> @@ -713,20 +713,18 @@ struct bio *bio_clone_fast(struct bio *bio, gfp_t gfp_mask, struct bio_set *bs)
>
> __bio_clone_fast(b, bio);
>
> - bio_crypt_clone(b, bio, gfp_mask);
> + if (bio_crypt_clone(b, bio, gfp_mask) < 0)
> + goto err_put;
>
> - if (bio_integrity(bio)) {
> - int ret;
> -
> - ret = bio_integrity_clone(b, bio, gfp_mask);
> -
> - if (ret < 0) {
> - bio_put(b);
> - return NULL;
> - }
> - }
> + if (bio_integrity(bio) &&
> + bio_integrity_clone(b, bio, gfp_mask) < 0)
> + goto err_put;
>
> return b;
> +
> +err_put:
> + bio_put(b);
> + return NULL;
> }
> EXPORT_SYMBOL(bio_clone_fast);
>
> diff --git a/block/blk-crypto.c b/block/blk-crypto.c
> index 2d5e60023b08b..a3f27a19067c9 100644
> --- a/block/blk-crypto.c
> +++ b/block/blk-crypto.c
> @@ -95,10 +95,13 @@ void __bio_crypt_free_ctx(struct bio *bio)
> bio->bi_crypt_context = NULL;
> }
>
> -void __bio_crypt_clone(struct bio *dst, struct bio *src, gfp_t gfp_mask)
> +int __bio_crypt_clone(struct bio *dst, struct bio *src, gfp_t gfp_mask)
> {
> dst->bi_crypt_context = mempool_alloc(bio_crypt_ctx_pool, gfp_mask);
> + if (!dst->bi_crypt_context)
> + return -ENOMEM;
> *dst->bi_crypt_context = *src->bi_crypt_context;
> + return 0;
> }
> EXPORT_SYMBOL_GPL(__bio_crypt_clone);
>
> diff --git a/block/bounce.c b/block/bounce.c
> index 431be88a02405..162a6eee89996 100644
> --- a/block/bounce.c
> +++ b/block/bounce.c
> @@ -267,22 +267,21 @@ static struct bio *bounce_clone_bio(struct bio *bio_src, gfp_t gfp_mask,
> break;
> }
>
> - bio_crypt_clone(bio, bio_src, gfp_mask);
> + if (bio_crypt_clone(bio, bio_src, gfp_mask) < 0)
> + goto err_put;
>
> - if (bio_integrity(bio_src)) {
> - int ret;
> -
> - ret = bio_integrity_clone(bio, bio_src, gfp_mask);
> - if (ret < 0) {
> - bio_put(bio);
> - return NULL;
> - }
> - }
> + if (bio_integrity(bio_src) &&
> + bio_integrity_clone(bio, bio_src, gfp_mask) < 0)
> + goto err_put;
>
> bio_clone_blkg_association(bio, bio_src);
> blkcg_bio_issue_init(bio);
>
> return bio;
> +
> +err_put:
> + bio_put(bio);
> + return NULL;
> }
>
> static void __blk_queue_bounce(struct request_queue *q, struct bio **bio_orig,
> diff --git a/drivers/md/dm.c b/drivers/md/dm.c
> index 3dedd9cc4fb65..5487c3ff74b51 100644
> --- a/drivers/md/dm.c
> +++ b/drivers/md/dm.c
> @@ -1326,14 +1326,15 @@ static int clone_bio(struct dm_target_io *tio, struct bio *bio,
> sector_t sector, unsigned len)
> {
> struct bio *clone = &tio->clone;
> + int r;
>
> __bio_clone_fast(clone, bio);
>
> - bio_crypt_clone(clone, bio, GFP_NOIO);
> + r = bio_crypt_clone(clone, bio, GFP_NOIO);
> + if (r < 0)
> + return r;
>
> if (bio_integrity(bio)) {
> - int r;
> -
> if (unlikely(!dm_target_has_integrity(tio->ti->type) &&
> !dm_target_passes_integrity(tio->ti->type))) {
> DMWARN("%s: the target %s doesn't support integrity data.",
> diff --git a/include/linux/blk-crypto.h b/include/linux/blk-crypto.h
> index e82342907f2b1..69b24fe92cbf1 100644
> --- a/include/linux/blk-crypto.h
> +++ b/include/linux/blk-crypto.h
> @@ -112,12 +112,24 @@ static inline bool bio_has_crypt_ctx(struct bio *bio)
>
> #endif /* CONFIG_BLK_INLINE_ENCRYPTION */
>
> -void __bio_crypt_clone(struct bio *dst, struct bio *src, gfp_t gfp_mask);
> -static inline void bio_crypt_clone(struct bio *dst, struct bio *src,
> - gfp_t gfp_mask)
> +int __bio_crypt_clone(struct bio *dst, struct bio *src, gfp_t gfp_mask);
> +/**
> + * bio_crypt_clone - clone bio encryption context
> + * @dst: destination bio
> + * @src: source bio
> + * @gfp_mask: memory allocation flags
> + *
> + * If @src has an encryption context, clone it to @dst.
> + *
> + * Return: 0 on success, -ENOMEM if out of memory. -ENOMEM is only possible if
> + * @gfp_mask doesn't include %__GFP_DIRECT_RECLAIM.
> + */
> +static inline int bio_crypt_clone(struct bio *dst, struct bio *src,
> + gfp_t gfp_mask)
> {
> if (bio_has_crypt_ctx(src))
> - __bio_crypt_clone(dst, src, gfp_mask);
> + return __bio_crypt_clone(dst, src, gfp_mask);
> + return 0;
> }
>
> #endif /* __LINUX_BLK_CRYPTO_H */
Looks good to me :). Please feel free to add
Reviewed-by: Satya Tangirala <satyat@google.com>
> --
> 2.28.0
>
^ permalink raw reply [flat|nested] 12+ messages in thread* Re: [PATCH v2 1/3] block: make bio_crypt_clone() able to fail
2020-09-16 3:53 ` [PATCH v2 1/3] block: make bio_crypt_clone() able to fail Eric Biggers
2020-09-17 22:17 ` Satya Tangirala
@ 2020-09-24 0:56 ` Mike Snitzer
1 sibling, 0 replies; 12+ messages in thread
From: Mike Snitzer @ 2020-09-24 0:56 UTC (permalink / raw)
To: Eric Biggers
Cc: linux-block, Jens Axboe, Miaohe Lin, dm-devel, Satya Tangirala
On Tue, Sep 15 2020 at 11:53pm -0400,
Eric Biggers <ebiggers@kernel.org> wrote:
> From: Eric Biggers <ebiggers@google.com>
>
> bio_crypt_clone() assumes its gfp_mask argument always includes
> __GFP_DIRECT_RECLAIM, so that the mempool_alloc() will always succeed.
>
> However, bio_crypt_clone() might be called with GFP_ATOMIC via
> setup_clone() in drivers/md/dm-rq.c, or with GFP_NOWAIT via
> kcryptd_io_read() in drivers/md/dm-crypt.c.
>
> Neither case is currently reachable with a bio that actually has an
> encryption context. However, it's fragile to rely on this. Just make
> bio_crypt_clone() able to fail, analogous to bio_integrity_clone().
>
> Reported-by: Miaohe Lin <linmiaohe@huawei.com>
> Cc: Satya Tangirala <satyat@google.com>
> Signed-off-by: Eric Biggers <ebiggers@google.com>
Reviewed-by: Mike Snitzer <snitzer@redhat.com>
^ permalink raw reply [flat|nested] 12+ messages in thread
* [PATCH v2 2/3] block: make blk_crypto_rq_bio_prep() able to fail
2020-09-16 3:53 [PATCH v2 0/3] block: fix up bio_crypt_ctx allocation Eric Biggers
2020-09-16 3:53 ` [PATCH v2 1/3] block: make bio_crypt_clone() able to fail Eric Biggers
@ 2020-09-16 3:53 ` Eric Biggers
2020-09-17 22:19 ` Satya Tangirala
2020-09-24 0:57 ` Mike Snitzer
2020-09-16 3:53 ` [PATCH v2 3/3] block: warn if !__GFP_DIRECT_RECLAIM in bio_crypt_set_ctx() Eric Biggers
` (2 subsequent siblings)
4 siblings, 2 replies; 12+ messages in thread
From: Eric Biggers @ 2020-09-16 3:53 UTC (permalink / raw)
To: linux-block, Jens Axboe; +Cc: dm-devel, Satya Tangirala, Miaohe Lin
From: Eric Biggers <ebiggers@google.com>
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.
Cc: Miaohe Lin <linmiaohe@huawei.com>
Suggested-by: Satya Tangirala <satyat@google.com>
Signed-off-by: Eric Biggers <ebiggers@google.com>
---
block/blk-core.c | 8 +++++---
block/blk-crypto-internal.h | 21 ++++++++++++++++-----
block/blk-crypto.c | 18 +++++++-----------
block/blk-mq.c | 7 ++++++-
4 files changed, 34 insertions(+), 20 deletions(-)
diff --git a/block/blk-core.c b/block/blk-core.c
index ca3f0f00c9435..fbeaa49f6fe2c 100644
--- a/block/blk-core.c
+++ b/block/blk-core.c
@@ -1620,8 +1620,10 @@ int blk_rq_prep_clone(struct request *rq, struct request *rq_src,
if (rq->bio) {
rq->biotail->bi_next = bio;
rq->biotail = bio;
- } else
+ } else {
rq->bio = rq->biotail = bio;
+ }
+ bio = NULL;
}
/* Copy attributes of the original request to the clone request. */
@@ -1634,8 +1636,8 @@ int blk_rq_prep_clone(struct request *rq, struct request *rq_src,
rq->nr_phys_segments = rq_src->nr_phys_segments;
rq->ioprio = rq_src->ioprio;
- if (rq->bio)
- blk_crypto_rq_bio_prep(rq, rq->bio, gfp_mask);
+ if (rq->bio && blk_crypto_rq_bio_prep(rq, rq->bio, gfp_mask) < 0)
+ goto free_and_out;
return 0;
diff --git a/block/blk-crypto-internal.h b/block/blk-crypto-internal.h
index d2b0f565d83cb..0d36aae538d7b 100644
--- a/block/blk-crypto-internal.h
+++ b/block/blk-crypto-internal.h
@@ -142,13 +142,24 @@ static inline void blk_crypto_free_request(struct request *rq)
__blk_crypto_free_request(rq);
}
-void __blk_crypto_rq_bio_prep(struct request *rq, struct bio *bio,
- gfp_t gfp_mask);
-static inline void blk_crypto_rq_bio_prep(struct request *rq, struct bio *bio,
- gfp_t gfp_mask)
+int __blk_crypto_rq_bio_prep(struct request *rq, struct bio *bio,
+ gfp_t gfp_mask);
+/**
+ * blk_crypto_rq_bio_prep - Prepare a request's crypt_ctx when its first bio
+ * is inserted
+ * @rq: The request to prepare
+ * @bio: The first bio being inserted into the request
+ * @gfp_mask: Memory allocation flags
+ *
+ * Return: 0 on success, -ENOMEM if out of memory. -ENOMEM is only possible if
+ * @gfp_mask doesn't include %__GFP_DIRECT_RECLAIM.
+ */
+static inline int blk_crypto_rq_bio_prep(struct request *rq, struct bio *bio,
+ gfp_t gfp_mask)
{
if (bio_has_crypt_ctx(bio))
- __blk_crypto_rq_bio_prep(rq, bio, gfp_mask);
+ return __blk_crypto_rq_bio_prep(rq, bio, gfp_mask);
+ return 0;
}
/**
diff --git a/block/blk-crypto.c b/block/blk-crypto.c
index a3f27a19067c9..bbe7974fd74f0 100644
--- a/block/blk-crypto.c
+++ b/block/blk-crypto.c
@@ -283,20 +283,16 @@ bool __blk_crypto_bio_prep(struct bio **bio_ptr)
return false;
}
-/**
- * __blk_crypto_rq_bio_prep - Prepare a request's crypt_ctx when its first bio
- * is inserted
- *
- * @rq: The request to prepare
- * @bio: The first bio being inserted into the request
- * @gfp_mask: gfp mask
- */
-void __blk_crypto_rq_bio_prep(struct request *rq, struct bio *bio,
- gfp_t gfp_mask)
+int __blk_crypto_rq_bio_prep(struct request *rq, struct bio *bio,
+ gfp_t gfp_mask)
{
- if (!rq->crypt_ctx)
+ if (!rq->crypt_ctx) {
rq->crypt_ctx = mempool_alloc(bio_crypt_ctx_pool, gfp_mask);
+ if (!rq->crypt_ctx)
+ return -ENOMEM;
+ }
*rq->crypt_ctx = *bio->bi_crypt_context;
+ return 0;
}
/**
diff --git a/block/blk-mq.c b/block/blk-mq.c
index e04b759add758..9ec0e7149ae69 100644
--- a/block/blk-mq.c
+++ b/block/blk-mq.c
@@ -1940,13 +1940,18 @@ void blk_mq_flush_plug_list(struct blk_plug *plug, bool from_schedule)
static void blk_mq_bio_to_request(struct request *rq, struct bio *bio,
unsigned int nr_segs)
{
+ int err;
+
if (bio->bi_opf & REQ_RAHEAD)
rq->cmd_flags |= REQ_FAILFAST_MASK;
rq->__sector = bio->bi_iter.bi_sector;
rq->write_hint = bio->bi_write_hint;
blk_rq_bio_prep(rq, bio, nr_segs);
- blk_crypto_rq_bio_prep(rq, bio, GFP_NOIO);
+
+ /* This can't fail, since GFP_NOIO includes __GFP_DIRECT_RECLAIM. */
+ err = blk_crypto_rq_bio_prep(rq, bio, GFP_NOIO);
+ WARN_ON_ONCE(err);
blk_account_io_start(rq);
}
--
2.28.0
^ permalink raw reply related [flat|nested] 12+ messages in thread* Re: [PATCH v2 2/3] block: make blk_crypto_rq_bio_prep() able to fail
2020-09-16 3:53 ` [PATCH v2 2/3] block: make blk_crypto_rq_bio_prep() " Eric Biggers
@ 2020-09-17 22:19 ` Satya Tangirala
2020-09-24 0:57 ` Mike Snitzer
1 sibling, 0 replies; 12+ messages in thread
From: Satya Tangirala @ 2020-09-17 22:19 UTC (permalink / raw)
To: Eric Biggers; +Cc: linux-block, Jens Axboe, dm-devel, Miaohe Lin
On Tue, Sep 15, 2020 at 08:53:14PM -0700, Eric Biggers wrote:
> From: Eric Biggers <ebiggers@google.com>
>
> 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.
>
> Cc: Miaohe Lin <linmiaohe@huawei.com>
> Suggested-by: Satya Tangirala <satyat@google.com>
> Signed-off-by: Eric Biggers <ebiggers@google.com>
> ---
> block/blk-core.c | 8 +++++---
> block/blk-crypto-internal.h | 21 ++++++++++++++++-----
> block/blk-crypto.c | 18 +++++++-----------
> block/blk-mq.c | 7 ++++++-
> 4 files changed, 34 insertions(+), 20 deletions(-)
>
> diff --git a/block/blk-core.c b/block/blk-core.c
> index ca3f0f00c9435..fbeaa49f6fe2c 100644
> --- a/block/blk-core.c
> +++ b/block/blk-core.c
> @@ -1620,8 +1620,10 @@ int blk_rq_prep_clone(struct request *rq, struct request *rq_src,
> if (rq->bio) {
> rq->biotail->bi_next = bio;
> rq->biotail = bio;
> - } else
> + } else {
> rq->bio = rq->biotail = bio;
> + }
> + bio = NULL;
> }
>
> /* Copy attributes of the original request to the clone request. */
> @@ -1634,8 +1636,8 @@ int blk_rq_prep_clone(struct request *rq, struct request *rq_src,
> rq->nr_phys_segments = rq_src->nr_phys_segments;
> rq->ioprio = rq_src->ioprio;
>
> - if (rq->bio)
> - blk_crypto_rq_bio_prep(rq, rq->bio, gfp_mask);
> + if (rq->bio && blk_crypto_rq_bio_prep(rq, rq->bio, gfp_mask) < 0)
> + goto free_and_out;
>
> return 0;
>
> diff --git a/block/blk-crypto-internal.h b/block/blk-crypto-internal.h
> index d2b0f565d83cb..0d36aae538d7b 100644
> --- a/block/blk-crypto-internal.h
> +++ b/block/blk-crypto-internal.h
> @@ -142,13 +142,24 @@ static inline void blk_crypto_free_request(struct request *rq)
> __blk_crypto_free_request(rq);
> }
>
> -void __blk_crypto_rq_bio_prep(struct request *rq, struct bio *bio,
> - gfp_t gfp_mask);
> -static inline void blk_crypto_rq_bio_prep(struct request *rq, struct bio *bio,
> - gfp_t gfp_mask)
> +int __blk_crypto_rq_bio_prep(struct request *rq, struct bio *bio,
> + gfp_t gfp_mask);
> +/**
> + * blk_crypto_rq_bio_prep - Prepare a request's crypt_ctx when its first bio
> + * is inserted
> + * @rq: The request to prepare
> + * @bio: The first bio being inserted into the request
> + * @gfp_mask: Memory allocation flags
> + *
> + * Return: 0 on success, -ENOMEM if out of memory. -ENOMEM is only possible if
> + * @gfp_mask doesn't include %__GFP_DIRECT_RECLAIM.
> + */
> +static inline int blk_crypto_rq_bio_prep(struct request *rq, struct bio *bio,
> + gfp_t gfp_mask)
> {
> if (bio_has_crypt_ctx(bio))
> - __blk_crypto_rq_bio_prep(rq, bio, gfp_mask);
> + return __blk_crypto_rq_bio_prep(rq, bio, gfp_mask);
> + return 0;
> }
>
> /**
> diff --git a/block/blk-crypto.c b/block/blk-crypto.c
> index a3f27a19067c9..bbe7974fd74f0 100644
> --- a/block/blk-crypto.c
> +++ b/block/blk-crypto.c
> @@ -283,20 +283,16 @@ bool __blk_crypto_bio_prep(struct bio **bio_ptr)
> return false;
> }
>
> -/**
> - * __blk_crypto_rq_bio_prep - Prepare a request's crypt_ctx when its first bio
> - * is inserted
> - *
> - * @rq: The request to prepare
> - * @bio: The first bio being inserted into the request
> - * @gfp_mask: gfp mask
> - */
> -void __blk_crypto_rq_bio_prep(struct request *rq, struct bio *bio,
> - gfp_t gfp_mask)
> +int __blk_crypto_rq_bio_prep(struct request *rq, struct bio *bio,
> + gfp_t gfp_mask)
> {
> - if (!rq->crypt_ctx)
> + if (!rq->crypt_ctx) {
> rq->crypt_ctx = mempool_alloc(bio_crypt_ctx_pool, gfp_mask);
> + if (!rq->crypt_ctx)
> + return -ENOMEM;
> + }
> *rq->crypt_ctx = *bio->bi_crypt_context;
> + return 0;
> }
>
> /**
> diff --git a/block/blk-mq.c b/block/blk-mq.c
> index e04b759add758..9ec0e7149ae69 100644
> --- a/block/blk-mq.c
> +++ b/block/blk-mq.c
> @@ -1940,13 +1940,18 @@ void blk_mq_flush_plug_list(struct blk_plug *plug, bool from_schedule)
> static void blk_mq_bio_to_request(struct request *rq, struct bio *bio,
> unsigned int nr_segs)
> {
> + int err;
> +
> if (bio->bi_opf & REQ_RAHEAD)
> rq->cmd_flags |= REQ_FAILFAST_MASK;
>
> rq->__sector = bio->bi_iter.bi_sector;
> rq->write_hint = bio->bi_write_hint;
> blk_rq_bio_prep(rq, bio, nr_segs);
> - blk_crypto_rq_bio_prep(rq, bio, GFP_NOIO);
> +
> + /* This can't fail, since GFP_NOIO includes __GFP_DIRECT_RECLAIM. */
> + err = blk_crypto_rq_bio_prep(rq, bio, GFP_NOIO);
> + WARN_ON_ONCE(err);
>
> blk_account_io_start(rq);
> }
Looks good!
Reviewed-by: Satya Tangirala <satyat@google.com>
> --
> 2.28.0
>
^ permalink raw reply [flat|nested] 12+ messages in thread* Re: [PATCH v2 2/3] block: make blk_crypto_rq_bio_prep() able to fail
2020-09-16 3:53 ` [PATCH v2 2/3] block: make blk_crypto_rq_bio_prep() " Eric Biggers
2020-09-17 22:19 ` Satya Tangirala
@ 2020-09-24 0:57 ` Mike Snitzer
1 sibling, 0 replies; 12+ messages in thread
From: Mike Snitzer @ 2020-09-24 0:57 UTC (permalink / raw)
To: Eric Biggers
Cc: linux-block, Jens Axboe, Miaohe Lin, dm-devel, Satya Tangirala
On Tue, Sep 15 2020 at 11:53pm -0400,
Eric Biggers <ebiggers@kernel.org> wrote:
> From: Eric Biggers <ebiggers@google.com>
>
> 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.
>
> Cc: Miaohe Lin <linmiaohe@huawei.com>
> Suggested-by: Satya Tangirala <satyat@google.com>
> Signed-off-by: Eric Biggers <ebiggers@google.com>
Reviewed-by: Mike Snitzer <snitzer@redhat.com>
^ permalink raw reply [flat|nested] 12+ messages in thread
* [PATCH v2 3/3] block: warn if !__GFP_DIRECT_RECLAIM in bio_crypt_set_ctx()
2020-09-16 3:53 [PATCH v2 0/3] block: fix up bio_crypt_ctx allocation Eric Biggers
2020-09-16 3:53 ` [PATCH v2 1/3] block: make bio_crypt_clone() able to fail Eric Biggers
2020-09-16 3:53 ` [PATCH v2 2/3] block: make blk_crypto_rq_bio_prep() " Eric Biggers
@ 2020-09-16 3:53 ` Eric Biggers
2020-09-17 22:26 ` Satya Tangirala
2020-09-28 20:59 ` [PATCH v2 0/3] block: fix up bio_crypt_ctx allocation Eric Biggers
2020-10-05 16:48 ` Jens Axboe
4 siblings, 1 reply; 12+ messages in thread
From: Eric Biggers @ 2020-09-16 3:53 UTC (permalink / raw)
To: linux-block, Jens Axboe; +Cc: dm-devel, Satya Tangirala, Miaohe Lin
From: Eric Biggers <ebiggers@google.com>
bio_crypt_set_ctx() assumes its gfp_mask argument always includes
__GFP_DIRECT_RECLAIM, so that the mempool_alloc() will always succeed.
For now this assumption is still fine, since no callers violate it.
Making bio_crypt_set_ctx() able to fail would add unneeded complexity.
However, if a caller didn't use __GFP_DIRECT_RECLAIM, it would be very
hard to notice the bug. Make it easier by adding a WARN_ON_ONCE().
Cc: Miaohe Lin <linmiaohe@huawei.com>
Cc: Satya Tangirala <satyat@google.com>
Signed-off-by: Eric Biggers <ebiggers@google.com>
---
block/blk-crypto.c | 10 +++++++++-
1 file changed, 9 insertions(+), 1 deletion(-)
diff --git a/block/blk-crypto.c b/block/blk-crypto.c
index bbe7974fd74f0..5da43f0973b46 100644
--- a/block/blk-crypto.c
+++ b/block/blk-crypto.c
@@ -81,7 +81,15 @@ subsys_initcall(bio_crypt_ctx_init);
void bio_crypt_set_ctx(struct bio *bio, const struct blk_crypto_key *key,
const u64 dun[BLK_CRYPTO_DUN_ARRAY_SIZE], gfp_t gfp_mask)
{
- struct bio_crypt_ctx *bc = mempool_alloc(bio_crypt_ctx_pool, gfp_mask);
+ struct bio_crypt_ctx *bc;
+
+ /*
+ * The caller must use a gfp_mask that contains __GFP_DIRECT_RECLAIM so
+ * that the mempool_alloc() can't fail.
+ */
+ WARN_ON_ONCE(!(gfp_mask & __GFP_DIRECT_RECLAIM));
+
+ bc = mempool_alloc(bio_crypt_ctx_pool, gfp_mask);
bc->bc_key = key;
memcpy(bc->bc_dun, dun, sizeof(bc->bc_dun));
--
2.28.0
^ permalink raw reply related [flat|nested] 12+ messages in thread* Re: [PATCH v2 3/3] block: warn if !__GFP_DIRECT_RECLAIM in bio_crypt_set_ctx()
2020-09-16 3:53 ` [PATCH v2 3/3] block: warn if !__GFP_DIRECT_RECLAIM in bio_crypt_set_ctx() Eric Biggers
@ 2020-09-17 22:26 ` Satya Tangirala
0 siblings, 0 replies; 12+ messages in thread
From: Satya Tangirala @ 2020-09-17 22:26 UTC (permalink / raw)
To: Eric Biggers; +Cc: linux-block, Jens Axboe, dm-devel, Miaohe Lin
On Tue, Sep 15, 2020 at 08:53:15PM -0700, Eric Biggers wrote:
> From: Eric Biggers <ebiggers@google.com>
>
> bio_crypt_set_ctx() assumes its gfp_mask argument always includes
> __GFP_DIRECT_RECLAIM, so that the mempool_alloc() will always succeed.
>
> For now this assumption is still fine, since no callers violate it.
> Making bio_crypt_set_ctx() able to fail would add unneeded complexity.
>
> However, if a caller didn't use __GFP_DIRECT_RECLAIM, it would be very
> hard to notice the bug. Make it easier by adding a WARN_ON_ONCE().
>
> Cc: Miaohe Lin <linmiaohe@huawei.com>
> Cc: Satya Tangirala <satyat@google.com>
> Signed-off-by: Eric Biggers <ebiggers@google.com>
> ---
> block/blk-crypto.c | 10 +++++++++-
> 1 file changed, 9 insertions(+), 1 deletion(-)
>
> diff --git a/block/blk-crypto.c b/block/blk-crypto.c
> index bbe7974fd74f0..5da43f0973b46 100644
> --- a/block/blk-crypto.c
> +++ b/block/blk-crypto.c
> @@ -81,7 +81,15 @@ subsys_initcall(bio_crypt_ctx_init);
> void bio_crypt_set_ctx(struct bio *bio, const struct blk_crypto_key *key,
> const u64 dun[BLK_CRYPTO_DUN_ARRAY_SIZE], gfp_t gfp_mask)
> {
> - struct bio_crypt_ctx *bc = mempool_alloc(bio_crypt_ctx_pool, gfp_mask);
> + struct bio_crypt_ctx *bc;
> +
> + /*
> + * The caller must use a gfp_mask that contains __GFP_DIRECT_RECLAIM so
> + * that the mempool_alloc() can't fail.
> + */
> + WARN_ON_ONCE(!(gfp_mask & __GFP_DIRECT_RECLAIM));
> +
> + bc = mempool_alloc(bio_crypt_ctx_pool, gfp_mask);
>
> bc->bc_key = key;
> memcpy(bc->bc_dun, dun, sizeof(bc->bc_dun));
> --
Looks good!
Reviewed-by: Satya Tangirala <satyat@google.com>
> 2.28.0
>
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [PATCH v2 0/3] block: fix up bio_crypt_ctx allocation
2020-09-16 3:53 [PATCH v2 0/3] block: fix up bio_crypt_ctx allocation Eric Biggers
` (2 preceding siblings ...)
2020-09-16 3:53 ` [PATCH v2 3/3] block: warn if !__GFP_DIRECT_RECLAIM in bio_crypt_set_ctx() Eric Biggers
@ 2020-09-28 20:59 ` Eric Biggers
2020-10-05 16:42 ` Eric Biggers
2020-10-05 16:48 ` Jens Axboe
4 siblings, 1 reply; 12+ messages in thread
From: Eric Biggers @ 2020-09-28 20:59 UTC (permalink / raw)
To: Jens Axboe; +Cc: linux-block, dm-devel, Satya Tangirala, Miaohe Lin
On Tue, Sep 15, 2020 at 08:53:12PM -0700, Eric Biggers wrote:
> This series makes allocation of encryption contexts either able to fail,
> or explicitly require __GFP_DIRECT_RECLAIM (via WARN_ON_ONCE).
>
> This applies to linux-block/for-next.
>
> Changed since v1 (https://lkml.kernel.org/r/20200902051511.79821-1-ebiggers@kernel.org):
> - Added patches 2 and 3.
> - Added kerneldoc for bio_crypt_clone().
> - Adjusted commit message.
>
> Eric Biggers (3):
> block: make bio_crypt_clone() able to fail
> block: make blk_crypto_rq_bio_prep() able to fail
> block: warn if !__GFP_DIRECT_RECLAIM in bio_crypt_set_ctx()
Jens, any interest in applying these patches for 5.10?
- Eric
^ permalink raw reply [flat|nested] 12+ messages in thread* Re: [PATCH v2 0/3] block: fix up bio_crypt_ctx allocation
2020-09-28 20:59 ` [PATCH v2 0/3] block: fix up bio_crypt_ctx allocation Eric Biggers
@ 2020-10-05 16:42 ` Eric Biggers
0 siblings, 0 replies; 12+ messages in thread
From: Eric Biggers @ 2020-10-05 16:42 UTC (permalink / raw)
To: Jens Axboe; +Cc: linux-block, Miaohe Lin, dm-devel, Satya Tangirala
On Mon, Sep 28, 2020 at 01:59:34PM -0700, Eric Biggers wrote:
> On Tue, Sep 15, 2020 at 08:53:12PM -0700, Eric Biggers wrote:
> > This series makes allocation of encryption contexts either able to fail,
> > or explicitly require __GFP_DIRECT_RECLAIM (via WARN_ON_ONCE).
> >
> > This applies to linux-block/for-next.
> >
> > Changed since v1 (https://lkml.kernel.org/r/20200902051511.79821-1-ebiggers@kernel.org):
> > - Added patches 2 and 3.
> > - Added kerneldoc for bio_crypt_clone().
> > - Adjusted commit message.
> >
> > Eric Biggers (3):
> > block: make bio_crypt_clone() able to fail
> > block: make blk_crypto_rq_bio_prep() able to fail
> > block: warn if !__GFP_DIRECT_RECLAIM in bio_crypt_set_ctx()
>
> Jens, any interest in applying these patches for 5.10?
>
Ping.
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [PATCH v2 0/3] block: fix up bio_crypt_ctx allocation
2020-09-16 3:53 [PATCH v2 0/3] block: fix up bio_crypt_ctx allocation Eric Biggers
` (3 preceding siblings ...)
2020-09-28 20:59 ` [PATCH v2 0/3] block: fix up bio_crypt_ctx allocation Eric Biggers
@ 2020-10-05 16:48 ` Jens Axboe
4 siblings, 0 replies; 12+ messages in thread
From: Jens Axboe @ 2020-10-05 16:48 UTC (permalink / raw)
To: Eric Biggers, linux-block; +Cc: dm-devel, Satya Tangirala, Miaohe Lin
On 9/15/20 9:53 PM, Eric Biggers wrote:
> This series makes allocation of encryption contexts either able to fail,
> or explicitly require __GFP_DIRECT_RECLAIM (via WARN_ON_ONCE).
>
> This applies to linux-block/for-next.
>
> Changed since v1 (https://lkml.kernel.org/r/20200902051511.79821-1-ebiggers@kernel.org):
> - Added patches 2 and 3.
> - Added kerneldoc for bio_crypt_clone().
> - Adjusted commit message.
Applied for 5.10, thanks.
--
Jens Axboe
^ permalink raw reply [flat|nested] 12+ messages in thread