Re: [PATCH] NULL pointer in raid1_make_request passed to bio_trim when adding md as bcache caching dev

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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@xxxxxx>
> 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@xxxxxx>
> 
> 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@xxxxxxxxxxxxxxx
> 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@xxxxxxxxxxxxxxx
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 
--
To unsubscribe from this list: send the line "unsubscribe linux-raid" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html



[Index of Archives]     [Linux RAID Wiki]     [ATA RAID]     [Linux SCSI Target Infrastructure]     [Linux Block]     [Linux IDE]     [Linux SCSI]     [Linux Hams]     [Device Mapper]     [Device Mapper Cryptographics]     [Kernel]     [Linux Admin]     [Linux Net]     [GFS]     [RPM]     [git]     [Yosemite Forum]


  Powered by Linux