From: Matthew Wilcox <email@example.com> To: Andrew Morton <firstname.lastname@example.org> Cc: email@example.com, firstname.lastname@example.org, Kent Overstreet <email@example.com>, Christoph Hellwig <firstname.lastname@example.org> Subject: Re: [PATCH] mm/filemap: Use filemap_read_page in filemap_fault Date: Wed, 3 Mar 2021 20:57:36 +0000 [thread overview] Message-ID: <20210303205736.GG2723601@casper.infradead.org> (raw) In-Reply-To: <email@example.com> On Wed, Mar 03, 2021 at 12:12:53PM -0800, Andrew Morton wrote: > On Wed, 3 Mar 2021 13:26:40 +0000 Matthew Wilcox <firstname.lastname@example.org> wrote: > > > But here's the thing ... invalidate_mapping_pages() doesn't > > ClearPageUptodate. The only places where we ClearPageUptodate is on an > > I/O error. > > yup. > > > So ... as far as I can tell, the only way to hit this is: > > > > - Get an I/O error during the wait > > - Have another thread cause the page to be removed from the page cache > > (eg do direct I/O to the file) before this thread is run. > > > > and the consequence to this change is that we have another attempt to > > read the page instead of returning an error immediately. I'm OK with > > that unintentional change, although I think the previous behaviour was > > also perfectly acceptable (after all, there was an I/O error while trying > > to read this page). > > > > Delving into the linux-fullhistory tree, this code was introduced by ... > > > > commit 56f0d5fe6851037214a041a5cb4fc66199256544 > > Author: Andrew Morton <email@example.com> > > Date: Fri Jan 7 22:03:01 2005 -0800 > > > > [PATCH] readpage-vs-invalidate fix > > > > A while ago we merged a patch which tried to solve a problem wherein a > > concurrent read() and invalidate_inode_pages() would cause the read() to > > return -EIO because invalidate cleared PageUptodate() at the wrong time. > > > > We no longer clear PageUptodate, so I think this is stale code? Perhaps > > you could check with the original author ... > > Which code do you think might be stale? We need the !PageUptodate > check to catch IO errors and we need the !page->mapping check to catch > invalidates. Am a bit confused. I think the check of !page->mapping here: if (PageUptodate(page)) return 0; if (!page->mapping) /* page truncated */ return AOP_TRUNCATED_PAGE; is no longer needed. If we didn't see an error, the page will be Uptodate, regardless of whether it's been removed from the page cache. If we did see an error, it's OK to return -EIO, even if the page has been removed from the page cache in the interim.
next prev parent reply other threads:[~2021-03-04 0:21 UTC|newest] Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top 2021-02-26 14:00 Matthew Wilcox (Oracle) 2021-03-03 1:30 ` Andrew Morton 2021-03-03 1:33 ` Matthew Wilcox 2021-03-03 6:07 ` Andrew Morton 2021-03-03 13:26 ` Matthew Wilcox 2021-03-03 20:12 ` Andrew Morton 2021-03-03 20:57 ` Matthew Wilcox [this message] 2021-03-03 21:51 ` Andrew Morton 2021-03-03 22:31 ` Matthew Wilcox
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=20210303205736.GG2723601@casper.infradead.org \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --subject='Re: [PATCH] mm/filemap: Use filemap_read_page in filemap_fault' \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: link
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.