From: Menyhart Zoltan <Zoltan.Menyhart@bull.net>
To: linux-nfs@vger.kernel.org
Subject: Locking question around "...PagePrivate()"
Date: Mon, 20 Sep 2010 14:49:19 +0200 [thread overview]
Message-ID: <4C97584F.4020104@bull.net> (raw)
In-Reply-To: <4C7E4469.70807@duchatelet.net>
Hi,
nfs_inode_add_request() runs under the protection of the Page Lock
while setting up SetPagePrivate(), set_page_private().
The consumers of PagePrivate() run also under the protection of the Page Lock.
On the other hand, nfs_inode_remove_request() invoked by
nfs_writeback_release_full() and nfs_commit_release() apparently does
not take the Page Lock.
nfs_inode_remove_request() includes the sequence of
set_page_private(req->wb_page, 0);
ClearPagePrivate(req->wb_page);
When the base kernel calls e.g.
mapping->a_ops->releasepage(page, gfp_mask)
then nfs_release_page() may see an incoherent "private" state.
Should not all the "private" operations be protected by the Page Lock?
Thanks,
Zoltan Menyhart
next prev parent reply other threads:[~2010-09-20 12:49 UTC|newest]
Thread overview: 46+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-09-01 12:17 Relocate NFS root FS for maintenance Greg
2010-09-01 17:34 ` J. Bruce Fields
2010-09-01 21:52 ` Tom Haynes
2010-09-02 7:32 ` Greg
2010-09-02 16:06 ` J. Bruce Fields
2010-09-07 6:59 ` Greg
2010-09-02 6:56 ` statfs() gives ESTALE error Menyhart Zoltan
2010-09-07 18:32 ` Trond Myklebust
2010-09-08 13:33 ` Re :statfs() " Menyhart Zoltan
2010-09-08 20:25 ` Trond Myklebust
2010-09-09 8:12 ` Menyhart Zoltan
2010-09-20 12:49 ` Menyhart Zoltan [this message]
2010-09-20 13:55 ` Locking question around "...PagePrivate()" Trond Myklebust
2010-10-05 8:22 ` "xprt" reference count drops to 0 Menyhart Zoltan
2010-10-21 20:38 ` J. Bruce Fields
2010-10-22 15:00 ` Menyhart Zoltan
2010-10-22 21:20 ` J. Bruce Fields
2010-10-22 23:01 ` J. Bruce Fields
2010-10-22 23:21 ` J. Bruce Fields
2010-10-23 3:32 ` J. Bruce Fields
2010-10-25 1:09 ` J. Bruce Fields
2010-10-25 1:21 ` [PATCH 1/4] svcrpc: never clear XPT_BUSY on dead xprt J. Bruce Fields
2010-10-25 1:43 ` Neil Brown
2010-10-25 20:21 ` J. Bruce Fields
2010-10-25 22:58 ` Neil Brown
2010-10-25 23:03 ` J. Bruce Fields
2010-10-25 23:54 ` Neil Brown
2010-10-26 0:11 ` J. Bruce Fields
2010-10-26 0:28 ` J. Bruce Fields
2010-10-26 0:30 ` J. Bruce Fields
2010-10-26 1:28 ` Neil Brown
2010-10-26 12:59 ` J. Bruce Fields
2010-10-26 16:05 ` J. Bruce Fields
2010-11-12 19:00 ` J. Bruce Fields
2010-10-25 1:21 ` [PATCH 2/4] svcrpc: assume svc_delete_xprt() called only once J. Bruce Fields
2010-10-25 1:21 ` [PATCH 3/4] svcrpc: no need for XPT_DEAD check in svc_xprt_enqueue J. Bruce Fields
2010-10-25 1:21 ` [PATCH 4/4] svcrpc: svc_tcp_sendto XTP_DEAD check is redundant J. Bruce Fields
2010-10-25 2:10 ` Neil Brown
2010-10-25 15:03 ` J. Bruce Fields
2010-10-25 17:46 ` J. Bruce Fields
2010-10-25 23:08 ` Neil Brown
2010-10-26 1:33 ` J. Bruce Fields
2010-10-25 23:23 ` Neil Brown
2010-10-26 1:25 ` J. Bruce Fields
2010-10-25 11:56 ` "xprt" reference count drops to 0 Menyhart Zoltan
2010-10-25 14:36 ` J. Bruce Fields
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=4C97584F.4020104@bull.net \
--to=zoltan.menyhart@bull.net \
--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 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.