From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 4FC37C636D3 for ; Thu, 9 Feb 2023 04:14:11 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229468AbjBIEOJ (ORCPT ); Wed, 8 Feb 2023 23:14:09 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:58116 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229450AbjBIEOJ (ORCPT ); Wed, 8 Feb 2023 23:14:09 -0500 Received: from ams.source.kernel.org (ams.source.kernel.org [145.40.68.75]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 462FD37B46; Wed, 8 Feb 2023 20:13:22 -0800 (PST) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ams.source.kernel.org (Postfix) with ESMTPS id 813B3B8164F; Thu, 9 Feb 2023 04:11:35 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 1B67BC433D2; Thu, 9 Feb 2023 04:11:34 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linux-foundation.org; s=korg; t=1675915894; bh=RYEtM6aU+aW85+WzpssnI74f+wBUFOV2fCK4BM0NTkU=; h=Date:To:From:Subject:From; b=IKYZJIFOKsbiXbWXmklxuCSq0OcJGCuu5kLdh7fQTwBTDOVcumj95FMH5O8FSKTO2 mE5tT5aWzMZdyNWnfWQURVVDuy3ZwJPoKA/1ESt1pQeUFNvdWZAXyZp0RBkVrQvMlS cqK0iS+iojv7m4Ss5jr6ZcKaTOYekdodRms/s65U= Date: Wed, 08 Feb 2023 20:11:33 -0800 To: mm-commits@vger.kernel.org, willy@infradead.org, stable@vger.kernel.org, qian@ddn.com, akpm@linux-foundation.org From: Andrew Morton Subject: + mm-filemap-fix-page-end-in-filemap_get_read_batch.patch added to mm-hotfixes-unstable branch Message-Id: <20230209041134.1B67BC433D2@smtp.kernel.org> Precedence: bulk Reply-To: linux-kernel@vger.kernel.org List-ID: X-Mailing-List: mm-commits@vger.kernel.org The patch titled Subject: mm/filemap: fix page end in filemap_get_read_batch has been added to the -mm mm-hotfixes-unstable branch. Its filename is mm-filemap-fix-page-end-in-filemap_get_read_batch.patch This patch will shortly appear at https://git.kernel.org/pub/scm/linux/kernel/git/akpm/25-new.git/tree/patches/mm-filemap-fix-page-end-in-filemap_get_read_batch.patch This patch will later appear in the mm-hotfixes-unstable branch at git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm Before you just go and hit "reply", please: a) Consider who else should be cc'ed b) Prefer to cc a suitable mailing list as well c) Ideally: find the original patch on the mailing list and do a reply-to-all to that, adding suitable additional cc's *** Remember to use Documentation/process/submit-checklist.rst when testing your code *** The -mm tree is included into linux-next via the mm-everything branch at git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm and is updated there every 2-3 working days ------------------------------------------------------ From: Qian Yingjin Subject: mm/filemap: fix page end in filemap_get_read_batch Date: Wed, 8 Feb 2023 10:24:00 +0800 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. Link: https://lkml.kernel.org/r/20230208022400.28962-1-coolqyj@163.com Fixes: cbd59c48ae2b ("mm/filemap: use head pages in generic_file_buffered_read") Signed-off-by: Qian Yingjin Reviewed-by: Matthew Wilcox (Oracle) Cc: Signed-off-by: Andrew Morton --- --- a/mm/filemap.c~mm-filemap-fix-page-end-in-filemap_get_read_batch +++ a/mm/filemap.c @@ -2588,18 +2588,19 @@ static int filemap_get_pages(struct kioc struct folio *folio; int err = 0; + /* "last_index" is the index of the page beyond the end of the read */ last_index = DIV_ROUND_UP(iocb->ki_pos + iter->count, PAGE_SIZE); retry: 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)) _ Patches currently in -mm which might be from qian@ddn.com are mm-filemap-fix-page-end-in-filemap_get_read_batch.patch