From: Jeff Moyer <jmoyer@redhat.com>
To: Shaohua Li <shli@kernel.org>
Cc: Sebastian Roesner <sroesner-kernelorg@roesner-online.de>,
Ming Lei <ming.lei@canonical.com>,
Eric Wheeler <bcache@lists.ewheeler.net>,
linux-bcache@vger.kernel.org, linux-raid@vger.kernel.org,
Ming Lin <mlin@kernel.org>, Vlad-Cosmin Miu <miuvlad@gmail.com>,
rjones@redhat.com, Kent Overstreet <kent.overstreet@gmail.com>,
axboe@fb.com
Subject: Re: [BUG] NULL pointer in raid1_make_request passed to bio_trim when adding md as bcache caching dev
Date: Mon, 28 Mar 2016 14:38:53 -0400 [thread overview]
Message-ID: <x49mvpi5txe.fsf@segfault.boston.devel.redhat.com> (raw)
In-Reply-To: <20160328181059.GA83819@kernel.org> (Shaohua Li's message of "Mon, 28 Mar 2016 11:10:59 -0700")
Shaohua Li <shli@kernel.org> writes:
> On Sat, Mar 26, 2016 at 05:46:16PM +0100, Sebastian Roesner wrote:
>> Hello Ming, Eric,
>>
>> Am 26.03.2016 um 16:40 schrieb Ming Lei:
>> > From the trace, looks the bio returned from bio_clone_mddev() is NULL,
>> >and maybe the source bio is buggy, something like the attached patch
>> >might be helpful, could you apply the attached debug patch, reproduce
>> >and post the log?
>>
>> I was able to reproduce it on a non-productive system, but only after
>> copying the bcache superblocks/partition starts from the original system,
>> with new created ones it worked fine.
>>
>> Full trace and check_bio output can be found here:
>>
>> http://pastebin.com/ngvGGHBZ
>
> 320 bvecs exceeds what bio-clone_set can handle. Could you please try
> below patch?
OK, so bvec_alloc won't allow us to allocate more than BIO_MAX_PAGES.
> commit 92761dad7ff6e1bf25de247e0064dd398e797599
> Author: Shaohua Li <shli@fb.com>
> Date: Mon Mar 28 10:54:35 2016 -0700
>
> block: don't make BLK_DEF_MAX_SECTORS too big
>
> bio_alloc_bioset() allocates bvecs from bvec_slabs which can only allocate
> maximum 256 bvec (eg, 1M for 4k pages). We can't bump BLK_DEF_MAX_SECTORS to
> exceed this value otherwise bio_alloc_bioset will fail.
>
> This fixes commit 30e2bc08b2bb7c069.
Wrong commit. You meant this one: d2be537c3ba (block: bump
BLK_DEF_MAX_SECTORS to 2560).
> We probably should make the bvec_slabs hold bigger bvecs if bigger
> bio size is required.
This change is okay with me. So long as it fixes the issue, it should
be marked for stable, too. Thanks for adding the comment, by the way!
Reviewed-by: Jeff Moyer <jmoyer@redhat.com>
> Signed-off-by: Shaohua Li <shli@fb.com>
>
> diff --git a/include/linux/blkdev.h b/include/linux/blkdev.h
> index 7e5d7e0..da64325 100644
> --- a/include/linux/blkdev.h
> +++ b/include/linux/blkdev.h
> @@ -1153,7 +1153,11 @@ extern int blk_verify_command(unsigned char *cmd, fmode_t has_write_perm);
> enum blk_default_limits {
> BLK_MAX_SEGMENTS = 128,
> BLK_SAFE_MAX_SECTORS = 255,
> - BLK_DEF_MAX_SECTORS = 2560,
> + /*
> + * if you change this, please also change bvec_alloc and BIO_MAX_PAGES.
> + * Otherwise bio_alloc_bioset will break.
> + */
> + BLK_DEF_MAX_SECTORS = BIO_MAX_SECTORS,
> BLK_MAX_SEGMENT_SIZE = 65536,
> BLK_SEG_BOUNDARY_MASK = 0xFFFFFFFFUL,
> };
next prev parent reply other threads:[~2016-03-28 18:38 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-03-24 15:19 Bug - bcache: "unable to handle kernel NULL pointer dereference" when trying to add a md caching device Sebastian Roesner
2016-03-25 1:49 ` Eric Wheeler
2016-03-25 4:18 ` Eric Wheeler
2016-03-25 14:11 ` Sebastian Roesner
2016-03-25 20:44 ` [BUG] NULL pointer in raid1_make_request passed to bio_trim when adding md as bcache caching dev Eric Wheeler
2016-03-25 21:32 ` Eric Wheeler
2016-03-26 18:38 ` Sebastian Roesner
2016-03-26 15:40 ` Ming Lei
2016-03-26 16:46 ` Sebastian Roesner
2016-03-28 18:10 ` Shaohua Li
2016-03-28 18:38 ` Jeff Moyer [this message]
2016-03-29 1:28 ` Ming Lei
2016-04-01 18:14 ` Eric Wheeler
2016-04-10 18:01 ` Sebastian Roesner
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=x49mvpi5txe.fsf@segfault.boston.devel.redhat.com \
--to=jmoyer@redhat.com \
--cc=axboe@fb.com \
--cc=bcache@lists.ewheeler.net \
--cc=kent.overstreet@gmail.com \
--cc=linux-bcache@vger.kernel.org \
--cc=linux-raid@vger.kernel.org \
--cc=ming.lei@canonical.com \
--cc=miuvlad@gmail.com \
--cc=mlin@kernel.org \
--cc=rjones@redhat.com \
--cc=shli@kernel.org \
--cc=sroesner-kernelorg@roesner-online.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox