On 8/13/21 3:49 PM, Christoph Hellwig wrote:
On Fri, Aug 13, 2021 at 02:05:10PM +0800, Guoqing Jiang wrote:
From: Guoqing Jiang <jiangguoqing@xxxxxxxxxx>
We can't split bio with more than BIO_MAX_VECS sectors, otherwise the
below call trace was triggered because we could allocate oversized
write behind bio later.
[ 8.097936] bvec_alloc+0x90/0xc0
[ 8.098934] bio_alloc_bioset+0x1b3/0x260
[ 8.099959] raid1_make_request+0x9ce/0xc50 [raid1]
Which bio_alloc_bioset is this? The one in alloc_behind_master_bio?
Yes, it should be the one since bio_clone_fast calls bio_alloc_bioset
with 0 iovecs.
In which case I think you want to limit the reduction of max_sectors
to just the write behind case, and clearly document what is going on.
Ok, thanks.
In general the size of a bio only depends on the number of vectors, not
the total I/O size. But alloc_behind_master_bio allocates new backing
pages using order 0 allocations, so in this exceptional case the total
size oes actually matter.
While we're at it: this huge memory allocation looks really deadlock
prone.
Hmm, let me think more about it, or could you share your thought? 😉
Thanks,
Guoqing
