From: Trond Myklebust <Trond.Myklebust@netapp.com>
To: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Nick Bowler <nbowler@elliptictech.com>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
linux-nfs@vger.kernel.org
Subject: Re: [PATCH 2/3] NFS: lock the readdir page while it is in use
Date: Wed, 01 Dec 2010 09:49:55 -0500 [thread overview]
Message-ID: <1291214995.6609.10.camel@heimdal.trondhjem.org> (raw)
In-Reply-To: <AANLkTi=p8mF2=G8TPi7TciEYS8cyDNp8OG+ksrF7b-vf@mail.gmail.com>
On Tue, 2010-11-30 at 21:06 -0800, Linus Torvalds wrote:
> On Tue, Nov 30, 2010 at 8:29 PM, Trond Myklebust
> <Trond.Myklebust@netapp.com> wrote:
> >
> > I'm not worried about other readdir calls invalidating the page. My
> > concern is rather about the VM memory reclaimers ejecting the page from
> > the page cache, and calling nfs_readdir_clear_array while we're
> > referencing the page.
>
> I think you're making a fundamental mistake here, and you're confused
> by a much deeper problem.
>
> The thing is, the ".releasepage" callback gets called _before_ the
> page actually gets removed from the page cache, and there is no
> guarantee that it will always be removed at all!
>
> In fact, anybody holding a reference to it will result in
> page_freeze_refs() not successfully clearing all the refs, and that in
> turn will abort the actual freeing of the page. So while you hold the
> page count, your page will NOT be freed. Guaranteed.
>
> But it is true that the ".releasepage()" function may be called. So if
> your NFS release callback ends up invalidating the data on that page,
> that page lock thing will make a difference, yes.
>
> But at the same time, are you sure that you are able to then handle
> the case of that page still existing in the page cache and being used
> afterwards? Looking at the code, it doesn't look that way to me.
>
> So I think you're confused, and the NFS code totally incorrectly
> thinks that ".releasepage" is something that happens at the last use
> of the page. It simply is not so. In fact, you seem to return 0, which
> I think means "failure to release", so the VM will just mark it busy
> again afterwards.
>
> Now, I think you do have a few options:
>
> - keep the current model. BUT! In the page cache release function
> (nfs_readdir_clear_array), make sure that you also clear the
> up-to-date bit, so that the page gets read back in since it no longer
> contains any valid information. And return success for the
> "releasepage" operatioin.
This is the option I'm attempting for now. I'm quite fine with the page
only being readable while under the page lock since this is readdir, and
so we don't have to worry about mmap() and its ilk.
My latest incarnation of the patches has added in all the PagePrivate()
foo to make try_to_release_page() work, and also adds in an
invalidatepage() address space operation (I rediscovered that
truncate_inode_pages() will otherwise call block_invalidatepage, and
subsequently Oops).
I'm still in the process of testing, but the latest patchset appears to
be doing all the right things for now. I'll post an update later today
so that Nick and others can test too.
Cheers
Trond
--
Trond Myklebust
Linux NFS client maintainer
NetApp
Trond.Myklebust@netapp.com
www.netapp.com
next prev parent reply other threads:[~2010-12-01 14:50 UTC|newest]
Thread overview: 70+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-11-30 17:42 [PATCH] NFS: Fix a readdirplus bug Trond Myklebust
2010-11-30 22:10 ` Linus Torvalds
2010-11-30 22:13 ` Trond Myklebust
2010-12-01 3:47 ` [PATCH 0/3] Fix more NFS readdir regressions Trond Myklebust
2010-12-01 3:47 ` [PATCH 1/3] NFS: Ensure we use the correct cookie in nfs_readdir_xdr_filler Trond Myklebust
2010-12-01 15:04 ` Nick Bowler
2010-12-01 15:36 ` [PATCH v2 0/3] Fix more NFS readdir regressions Trond Myklebust
2010-12-01 15:36 ` [PATCH v2 1/3] NFS: Ensure we use the correct cookie in nfs_readdir_xdr_filler Trond Myklebust
2010-12-01 15:36 ` [PATCH v2 2/3] NFS: lock the readdir page while it is in use Trond Myklebust
2010-12-01 15:36 ` [PATCH v2 3/3] NFS: Fix a memory leak in nfs_readdir Trond Myklebust
2010-12-01 16:17 ` Linus Torvalds
2010-12-01 16:35 ` Rik van Riel
2010-12-01 16:45 ` Benny Halevy
2010-12-01 16:47 ` Linus Torvalds
2010-12-01 17:02 ` Rik van Riel
2010-12-01 17:58 ` Trond Myklebust
2010-12-01 18:29 ` Miklos Szeredi
2010-12-01 18:54 ` Trond Myklebust
2010-12-01 19:23 ` Hugh Dickins
2010-12-01 19:52 ` Linus Torvalds
2010-12-01 20:05 ` Trond Myklebust
2010-12-01 20:39 ` Andrew Morton
2010-12-01 21:29 ` Neil Brown
2010-12-01 22:43 ` Andrew Morton
2010-12-01 23:01 ` Neil Brown
2010-12-01 19:47 ` Linus Torvalds
2010-12-01 20:10 ` Trond Myklebust
2010-12-01 20:18 ` Linus Torvalds
2010-12-01 20:31 ` Hugh Dickins
2010-12-01 20:33 ` Andrew Morton
2010-12-01 21:02 ` Hugh Dickins
2010-12-01 21:15 ` Hugh Dickins
2010-12-01 21:38 ` Andrew Morton
2010-12-01 21:51 ` Trond Myklebust
2010-12-01 22:13 ` Andrew Morton
2010-12-01 22:24 ` Linus Torvalds
2010-12-01 22:38 ` Andrew Morton
2010-12-01 22:47 ` Trond Myklebust
2010-12-01 23:21 ` Trond Myklebust
2010-12-01 23:46 ` Andrew Morton
2010-12-01 23:56 ` Trond Myklebust
2010-12-01 23:31 ` Linus Torvalds
2010-12-01 23:36 ` Andrew Morton
2010-12-02 1:05 ` Linus Torvalds
2010-12-02 1:22 ` Andrew Morton
2010-12-02 1:42 ` Linus Torvalds
2010-12-02 2:05 ` Andrew Morton
2010-12-02 3:08 ` [PATCH v3 0/3] Fix more NFS readdir regressions Trond Myklebust
2010-12-02 3:08 ` [PATCH v3 1/3] NFS: Ensure we use the correct cookie in nfs_readdir_xdr_filler Trond Myklebust
2010-12-02 3:08 ` [PATCH v3 2/3] Call the filesystem back whenever a page is removed from the page cache Trond Myklebust
2010-12-02 3:34 ` Hugh Dickins
2010-12-02 3:53 ` Trond Myklebust
2010-12-02 3:58 ` Linus Torvalds
2010-12-06 16:59 ` [PATCH v4 0/3] Fix more NFS readdir regressions Trond Myklebust
2010-12-06 16:59 ` [PATCH v4 1/3] NFS: Ensure we use the correct cookie in nfs_readdir_xdr_filler Trond Myklebust
2010-12-06 16:59 ` [PATCH v4 2/3] Call the filesystem back whenever a page is removed from the page cache Trond Myklebust
2010-12-07 7:08 ` Nick Piggin
2010-12-06 16:59 ` [PATCH v4 3/3] NFS: Fix a memory leak in nfs_readdir Trond Myklebust
2010-12-02 3:08 ` [PATCH v3 " Trond Myklebust
2010-12-03 9:12 ` [PATCH v2 " Nick Piggin
2010-12-01 23:43 ` Trond Myklebust
2010-12-01 22:43 ` Hugh Dickins
2010-12-01 3:47 ` [PATCH 2/3] NFS: lock the readdir page while it is in use Trond Myklebust
2010-12-01 4:10 ` Linus Torvalds
2010-12-01 4:29 ` Trond Myklebust
2010-12-01 5:06 ` Linus Torvalds
2010-12-01 14:49 ` Trond Myklebust [this message]
2010-12-01 13:14 ` Rik van Riel
2010-12-01 14:55 ` Trond Myklebust
2010-12-01 3:47 ` [PATCH 3/3] NFS: Fix a memory leak in nfs_readdir 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=1291214995.6609.10.camel@heimdal.trondhjem.org \
--to=trond.myklebust@netapp.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-nfs@vger.kernel.org \
--cc=nbowler@elliptictech.com \
--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 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).