On Wed, Jun 19, 2024 at 08:04:18AM +0530, Kundan Kumar wrote: > /** > - * bio_add_hw_page - attempt to add a page to a bio with hw constraints > + * bio_add_hw_page - a wrapper around function bio_add_hw_folio No. You haven't changed what this function does, merely how it is implemented. The reader of the API documentation doesn't care about the implementation, they just need to know what it does. > * @q: the target queue > * @bio: destination bio > * @page: page to add > @@ -972,13 +972,35 @@ bool bvec_try_merge_hw_page(struct request_queue *q, struct bio_vec *bv, > * @offset: vec entry offset > * @max_sectors: maximum number of sectors that can be added > * @same_page: return if the segment has been merged inside the same page > - * > - * Add a page to a bio while respecting the hardware max_sectors, max_segment > - * and gap limitations. Likewise. > +/** > + * bio_add_hw_folio - attempt to add a folio to a bio with hw constraints > + * @q: the target queue > + * @bio: destination bio > + * @folio: folio to add > + * @len: vec entry length > + * @offset: vec entry offset in the folio > + * @max_sectors: maximum number of sectors that can be added > + * @same_page: return if the segment has been merged inside the same page ... page? > + * Add a folio to a bio while respecting the hardware max_sectors, max_segment > + * and gap limitations. > + */ > +int bio_add_hw_folio(struct request_queue *q, struct bio *bio, > + struct folio *folio, unsigned int len, unsigned int offset, size_t for both of these parameters. We're dangerously close to overflowing unsigned int (arm64 gets to 512MB folios, which is only 3 bits from 4GB).
