Re: [BUGS] [CHECKER] 99 synchronization bugs and a lock summarydatabase

[Yichen Xie]

Hi Nathan, thanks for the feedback! This is indeed a false alarm. The tool
was able to infer the semantics of _sv_wait, but failed to used it due to
a bug in my checker... Problem fixed now and I will rerun the checker
tonight. I will update the error reports when the results are ready. 
Best,
Yichen

On Fri, 2 Jul 2004, Nathan Scott wrote:

> 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.
> 
> 

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/