From: Andrew Morton <akpm@linux-foundation.org>
To: Trond Myklebust <Trond.Myklebust@netapp.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>,
linux-nfs@vger.kernel.org, linux-kernel@vger.kernel.org,
nfsv4@linux-nfs.org
Subject: Re: [GIT] Please pull 2 NFS client fixes
Date: Thu, 7 Feb 2008 18:48:18 -0800 [thread overview]
Message-ID: <20080207184818.e40d5277.akpm@linux-foundation.org> (raw)
In-Reply-To: <1202432841.18376.50.camel-rJ7iovZKK19ZJLDQqaL3InhyD016LWXt@public.gmane.org>
On Thu, 07 Feb 2008 20:07:21 -0500 Trond Myklebust <Trond.Myklebust@netapp.com> wrote:
> commit 5d47a35600270e7115061cb1320ee60ae9bcb6b8
> Author: Trond Myklebust <Trond.Myklebust@netapp.com>
> Date: Thu Feb 7 17:24:07 2008 -0500
>
> NFS: Fix a potential file corruption issue when writing
>
> If the inode is flagged as having an invalid mapping, then we can't rely on
> the PageUptodate() flag. Ensure that we don't use the "anti-fragmentation"
> write optimisation in nfs_updatepage(), since that will cause NFS to write
> out areas of the page that are no longer guaranteed to be up to date.
>
> A potential corruption could occur in the following scenario:
>
> client 1 client 2
> =============== ===============
> fd=open("f",O_CREAT|O_WRONLY,0644);
> write(fd,"fubar\n",6); // cache last page
> close(fd);
> fd=open("f",O_WRONLY|O_APPEND);
> write(fd,"foo\n",4);
> close(fd);
>
> fd=open("f",O_WRONLY|O_APPEND);
> write(fd,"bar\n",4);
> close(fd);
> -----
> The bug may lead to the file "f" reading 'fubar\n\0\0\0\nbar\n' because
> client 2 does not update the cached page after re-opening the file for
> write. Instead it keeps it marked as PageUptodate() until someone calls
> invaldate_inode_pages2() (typically by calling read()).
Is this one worth feeding back into 2.6.24.x? (for various values of "4"?)
WARNING: multiple messages have this Message-ID (diff)
From: Andrew Morton <akpm@linux-foundation.org>
To: Trond Myklebust <Trond.Myklebust@netapp.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>,
linux-nfs@vger.kernel.org, linux-kernel@vger.kernel.org,
nfsv4@linux-nfs.org
Subject: Re: [GIT] Please pull 2 NFS client fixes
Date: Thu, 7 Feb 2008 18:48:18 -0800 [thread overview]
Message-ID: <20080207184818.e40d5277.akpm@linux-foundation.org> (raw)
In-Reply-To: <1202432841.18376.50.camel@heimdal.trondhjem.org>
On Thu, 07 Feb 2008 20:07:21 -0500 Trond Myklebust <Trond.Myklebust@netapp.com> wrote:
> commit 5d47a35600270e7115061cb1320ee60ae9bcb6b8
> Author: Trond Myklebust <Trond.Myklebust@netapp.com>
> Date: Thu Feb 7 17:24:07 2008 -0500
>
> NFS: Fix a potential file corruption issue when writing
>
> If the inode is flagged as having an invalid mapping, then we can't rely on
> the PageUptodate() flag. Ensure that we don't use the "anti-fragmentation"
> write optimisation in nfs_updatepage(), since that will cause NFS to write
> out areas of the page that are no longer guaranteed to be up to date.
>
> A potential corruption could occur in the following scenario:
>
> client 1 client 2
> =============== ===============
> fd=open("f",O_CREAT|O_WRONLY,0644);
> write(fd,"fubar\n",6); // cache last page
> close(fd);
> fd=open("f",O_WRONLY|O_APPEND);
> write(fd,"foo\n",4);
> close(fd);
>
> fd=open("f",O_WRONLY|O_APPEND);
> write(fd,"bar\n",4);
> close(fd);
> -----
> The bug may lead to the file "f" reading 'fubar\n\0\0\0\nbar\n' because
> client 2 does not update the cached page after re-opening the file for
> write. Instead it keeps it marked as PageUptodate() until someone calls
> invaldate_inode_pages2() (typically by calling read()).
Is this one worth feeding back into 2.6.24.x? (for various values of "4"?)
next prev parent reply other threads:[~2008-02-08 2:48 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-02-08 1:07 [GIT] Please pull 2 NFS client fixes Trond Myklebust
[not found] ` <1202432841.18376.50.camel-rJ7iovZKK19ZJLDQqaL3InhyD016LWXt@public.gmane.org>
2008-02-08 2:48 ` Andrew Morton [this message]
2008-02-08 2:48 ` Andrew Morton
2008-02-08 4:18 ` Trond Myklebust
2008-02-08 4:18 ` Trond Myklebust
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=20080207184818.e40d5277.akpm@linux-foundation.org \
--to=akpm@linux-foundation.org \
--cc=Trond.Myklebust@netapp.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-nfs@vger.kernel.org \
--cc=nfsv4@linux-nfs.org \
--cc=torvalds@linux-foundation.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 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.