On Sun, Apr 25, 2021 at 02:58:02PM +0100, David Howells wrote: > But for the moment, I guess I should just add: > > i->iov_offset += bytes; > > to all three (kvec, bvec and xarray)? No. First of all, you'd need ->count updated as well; for kvec and bvec you *REALLY* don't have to end up with ->iov_offset exceeding the size of current kvec or bvec resp.; Bad Shit(tm) happens that way. > > > > @@ -1246,7 +1349,8 @@ unsigned long iov_iter_alignment(const struct iov_iter *i) > > > iterate_all_kinds(i, size, v, > > > (res |= (unsigned long)v.iov_base | v.iov_len, 0), > > > res |= v.bv_offset | v.bv_len, > > > - res |= (unsigned long)v.iov_base | v.iov_len > > > + res |= (unsigned long)v.iov_base | v.iov_len, > > > + res |= v.bv_offset | v.bv_len > > > ) > > > return res; > > > } > > > > Hmm... That looks like a really bad overkill - do you need anything beyond > > count and iov_offset in that case + perhaps "do we have the very last page"? > > IOW, do you need to iterate anything at all here? What am I missing here? > > Good point. I wonder, even, if the alignment could just be set to 1. There's > no kdoc description on the function that says what the result is meant to > represent. Huh? It's the worst alignment of all segment boundaries, what else? As in if (iov_iter_alignment(i) & 1023) // we have something in there that isn't 1K-aligned. -- Linux-cachefs mailing list Linux-cachefs@xxxxxxxxxx https://listman.redhat.com/mailman/listinfo/linux-cachefs
