From: bmarzins@sourceware.org <bmarzins@sourceware.org>
To: cluster-devel.redhat.com
Subject: [Cluster-devel] cluster/gfs-kernel/src/gfs glock.c
Date: 24 Jan 2008 20:08:44 -0000 [thread overview]
Message-ID: <20080124200844.18321.qmail@sourceware.org> (raw)
CVSROOT: /cvs/cluster
Module name: cluster
Branch: RHEL51
Changes by: bmarzins at sourceware.org 2008-01-24 20:08:43
Modified files:
gfs-kernel/src/gfs: glock.c
Log message:
Fix for bz #426291. gfs_glock_dq was traversing the gl_holders list without
holding the gl_spin spinlock, this was causing a problem when the list item
it was currently looking at got removed from the list. The solution is to
not traverse the list, because it is unncessary. Unfortunately, there is also
a bug in this section of code, where you can't guarantee that you will not
cache a glock held with GL_NOCACHE. Fixing this issue requires significantly
more work.
Patches:
http://sourceware.org/cgi-bin/cvsweb.cgi/cluster/gfs-kernel/src/gfs/glock.c.diff?cvsroot=cluster&only_with_tag=RHEL51&r1=1.29.2.5&r2=1.29.2.5.2.1
--- cluster/gfs-kernel/src/gfs/glock.c 2007/06/26 19:42:31 1.29.2.5
+++ cluster/gfs-kernel/src/gfs/glock.c 2008/01/24 20:08:43 1.29.2.5.2.1
@@ -1618,8 +1618,6 @@
struct gfs_sbd *sdp = gl->gl_sbd;
struct gfs_glock_operations *glops = gl->gl_ops;
struct list_head *pos;
- struct gfs_holder *tmp_gh = NULL;
- int count = 0;
atomic_inc(&gl->gl_sbd->sd_glock_dq_calls);
@@ -1630,14 +1628,13 @@
set_bit(GLF_SYNC, &gl->gl_flags);
/* Don't cache glock; request demote to unlock at inter-node scope */
- if (gh->gh_flags & GL_NOCACHE) {
- list_for_each(pos, &gl->gl_holders) {
- tmp_gh = list_entry(pos, struct gfs_holder, gh_list);
- ++count;
- }
- if (tmp_gh == gh && count == 1)
- handle_callback(gl, LM_ST_UNLOCKED);
- }
+ if (gh->gh_flags & GL_NOCACHE && gl->gl_holders.next == &gh->gh_list &&
+ gl->gl_holders.prev == &gh->gh_list)
+ /* There's a race here. If there are two holders, and both
+ * are dq'ed at almost the same time, you can't guarantee that
+ * you will call handle_callback. Fixing this will require
+ * some refactoring */
+ handle_callback(gl, LM_ST_UNLOCKED);
lock_on_glock(gl);
next reply other threads:[~2008-01-24 20:08 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-01-24 20:08 bmarzins [this message]
-- strict thread matches above, loose matches on Subject: below --
2008-01-29 22:21 [Cluster-devel] cluster/gfs-kernel/src/gfs glock.c bmarzins
2008-01-28 6:40 fabbione
2008-01-24 22:23 bmarzins
2008-01-24 20:42 bmarzins
2008-01-24 20:25 bmarzins
2007-06-26 20:39 wcheng
2007-06-26 20:34 wcheng
2007-06-26 19:43 wcheng
2007-06-26 19:42 wcheng
2007-06-26 18:38 wcheng
2007-06-26 18:30 wcheng
2007-06-26 17:50 wcheng
2007-06-26 17:38 wcheng
2007-01-25 22:38 wcheng
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=20080124200844.18321.qmail@sourceware.org \
--to=bmarzins@sourceware.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).