From: Trond Myklebust <trondmy@hammerspace.com>
To: "bcodding@redhat.com" <bcodding@redhat.com>
Cc: "anna.schumaker@netapp.com" <anna.schumaker@netapp.com>,
"linux-nfs@vger.kernel.org" <linux-nfs@vger.kernel.org>
Subject: Re: [PATCH] NFS: Don't use page_file_mapping after removing the page
Date: Mon, 4 Feb 2019 21:40:48 +0000 [thread overview]
Message-ID: <602aa0cc867676254cf09d6e329eb6a8f7345920.camel@hammerspace.com> (raw)
In-Reply-To: <628931F4-B625-4430-96FF-268CF926934A@redhat.com>
On Mon, 2019-02-04 at 15:31 -0500, Benjamin Coddington wrote:
> On 4 Feb 2019, at 14:20, Benjamin Coddington wrote:
>
> > On 4 Feb 2019, at 14:07, Benjamin Coddington wrote:
> >
> > > On 4 Feb 2019, at 14:03, Benjamin Coddington wrote:
> > >
> > > > On 4 Feb 2019, at 13:32, Trond Myklebust wrote:
> > > >
> > > > > On Mon, 2019-02-04 at 13:13 -0500, Benjamin Coddington wrote:
> > > > > > If nfs_page_async_flush() removes the page from the
> > > > > > mapping, then we
> > > > > > can't use page_file_mapping() on it as nfs_updatepate() is
> > > > > > wont to do
> > > > > > when receiving an error. Instead, simplify
> > > > > > nfs_zap_mapping() to take
> > > > > > the inode.
> > > > > >
> > > > >
> > > > > Won't this break NFS swap?
> > > >
> > > > I guess it may, but then I wonder: is that a thing that anyone
> > > > does? It
> > > > sounds like a terrible idea..
> > > >
> > > > I'm curious enough though, and doing some research on it.
> > >
> > > There's enough to commits in the tree fixing problem or
> > > supporting swap
> > > on NFS, so I suppose I've just missed all that.
> >
> > So for diskless systems, ah. It makes sense.
> >
> > But does it make any sense to set NFS_INO_INVALID_DATA on a swap
> > file?
> > Does anyone share them?
> >
> > Dazed and confused, but trying to continue..
>
> So if the page is backing a swap file, nfs_zap_mapping() will fail to
> set
> NFS_INO_INVALID_DATA because i_mapping.nrpages will always be 0.
>
> But it looks like NFS has already decided to not care if the mapping
> needs
> revalidation for swap, since we assume /shared/ swap files are
> insane.
>
> So without testing swap on NFS at all, it seems safe.
>
What about the case when the page is in the swap cache? Is that also
safe?
--
Trond Myklebust
Linux NFS client maintainer, Hammerspace
trond.myklebust@hammerspace.com
next prev parent reply other threads:[~2019-02-04 21:40 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-02-04 18:13 [PATCH] NFS: Don't use page_file_mapping after removing the page Benjamin Coddington
2019-02-04 18:32 ` Trond Myklebust
2019-02-04 19:03 ` Benjamin Coddington
2019-02-04 19:07 ` Benjamin Coddington
2019-02-04 19:20 ` Benjamin Coddington
2019-02-04 20:31 ` Benjamin Coddington
2019-02-04 21:40 ` Trond Myklebust [this message]
2019-02-05 10:23 ` Benjamin Coddington
2019-02-06 11:12 ` Benjamin Coddington
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=602aa0cc867676254cf09d6e329eb6a8f7345920.camel@hammerspace.com \
--to=trondmy@hammerspace.com \
--cc=anna.schumaker@netapp.com \
--cc=bcodding@redhat.com \
--cc=linux-nfs@vger.kernel.org \
/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
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).