On Mon, Feb 05, 2024 at 10:48:14AM -0500, Brian Foster wrote: > bch2_direct_IO_read() checks the request offset and size for sector > alignment and then falls through to a couple calculations to shrink > the size of the request based on the inode size. The problem is that > these checks round up to the fs block size, which runs the risk of > underflowing iter->count if the block size happens to be large > enough. This is triggered by fstest generic/361 with a 4k block > size, which subsequently leads to a crash. > > After some discussion, the original purpose of the shorten logic in this > path is not totally clear. It appears to be intended as an optimization > of limited value, so simplify things and avoid the underflow problem by > removing it.
Thinking about this a bit more... All that we're avoiding with the shorten is zeroing out the rest of the read, which will happen in bch2_read_extent(); we won't be issuing any IO, since that would require real data extents above i_size, which is of course not allowed. But zeroing out the rest of the read is actual work that's being avoided, since if we return a short read (which is what we're doing here) it's undefined what happens to the rest of the buffer. So... maybe we should keep it, for the crazy but inevitable application that uses a 1MB read buffer for everything, including O_DIRECT reads to 4k files?
