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