linux-bcache.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Eric Wheeler <bcache@lists.ewheeler.net>
To: Shaohua Li <shli@kernel.org>
Cc: Ming Lei <ming.lei@canonical.com>,
	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>,
	jmoyer@redhat.com, axboe@fb.com,
	Sebastian Roesner <sroesner-kernelorg@roesner-online.de>,
	linux-block@vger.kernel.org
Subject: Re: [PATCH] NULL pointer in raid1_make_request passed to bio_trim when adding md as bcache caching dev
Date: Wed, 10 Aug 2016 23:52:15 -0700 (PDT)	[thread overview]
Message-ID: <alpine.LRH.2.11.1608102344080.10662@mail.ewheeler.net> (raw)
In-Reply-To: <alpine.LRH.2.11.1608102035180.10662@mail.ewheeler.net>

On Wed, 10 Aug 2016, Eric Wheeler wrote:

> On Sun, 10 Apr 2016 20:01:30 +0200, Sebastian Roesner wrote:
> > Am 01.04.2016 um 20:14 schrieb Eric Wheeler:
> > > On Mon, 28 Mar 2016, Shaohua Li wrote:
> > > > 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:
> > > > > 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.
> > > >
> > > > 320 bvecs exceeds what bio-clone_set can handle. Could you please try below patch?
> > > >
> > > Hey Sebastian,
> > > 
> > > Have you had a chance to test the patch below from Shaohua Li?
> > 
> > I just tried the patch and it did not crash anymore.
>  
> It doesn't look like this made it into v4.8-rc1 and it is known to fix at 
> least Sebastian's issue.
> 
> 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. We probably should make the bvec_slabs
>     hold bigger bvecs if bigger bio size is required.
>     
>     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,


It seems that I spoke too soon, as BIO_MAX_SECTORS was removed for v4.8.

What should BLK_DEF_MAX_SECTORS be defined as?  

Something like this?
	-	BLK_DEF_MAX_SECTORS     = 2560,
	+	BLK_DEF_MAX_SECTORS = (BIO_MAX_PAGES << (PAGE_SHIFT-9)

Or was this issue patched by Shaohua Li solved in some other way?

It appears that BLK_DEF_MAX_SECTORS is still used:

$ git grep BLK_DEF_MAX_SECTORS
block/blk-settings.c:   max_sectors = min_t(unsigned int, max_sectors, BLK_DEF_MAX_SECTORS);
drivers/block/aoe/aoeblk.c:     blk_queue_max_hw_sectors(q, BLK_DEF_MAX_SECTORS);
drivers/scsi/sd.c:              rw_max = BLK_DEF_MAX_SECTORS;


--
Eric Wheeler


>  	BLK_MAX_SEGMENT_SIZE	= 65536,
>  	BLK_SEG_BOUNDARY_MASK	= 0xFFFFFFFFUL,
>  };
> --
> To unsubscribe from this list: send the line "unsubscribe linux-bcache" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> --
> To unsubscribe from this list: send the line "unsubscribe linux-bcache" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 

      parent reply	other threads:[~2016-08-11  6:52 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-08-11  3:44 [PATCH] NULL pointer in raid1_make_request passed to bio_trim when adding md as bcache caching dev Eric Wheeler
2016-08-11  4:36 ` kbuild test robot
2016-08-11  6:52 ` Eric Wheeler [this message]

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=alpine.LRH.2.11.1608102344080.10662@mail.ewheeler.net \
    --to=bcache@lists.ewheeler.net \
    --cc=axboe@fb.com \
    --cc=jmoyer@redhat.com \
    --cc=kent.overstreet@gmail.com \
    --cc=linux-bcache@vger.kernel.org \
    --cc=linux-block@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;
as well as URLs for NNTP newsgroup(s).