linux-nfs.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
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



  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).