[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <1291215353.6609.15.camel@heimdal.trondhjem.org>
Date: Wed, 01 Dec 2010 09:55:53 -0500
From: Trond Myklebust <Trond.Myklebust@...app.com>
To: Rik van Riel <riel@...hat.com>
Cc: Linus Torvalds <torvalds@...ux-foundation.org>,
Nick Bowler <nbowler@...iptictech.com>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
linux-nfs@...r.kernel.org
Subject: Re: [PATCH 2/3] NFS: lock the readdir page while it is in use
On Wed, 2010-12-01 at 08:14 -0500, Rik van Riel wrote:
> On 11/30/2010 11:29 PM, Trond Myklebust 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.
>
> Wait, if nfs_readdir_clear_array can clear the page while
> somebody else has a refcount to it, what good is the
> refcount?
Hi Rik
This is readdir, so there should normally be only one process accessing
the page. If that process locks it (we don't have mmap() to worry about,
so page locking is reasonable here) then the scheme is safe.
Note that we do clear Pg_uptodate under the page lock in the latest
version of the releasepage method (patches to be published later today
after I finish testing).
> Why is your .releasepage modifying the data on the page,
> instead of just the metadata in the struct page?
We want to be able to free up the data that is referenced by the array
on the page before the page itself is freed.
Cheers
Trond
--
Trond Myklebust
Linux NFS client maintainer
NetApp
Trond.Myklebust@...app.com
www.netapp.com
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists