From: Bob Peterson <rpeterso@redhat.com>
To: cluster-devel.redhat.com
Subject: [Cluster-devel] [GFS2 PATCH v2] GFS2: Use local iopen glock holder in gfs2_evict_inode
Date: Thu, 16 Jun 2016 11:11:49 -0400 (EDT) [thread overview]
Message-ID: <919050674.20161154.1466089909280.JavaMail.zimbra@redhat.com> (raw)
In-Reply-To: <801923599.20160945.1466089868074.JavaMail.zimbra@redhat.com>
Hi,
I found a couple problems with the previous version of this patch
during testing. Here is my replacement, version 2.
Patch description:
Before this patch, function gfs2_evict_inode unlocked the iopen
glock (from SH), waited for completion, then locked it again in
EXclusive mode. That's all well and good except that other processes
(not in gfs2_evict_inode) can try to do lookups, and function
gfs2_inode_lookup tries to lock the iopen glock in SH again. This
second lookup can and does wipe out the holder's pid with getpid().
The first putpid (from glock_holder_uninit) will be successful, but
the second one will crash the kernel with:
BUG: unable to handle kernel paging request
This patch introduces a holder variable, io_gh, local to function
gfs2_evict_inode, which will keep its own getpid() and subsequent
putpid() from interfering with one another. So simultaneous inode
lookups won't change the value out from under gfs2_evict_inode.
Signed-off-by: Bob Peterson <rpeterso@redhat.com>
---
fs/gfs2/super.c | 25 ++++++++++++++++---------
1 file changed, 16 insertions(+), 9 deletions(-)
diff --git a/fs/gfs2/super.c b/fs/gfs2/super.c
index 9b2ff353..21a8ba8 100644
--- a/fs/gfs2/super.c
+++ b/fs/gfs2/super.c
@@ -1518,7 +1518,7 @@ static void gfs2_evict_inode(struct inode *inode)
struct super_block *sb = inode->i_sb;
struct gfs2_sbd *sdp = sb->s_fs_info;
struct gfs2_inode *ip = GFS2_I(inode);
- struct gfs2_holder gh;
+ struct gfs2_holder gh, iopen_gh;
struct address_space *metamapping;
int error;
@@ -1527,6 +1527,7 @@ static void gfs2_evict_inode(struct inode *inode)
return;
}
+ memset(&iopen_gh, 0, sizeof(iopen_gh));
if (inode->i_nlink || (sb->s_flags & MS_RDONLY))
goto out;
@@ -1555,9 +1556,15 @@ static void gfs2_evict_inode(struct inode *inode)
test_bit(HIF_HOLDER, &ip->i_iopen_gh.gh_iflags)) {
ip->i_iopen_gh.gh_flags |= GL_NOCACHE;
gfs2_glock_dq_wait(&ip->i_iopen_gh);
- gfs2_holder_reinit(LM_ST_EXCLUSIVE, LM_FLAG_TRY_1CB | GL_NOCACHE,
- &ip->i_iopen_gh);
- error = gfs2_glock_nq(&ip->i_iopen_gh);
+ /* This is subtle: Now we need to uninit the i_iopen_holder,
+ but if we do that before we obtain the new reference with
+ the local holder, the uninit's glock_put will free the
+ glock, which causes the new ref. to crash. So we need to do
+ this in a very specific order. Can't use glock_nq_init. */
+ gfs2_holder_init(ip->i_iopen_gh.gh_gl, LM_ST_EXCLUSIVE,
+ LM_FLAG_TRY_1CB | GL_NOCACHE, &iopen_gh);
+ gfs2_holder_uninit(&ip->i_iopen_gh);
+ error = gfs2_glock_nq(&iopen_gh);
if (error)
goto out_truncate;
}
@@ -1610,12 +1617,12 @@ out_unlock:
if (gfs2_rs_active(&ip->i_res))
gfs2_rs_deltree(&ip->i_res);
- if (ip->i_iopen_gh.gh_gl) {
- if (test_bit(HIF_HOLDER, &ip->i_iopen_gh.gh_iflags)) {
- ip->i_iopen_gh.gh_flags |= GL_NOCACHE;
- gfs2_glock_dq_wait(&ip->i_iopen_gh);
+ if (iopen_gh.gh_gl) {
+ if (test_bit(HIF_HOLDER, &iopen_gh.gh_iflags)) {
+ iopen_gh.gh_flags |= GL_NOCACHE;
+ gfs2_glock_dq_wait(&iopen_gh);
}
- gfs2_holder_uninit(&ip->i_iopen_gh);
+ gfs2_holder_uninit(&iopen_gh);
}
gfs2_glock_dq_uninit(&gh);
if (error && error != GLR_TRYFAILED && error != -EROFS)
next parent reply other threads:[~2016-06-16 15:11 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <801923599.20160945.1466089868074.JavaMail.zimbra@redhat.com>
2016-06-16 15:11 ` Bob Peterson [this message]
2016-06-16 15:51 ` [Cluster-devel] [GFS2 PATCH v2] GFS2: Use local iopen glock holder in gfs2_evict_inode Bob Peterson
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=919050674.20161154.1466089909280.JavaMail.zimbra@redhat.com \
--to=rpeterso@redhat.com \
/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).