Gitweb:
http://git.fedorahosted.org/git/cluster.git?p=cluster.git;a=commitdiff;h=...
Commit: 2f850ac3c4c34a4c972e5f7624694c61cb28d73f
Parent: ca7c9e3bc4dafe47303e90a4a74b76ad29050e39
Author: Abhijith Das <adas(a)redhat.com>
AuthorDate: Tue Sep 22 14:43:52 2009 -0500
Committer: Abhijith Das <adas(a)redhat.com>
CommitterDate: Tue Sep 22 14:43:52 2009 -0500
gfs-kernel: Bug 471258 - fatal: assertion "gfs_glock_is_locked_by_me(gl) &&
gfs_glock_is_held_excl(gl)" failed
Patch to manage racing gfs_creates when selinux is in permissive mode.
With selinux in permissive mode, I've been able to hit this bug pretty easily.
It arises when two processes (on different nodes) race each other to create the
same file. Upon successful creation of the inode, security xattr for it needs
to be written when selinux is in permissive mode.
One of the racing processes creates the inode and succeeds in acquiring an
EXclusive lock on it to set the xattr. The other process fails to actually
create the inode (seeing that it exists by now), and does a lookup (which
returns a SHared lock) instead to complete the operation. However, this process
goes on and incorrectly attempts to write xattr, which fails with the above
assert because it doesn't hold an EX lock on the inode.
The process on the second node should not be attempting to write xattrs since
it did not create the inode in the first place. This patch ensures that.
---
gfs-kernel/src/gfs/ops_inode.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/gfs-kernel/src/gfs/ops_inode.c b/gfs-kernel/src/gfs/ops_inode.c
index bff5aa0..ae836dc 100644
--- a/gfs-kernel/src/gfs/ops_inode.c
+++ b/gfs-kernel/src/gfs/ops_inode.c
@@ -152,7 +152,7 @@ gfs_create(struct inode *dir, struct dentry *dentry,
if (!inode)
error = -ENOMEM;
- else
+ else if (new)
error = gfs_security_init(dip, ip);
gfs_glock_dq_uninit(&d_gh);