On Mon, Jul 01, 2019 at 08:20:13AM -0600, Jens Axboe wrote:
> On 7/1/19 8:14 AM, Jens Axboe wrote:
> > On 7/1/19 8:05 AM, Jens Axboe wrote:
> >> On 7/1/19 1:14 AM, Ming Lei wrote:
> >>> 'bio->bi_iter.bi_size' is 'unsigned int', which at most hold 4G - 1
> >>> bytes.
> >>>
> >>> Before 07173c3ec276 ("block: enable multipage bvecs"), one bio can
> >>> include very limited pages, and usually at most 256, so the fs bio
> >>> size won't be bigger than 1M bytes most of times.
> >>>
> >>> Since we support multi-page bvec, in theory one fs bio really can
> >>> be added > 1M pages, especially in case of hugepage, or big writeback
> >>> with too many dirty pages. Then there is chance in which .bi_size
> >>> is overflowed.
> >>>
> >>> Fixes this issue by using bio_full() to check if the added segment may
> >>> overflow .bi_size.
> >>
> >> Any objections to queuing this up for 5.3? It's not a new regression
> >> this series.
> >
> > I took a closer look, and applied for 5.3 and removed the stable tag.
> > We'll need to apply your patch for stable, and I added an adapted
> > one for 5.3. I don't want a huge merge hassle because of this.
>
> OK, so we still get conflicts with that, due to both the same page
> merge fix, and Christophs 5.3 changes.
>
> I ended up pulling in 5.2-rc6 in for-5.3/block, which resolves at
> least most of it, and kept the stable tag since now it's possible
> to backport without too much trouble.
Thanks for merging it.
BTW, we need the -stable tag, since Yiding has test case to reproduce
the issue reliably, which just needs one big machine with enough memory,
and fast storage, I guess.
thanks,
Ming
