LKML Archive on lore.kernel.org
help / color / mirror / Atom feed
From: Omar Sandoval <osandov@osandov.com>
To: Trond Myklebust <trond.myklebust@primarydata.com>
Cc: Linux NFS Mailing List <linux-nfs@vger.kernel.org>,
Linux Kernel mailing list <linux-kernel@vger.kernel.org>,
Al Viro <viro@zeniv.linux.org.uk>,
Devel FS Linux <linux-fsdevel@vger.kernel.org>
Subject: Re: [PATCH RESEND] nfs: prevent truncate on active swapfile
Date: Fri, 23 Jan 2015 10:24:54 -0800 [thread overview]
Message-ID: <20150123182454.GA6069@mew> (raw)
In-Reply-To: <CAHQdGtRrJe4Z_REFpm=DZBC-KWct9TSKN1ueUW5jGX3qhKUXCA@mail.gmail.com>
On Fri, Jan 23, 2015 at 08:07:41AM -0500, Trond Myklebust wrote:
> On Thu, Jan 22, 2015 at 11:07 PM, Omar Sandoval <osandov@osandov.com> wrote:
> > On Mon, Jan 12, 2015 at 11:43:02AM -0800, Omar Sandoval wrote:
> >> On Sat, Jan 10, 2015 at 05:08:03PM -0500, Trond Myklebust wrote:
> >> > Hi Omar,
> >> >
> >> > On Thu, Jan 8, 2015 at 4:18 AM, Omar Sandoval <osandov@osandov.com> wrote:
> >> > > Most filesystems prevent truncation of an active swapfile by way of
> >> > > inode_newsize_ok, called from inode_change_ok. NFS doesn't call either
> >> > > from nfs_setattr, presumably because most of these checks are expected
> >> > > to be done server-side. However, the IS_SWAPFILE check can only be done
> >> > > client-side, and truncating a swapfile can't possibly be good.
> >> > >
> >> > > Signed-off-by: Omar Sandoval <osandov@osandov.com>
> >> > > ---
> >> > > Hi, Trond,
> >> > >
> >> > > Now that the holidays are over, could you take a look at this? It was
> >> > > generated against v3.19-rc3.
> >> > >
> >> > > Thanks!
> >> > >
> >> > > fs/nfs/inode.c | 7 ++++++-
> >> > > 1 file changed, 6 insertions(+), 1 deletion(-)
> >> > >
> >> > > diff --git a/fs/nfs/inode.c b/fs/nfs/inode.c
> >> > > index 4bffe63..9205513 100644
> >> > > --- a/fs/nfs/inode.c
> >> > > +++ b/fs/nfs/inode.c
> >> > > @@ -506,10 +506,15 @@ nfs_setattr(struct dentry *dentry, struct iattr *attr)
> >> > > attr->ia_valid &= ~ATTR_MODE;
> >> > >
> >> > > if (attr->ia_valid & ATTR_SIZE) {
> >> > > + loff_t i_size;
> >> > > +
> >> > > BUG_ON(!S_ISREG(inode->i_mode));
> >> > >
> >> > > - if (attr->ia_size == i_size_read(inode))
> >> > > + i_size = i_size_read(inode);
> >> > > + if (attr->ia_size == i_size)
> >> > > attr->ia_valid &= ~ATTR_SIZE;
> >> > > + else if (attr->ia_size < i_size && IS_SWAPFILE(inode))
> >> > > + return -ETXTBSY;
> >> > > }
> >> > >
> >> > > /* Optimization: if the end result is no change, don't RPC */
> >> > > --
> >> > > 2.2.1
> >> > >
> >> >
> >> > I agree that truncating a swap file is bad, however as you point out,
> >> > this really only addresses the case on the client that knows about
> >> > this being a swap file.
> >> > I'll take the patch,
> >>
> >> Thanks, I appreciate it.
> >>
> >> > but I'm wondering if we couldn't do better in the
> >> > case where we're using NFSv4 by using share deny modes (which are
> >> > enforced by the server). The problem is that there appears to be
> >> > nothing in swapon() that tells the filesystem this is an open of a
> >> > swap file...
> >>
> >> Yeah, it would be nice for completeness to prevent one client from
> >> truncating another client's swapfile. However, I'd hope that anyone
> >> using swap-over-NFS on a shared NFS mount would take the necessary
> >> precautions in terms of permissions, etc. to prevent someone from doing
> >> that. Also, since the failure mode of truncating an NFS swapfile is a
> >> corrupt swapfile rather than a corrupt filesystem (like on a local
> >> filesystem), it's probably okay to just deal with the low-hanging fruit
> >> for now.
> >>
> >> Thanks!
> >>
> >> >
> >> > Cheers
> >> > Trond
> >> > --
> >> > Trond Myklebust
> >> > Linux NFS client maintainer, PrimaryData
> >> > trond.myklebust@primarydata.com
> >>
> >> --
> >> Omar
> >
> > Hi, Trond,
> >
> > Are you still planning on taking this patch? I didn't see it in your
> > last pull request to Linus.
>
> I was planning on pushing it in the 3.20 merge window.
>
> Is there any reason to fasttrack it earlier as an important bugfix? To
> me it seems more like an "assist user to not shoot self in foot" type
> of thing.
>
> Cheers
> Trond
>
> --
> Trond Myklebust
> Linux NFS client maintainer, PrimaryData
> trond.myklebust@primarydata.com
Ah, okay, 3.20 should be fine.
Thanks,
--
Omar
prev parent reply other threads:[~2015-01-23 18:25 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-01-08 9:18 Omar Sandoval
2015-01-10 22:08 ` Trond Myklebust
2015-01-12 19:43 ` Omar Sandoval
2015-01-23 4:07 ` Omar Sandoval
2015-01-23 13:07 ` Trond Myklebust
2015-01-23 18:24 ` Omar Sandoval [this message]
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=20150123182454.GA6069@mew \
--to=osandov@osandov.com \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-nfs@vger.kernel.org \
--cc=trond.myklebust@primarydata.com \
--cc=viro@zeniv.linux.org.uk \
--subject='Re: [PATCH RESEND] nfs: prevent truncate on active swapfile' \
/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 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).