[????????? willy@infradead.org ????????? https://aka.ms/LearnAboutSenderIdentification?????????????]

On Wed, Jan 04, 2023 at 11:21:24AM +0800, coolqyj@163.com wrote:
> From: Qian Yingjin <qian@ddn.com>
>
> 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))