# Re: \[PATCH\] raid1: ensure bio doesn't have more than BIO\_MAX\_VECS sectors

- From: Guoqing Jiang \<hidden\>
- Date: 2021-08-13 08:39:13 
- List: linux-raid
- Page: https://ratatoskr.run/linux-raid/2021/08/6404654
- Thread: https://ratatoskr.run/linux-raid/2021/08/6640555/t.md

```text


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 <redacted>
>>
>> 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
```