On Wed, Jan 04, 2023 at 11:21:24AM +0800, coolqyj@xxxxxxx wrote: > From: Qian Yingjin <qian@xxxxxxx> > > I was running traces of the read code against an RAID storage > system to understand why read requests were being misaligned > against the underlying RAID strips. I found that the page end > offset calculation in filemap_get_read_batch() was off by one. > > When a read is submitted with end offset 1048575, then it > calculates the end page for read of 256 when it should be 255. > "last_index" is the index of the page beyond the end of the read > and it should be skipped when get a batch of pages for read in > @filemap_get_read_batch(). > > The below simple patch fixes the problem. This code was introduced > in kernel 5.12. Thanks for diagnosing & sending a patch. However, I'd really prefer to work in terms of 'max' instead of 'last_index' in that function. Would this work for you? +++ b/mm/filemap.c @@ -2595,13 +2595,13 @@ static int filemap_get_pages(struct kiocb *iocb, struct iov_iter *iter, if (fatal_signal_pending(current)) return -EINTR; - filemap_get_read_batch(mapping, index, last_index, fbatch); + filemap_get_read_batch(mapping, index, last_index - 1, fbatch); if (!folio_batch_count(fbatch)) { if (iocb->ki_flags & IOCB_NOIO) return -EAGAIN; page_cache_sync_readahead(mapping, ra, filp, index, last_index - index); - filemap_get_read_batch(mapping, index, last_index, fbatch); + filemap_get_read_batch(mapping, index, last_index - 1, fbatch); } if (!folio_batch_count(fbatch)) { if (iocb->ki_flags & (IOCB_NOWAIT | IOCB_WAITQ))