On Thu, Jul 10, 2025 at 01:22:59PM -0400, Mike Snitzer wrote: > On Thu, Jul 10, 2025 at 10:29:22AM -0600, Keith Busch wrote: > > The trim calculation assumes the current bi_size is already a block size > > multiple, but it may not be with your propsal. So the trim bytes needs > > to take into account the existing bi_size to know how much to trim off > > to arrive at a proper total bi_size instead of assuming we can append a > > block sized multiple carved out the current iov. > > The trim "calculation" doesn't assume anything, it just lops off > whatever is past the end of the last logical_block_size aligned > boundary of the requested pages (which is meant to be bi_size). The > fact that the trim ever gets anything implies bi_size is *not* always > logical_block_size aligned. No? No. The iov must be a block size, but if it spans more pages than the bio can hold (because of bi_max_vecs), the total size of the pages gotten is only part of iov. That's the case that 'trim' is trying to handle, as we only got part of the iov, so it's aligned down to make sure the next iteration can consider perfectly block size aligned iovecs. At every step of iovec iteration, the bio's bi_size is a block size multiple. Let's say we tried to allow smaller vecs. Assume block size of 512 bytes, and you send a direct IO with 4 vecs of 128 bytes each. That would normally get rejected very early, but if you did send that to the bio layer, the entirety of the first iov would get trimmed off and you should get an EFAULT return.
