On 3/3/25 20:49, Caleb Sander Mateos wrote:
On Mon, Mar 3, 2025 at 7:51 AM Pavel Begunkov <asml.silence@xxxxxxxxx> wrote:
...
If I understand correctly, io_import_reg_vec() converts the iovecs to
bio_vecs in place. If an iovec expands to more than one bio_vec (i.e.
crosses a folio boundary), wouldn't the bio_vecs overwrite iovecs that
hadn't been processed yet?
It's handled, obviously, you missed that the vectors are
offset'ed from each other.
>> diff --git a/io_uring/rsrc.c b/io_uring/rsrc.c
index 9b05e614819e..1ec1f5b3e385 100644
--- a/io_uring/rsrc.c
+++ b/io_uring/rsrc.c
...
+ for (; iov_len; offset = 0, bvec_idx++, src_bvec++) {
+ size_t seg_size = min_t(size_t, iov_len,
+ folio_size - offset);
+
+ res_bvec[bvec_idx].bv_page = src_bvec->bv_page;
+ res_bvec[bvec_idx].bv_offset = offset;
+ res_bvec[bvec_idx].bv_len = seg_size;
Could just increment res_bvec to avoid the variable bvec_idx?
I don't see the benefit.
+ for (i = 0; i < nr_iovs; i++)
+ max_segs += (iov[i].iov_len >> shift) + 2;
Sees like this may overestimate a bit. I think something like this
would give the exact number of segments for each iovec?
(((u64)iov_base & folio_mask) + iov_len + folio_mask) >> folio_shift
It's overestimated exactly to avoid a beast like this.
--
Pavel Begunkov
