On Fri, Feb 24, 2017 at 10:57:07AM -0800, Josh Triplett wrote:
> On Fri, Feb 24, 2017 at 10:07:59AM -0800, Matthew Wilcox wrote:
> > I was recently sent some code that looked like this:
> >
> > int foo()
> > {
> > lock();
> > return bar();
> > unlock();
> > }
> >
> > When you're restructuring code that contains locks, this is a
> > *really* easy mistake to make. I've done it myself. But there's no
> > compiler warning for it! gcc doesn't have it, sparse doesn't have it.
>
> Sparse does have a warning (via -Wcontext) for this, if you annotate
> lock() and unlock() with __acquires(somelock) and __releases(somelock),
> which expand to __attribute__((context(somelock,0,1))) and
> __attribute__((context(somelock,0,1))) respectively. You'll get a
> warning that foo() returns with the lock held.
>
> Not at all perfect, but it does have reasonable handling of
> conditionals, including a way to handle cond_lock().
Absolutely, -Wcontext is even enabled by default.
So with what is done in the kernel, you have something like:
#define __acquires(x) __attribute__((context(x,0,1)))
#define __releases(x) __attribute__((context(x,1,0)))
void lock(void) __acquires(lock);
void unlock(void) __releases(lock);
int bar(void);
static int foo(void)
{
lock();
return bar();
unlock();
}
For which sparse returns the following warning:
zz.c:9:5: warning: context imbalance in 'foo' - wrong count at exit
But of course, that's just for code properly lock/context annotated and I'm
not sure if what you're asking, which is much more general, is only motivated
by lock/unlock problems or by others problems too.
Luc Van Oostenryck
--
To unsubscribe from this list: send the line "unsubscribe linux-sparse" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
