From: Mark Fasheh <mfasheh@suse.de>
To: ocfs2-devel@oss.oracle.com
Subject: [Ocfs2-devel] [patch 04/15] ocfs2: avoid access invalid address when read o2dlm debug messages
Date: Fri, 19 Dec 2014 12:25:03 -0800 [thread overview]
Message-ID: <20141219202503.GX7238@wotan.suse.de> (raw)
In-Reply-To: <5493E31F.2000509@huawei.com>
On Fri, Dec 19, 2014 at 04:34:39PM +0800, jiangyiwen wrote:
> ? 2014/12/17 6:26, Mark Fasheh ??:
> > On Mon, Dec 15, 2014 at 02:51:00PM -0800, Andrew Morton wrote:
> >> In such a race case, invalid address access may occurs. So we should
> >> delete list res->tracking before resA->refs decrease to 0.
> >>
> >
> >
> >> diff -puN fs/ocfs2/dlm/dlmmaster.c~ocfs2-avoid-access-invalid-address-when-read-o2dlm-debug-messages fs/ocfs2/dlm/dlmmaster.c
> >> --- a/fs/ocfs2/dlm/dlmmaster.c~ocfs2-avoid-access-invalid-address-when-read-o2dlm-debug-messages
> >> +++ a/fs/ocfs2/dlm/dlmmaster.c
> >> @@ -498,16 +498,6 @@ static void dlm_lockres_release(struct k
> >> mlog(0, "destroying lockres %.*s\n", res->lockname.len,
> >> res->lockname.name);
> >>
> >> - spin_lock(&dlm->track_lock);
> >> - if (!list_empty(&res->tracking))
> >> - list_del_init(&res->tracking);
> >> - else {
> >> - mlog(ML_ERROR, "Resource %.*s not on the Tracking list\n",
> >> - res->lockname.len, res->lockname.name);
> >> - dlm_print_one_lock_resource(res);
> >> - }
> >> - spin_unlock(&dlm->track_lock);
> >> -
> >> atomic_dec(&dlm->res_cur_count);
> >>
> >> if (!hlist_unhashed(&res->hash_node) ||
> >> diff -puN fs/ocfs2/dlm/dlmthread.c~ocfs2-avoid-access-invalid-address-when-read-o2dlm-debug-messages fs/ocfs2/dlm/dlmthread.c
> >> --- a/fs/ocfs2/dlm/dlmthread.c~ocfs2-avoid-access-invalid-address-when-read-o2dlm-debug-messages
> >> +++ a/fs/ocfs2/dlm/dlmthread.c
> >> @@ -211,6 +211,16 @@ static void dlm_purge_lockres(struct dlm
> >>
> >> __dlm_unhash_lockres(dlm, res);
> >>
> >> + spin_lock(&dlm->track_lock);
> >> + if (!list_empty(&res->tracking))
> >> + list_del_init(&res->tracking);
> >> + else {
> >> + mlog(ML_ERROR, "Resource %.*s not on the Tracking list\n",
> >> + res->lockname.len, res->lockname.name);
> >> + __dlm_print_one_lock_resource(res);
> >> + }
> >> + spin_unlock(&dlm->track_lock);
> >> +
> >> /* lockres is not in the hash now. drop the flag and wake up
> >> * any processes waiting in dlm_get_lock_resource. */
> >> if (!master) {
> >> _
> >
> > How do we know that dlm_purge_lockres() is the last caller of
> > dlm_lockres_put()? Don't we now have a problem where if the last ref is
> > dropped by any other function than dlm_purge_lockres() the lockres is freed
> > while on the tracking list?
> > --Mark
> >
> > --
> > Mark Fasheh
> >
> > .
> >
> dlm_purge_lockres is not necessarily the last caller of
> dlm_lockres_put(), but it means lockres will be purged if
> dlm_purge_lockres is called. Besides, lockres is also unhashed in
> dlm_purge_lockres, so lockres can be removed from tracking list.
> contents of dlm->tracking_list will be consistent with
> dlm->lockres_hash.
I'm still confused. This is what I'm worried about:
1) a procss calls dlm_lockres_put(), NOT from dlm_purge_lockres().
2) if the count goes to zero, then that process will call dlm_lockres_release()
3) dlm_lockres_release() will free the lockres without removing it from the
tracking list. Thus we will have a corrupted list.
Does that make sense? Am I wrong here?
--Mark
--
Mark Fasheh
next prev parent reply other threads:[~2014-12-19 20:25 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-12-15 22:51 [Ocfs2-devel] [patch 04/15] ocfs2: avoid access invalid address when read o2dlm debug messages akpm at linux-foundation.org
2014-12-16 22:26 ` Mark Fasheh
2014-12-19 8:34 ` jiangyiwen
2014-12-19 20:25 ` Mark Fasheh [this message]
2014-12-20 9:39 ` jiangyiwen
2014-12-23 6:06 ` Xue jiufei
2014-12-24 9:08 ` jiangyiwen
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=20141219202503.GX7238@wotan.suse.de \
--to=mfasheh@suse.de \
--cc=ocfs2-devel@oss.oracle.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).