Hi
This is backport of the upstream patch
7efb367320f56fc4d549875b6f3a6940018ef2e5 for the stable kernels.
On Thu, 22 Sep 2016, gregkh@xxxxxxxxxxxxxxxxxxx wrote:
>
> The patch below does not apply to the 4.7-stable tree.
> If someone wants it applied there, or to any other stable or longterm
> tree, then please email the backport, including the original git commit
> id to <stable@xxxxxxxxxxxxxxx>.
>
> thanks,
>
> greg k-h
>
> ------------------ original commit in Linus's tree ------------------
>
> >From 7efb367320f56fc4d549875b6f3a6940018ef2e5 Mon Sep 17 00:00:00 2001
> From: Mikulas Patocka <mpatocka@xxxxxxxxxx>
> Date: Tue, 30 Aug 2016 16:20:55 -0400
> Subject: [PATCH] dm log writes: fix bug with too large bios
>
> bio_alloc() can allocate a bio with at most BIO_MAX_PAGES (256) vector
> entries. However, the incoming bio may have more vector entries if it
> was allocated by other means. For example, bcache submits bios with
> more than BIO_MAX_PAGES entries. This results in bio_alloc() failure.
>
> To avoid the failure, change the code so that it allocates bio with at
> most BIO_MAX_PAGES entries. If the incoming bio has more entries,
> bio_add_page() will fail and a new bio will be allocated - the code that
> handles bio_add_page() failure already exists in the dm-log-writes
> target.
>
> Signed-off-by: Mikulas Patocka <mpatocka@xxxxxxxxxx>
> Reviewed-by: Josef Bacik <jbacik@fb,com>
> Signed-off-by: Mike Snitzer <snitzer@xxxxxxxxxx>
> Cc: stable@xxxxxxxxxxxxxxx # v4.1+
>
> diff --git a/drivers/md/dm-log-writes.c b/drivers/md/dm-log-writes.c
> index 4cc78aef9007..ba24f4f37efc 100644
> --- a/drivers/md/dm-log-writes.c
> +++ b/drivers/md/dm-log-writes.c
> @@ -260,7 +260,7 @@ static int log_one_block(struct log_writes_c *lc,
> sector++;
>
> atomic_inc(&lc->io_blocks);
> - bio = bio_alloc(GFP_KERNEL, block->vec_cnt);
> + bio = bio_alloc(GFP_KERNEL, min(block->vec_cnt, BIO_MAX_PAGES));
> if (!bio) {
> DMERR("Couldn't alloc log bio");
> goto error;
> @@ -282,7 +282,7 @@ static int log_one_block(struct log_writes_c *lc,
> if (ret != block->vecs[i].bv_len) {
> atomic_inc(&lc->io_blocks);
> submit_bio(bio);
> - bio = bio_alloc(GFP_KERNEL, block->vec_cnt - i);
> + bio = bio_alloc(GFP_KERNEL, min(block->vec_cnt - i, BIO_MAX_PAGES));
> if (!bio) {
> DMERR("Couldn't alloc log bio");
> goto error;
>
commit 7efb367320f56fc4d549875b6f3a6940018ef2e5
Author: Mikulas Patocka <mpatocka@xxxxxxxxxx>
Date: Tue Aug 30 16:20:55 2016 -0400
dm log writes: fix bug with too large bios
bio_alloc() can allocate a bio with at most BIO_MAX_PAGES (256) vector
entries. However, the incoming bio may have more vector entries if it
was allocated by other means. For example, bcache submits bios with
more than BIO_MAX_PAGES entries. This results in bio_alloc() failure.
To avoid the failure, change the code so that it allocates bio with at
most BIO_MAX_PAGES entries. If the incoming bio has more entries,
bio_add_page() will fail and a new bio will be allocated - the code that
handles bio_add_page() failure already exists in the dm-log-writes
target.
Signed-off-by: Mikulas Patocka <mpatocka@xxxxxxxxxx>
Reviewed-by: Josef Bacik <jbacik@fb,com>
Signed-off-by: Mike Snitzer <snitzer@xxxxxxxxxx>
Cc: stable@xxxxxxxxxxxxxxx # v4.1+
diff --git a/drivers/md/dm-log-writes.c b/drivers/md/dm-log-writes.c
index 4cc78ae..ba24f4f 100644
--- a/drivers/md/dm-log-writes.c
+++ b/drivers/md/dm-log-writes.c
@@ -260,7 +260,7 @@ static int log_one_block(struct log_writes_c *lc,
sector++;
atomic_inc(&lc->io_blocks);
- bio = bio_alloc(GFP_KERNEL, block->vec_cnt);
+ bio = bio_alloc(GFP_KERNEL, min(block->vec_cnt, BIO_MAX_PAGES));
if (!bio) {
DMERR("Couldn't alloc log bio");
goto error;
@@ -282,7 +282,7 @@ static int log_one_block(struct log_writes_c *lc,
if (ret != block->vecs[i].bv_len) {
atomic_inc(&lc->io_blocks);
submit_bio(WRITE, bio);
- bio = bio_alloc(GFP_KERNEL, block->vec_cnt - i);
+ bio = bio_alloc(GFP_KERNEL, min(block->vec_cnt - i, BIO_MAX_PAGES));
if (!bio) {
DMERR("Couldn't alloc log bio");
goto error;
--
To unsubscribe from this list: send the line "unsubscribe stable" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html