Re: [PATCH 1/2] iov_iter: iterate_folioq: fix handling of offset >= folio size

[David Howells <dhowells@redhat.com>]

Dominique Martinet via B4 Relay wrote:

> It's apparently possible to get an iov forwarded all the way up to the

By "forwarded" I presume you mean "advanced"?

> end of the current page we're looking at, e.g.
> 
> (gdb) p *iter
> $24 = {iter_type = 4 '\004', nofault = false, data_source = false, iov_offset = 4096, {__ubuf_iovec = {
>       iov_base = 0xffff88800f5bc000, iov_len = 655}, {{__iov = 0xffff88800f5bc000, kvec = 0xffff88800f5bc000,
>         bvec = 0xffff88800f5bc000, folioq = 0xffff88800f5bc000, xarray = 0xffff88800f5bc000,
>         ubuf = 0xffff88800f5bc000}, count = 655}}, {nr_segs = 2, folioq_slot = 2 '\002', xarray_start = 2}}
> 
> Where iov_offset is 4k with 4k-sized folios
> 
> This should have been because we're only in the 2nd slot and there's
> another one after this, but iterate_folioq should not try to map a
> folio that skips the whole size, and more importantly part here does
> not end up zero (because 'PAGE_SIZE - skip % PAGE_SIZE' ends up
> PAGE_SIZE and not zero..), so skip forward to the "advance to next
> folio" code.

Note that things get complicated because folioqs form a segmented list that
can be under construction as it advances.  So if there's no next folioq
segment at the time you advance to the end of the current one, it will end up
parked at the end of the last folio or with slot==nr_slots because there's
nowhere for it to advance to.  However, the folioq chain can then get
extended, so the advancer has to detect this and move on to the next segment.

Anyway:

Acked-by: David Howells <dhowells@redhat.com>

Note that extract_folioq_to_sg() already does this as does
iov_iter_extract_folioq_pages().