[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <YpoCPIdsDrBLdIsV@casper.infradead.org>
Date: Fri, 3 Jun 2022 13:44:44 +0100
From: Matthew Wilcox <willy@...radead.org>
To: Alistair Popple <apopple@...dia.com>
Cc: akpm@...ux-foundation.org, linux-mm@...ck.org,
linux-kernel@...r.kernel.org
Subject: Re: [PATCH] mm/filemap.c: Update comments in filemap_fault()
On Fri, Jun 03, 2022 at 05:12:33PM +1000, Alistair Popple wrote:
> +++ b/mm/filemap.c
> @@ -3168,8 +3168,9 @@ vm_fault_t filemap_fault(struct vm_fault *vmf)
> VM_BUG_ON_FOLIO(!folio_contains(folio, index), folio);
>
> /*
> - * We have a locked page in the page cache, now we need to check
> - * that it's up-to-date. If not, it is going to be due to an error.
> + * We have a locked page in the page cache. Check that it's up-to-date.
> + * If not it is because there was no page in the page cache (only likely
> + * in the case of MADV_RANDOM) or due to error.
The comment is correct, but the code is buggy!
We should be calling page_cache_ra_order() in do_sync_mmap_readahead(),
even if VM_RAND_READ is set (or !ra_pages, or mmap_miss is high).
At least for one page. That would allow us to drop the FGP_FOR_MMAP
flag as page_cache_ra_order() will instantiate a folio for us.
Do you want to write that patch or should I do it?
Powered by blists - more mailing lists