From: Nathan Scott <nathans@sgi.com>
To: Yichen Xie <yxie@cs.stanford.edu>
Cc: linux-kernel@vger.kernel.org
Subject: Re: [BUGS] [CHECKER] 99 synchronization bugs and a lock summary database
Date: Fri, 2 Jul 2004 14:35:24 +1000 [thread overview]
Message-ID: <20040702043524.GA1203@frodo> (raw)
In-Reply-To: <Pine.LNX.4.44.0407011747040.4015-100000@kaki.stanford.edu>
On Thu, Jul 01, 2004 at 06:01:00PM -0700, Yichen Xie wrote:
> Hi all,
Hi there,
> We are a group of researchers at Stanford working on program analysis
> algorithms. We have been building a precision enhanced program analysis
> engine at Stanford, and our first application was to derive mutex/lock
> behavior in the linux kernel. In the process, we found 99 likely
> synchronization errors in linux kernel version 2.6.5:
>
> http://glide.stanford.edu/linux-lock/err1.html (69 errors)
> http://glide.stanford.edu/linux-lock/err2.html (30 errors)
>
> ...
>
> As always, feedbacks and confirmations will be greatly appreciated!
>From looking through the XFS reports, I suspect your tools aren't
following the sv_wait semantics correctly (or else I'm misreading
the code). Many of the reported XFS items stem from this - e.g.
this one...
[NOTE] BUG forgot to unlock before "goto try_again" (line 2293)
ERROR: fs/xfs/xfs_log.c:2948: lock check failed!
ERROR: fs/xfs/xfs_log.c:xlog_state_sync
the code in question does this:
try_again:
s = LOG_LOCK(log); /* spin_lock(&log->l_icloglock); */
...
sv_wait(&iclog->ic_prev->ic_writesema, PSWP,
&log->l_icloglock, s);
already_slept = 1;
goto try_again;
and the tools seem to be missing that the log->l_icloglock is
unlocked by the sv_wait routine. Well, that or I've overlooked
something that the tools have not. :)
A couple of the others were definately missed unlocks on error
paths though (fixed now) - thanks!
cheers.
--
Nathan
next prev parent reply other threads:[~2004-07-02 3:38 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-07-02 1:01 [BUGS] [CHECKER] 99 synchronization bugs and a lock summary database Yichen Xie
2004-07-02 4:35 ` Nathan Scott [this message]
2004-07-02 7:06 ` Yichen Xie
2004-07-02 7:44 ` Andrew Morton
2004-07-02 16:48 ` Yichen Xie
2004-07-02 20:42 ` Yichen Xie
2004-07-02 21:12 ` Yichen Xie
2004-07-02 22:50 ` J. Bruce Fields
2004-07-02 23:44 ` Yichen Xie
2004-07-02 4:38 ` Andrew Morton
2004-07-02 7:20 ` Yichen Xie
2004-07-02 7:33 ` Andrew Morton
2004-07-02 7:39 ` Martin Diehl
2004-07-02 10:00 ` Matthias Urlichs
2004-07-02 22:32 ` Andrew Morton
2004-07-02 8:15 ` Andrew Morton
2004-07-02 16:53 ` Yichen Xie
2004-07-02 8:19 ` Andrew Morton
2004-07-02 16:39 ` Yichen Xie
2004-07-02 17:00 ` J. Bruce Fields
2004-07-02 8:47 ` YOSHIFUJI Hideaki / 吉藤英明
-- strict thread matches above, loose matches on Subject: below --
2004-07-02 7:49 Fw: " Andrew Morton
2004-07-02 11:04 ` Herbert Xu
2004-07-02 19:30 ` Andrew Morton
2004-07-02 19:50 ` Stephen Hemminger
2004-07-03 5:42 ` OGAWA Hirofumi
2004-07-03 6:13 ` Herbert Xu
2004-07-03 8:03 ` OGAWA Hirofumi
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=20040702043524.GA1203@frodo \
--to=nathans@sgi.com \
--cc=linux-kernel@vger.kernel.org \
--cc=yxie@cs.stanford.edu \
/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.