Re: Killing off __cond_lock()

[Johannes Berg <johannes@sipsolutions.net>]

On Mon, 2012-03-26 at 10:11 +0200, Peter Zijlstra wrote:

> > However, note that today sparse doesn't evaluate anything in the
> > context, it doesn't even look at the first argument. So another thing
> > you can't really annotate well is things like this:
> > 
> > struct foo_object *get_locked_object(...);
> > 
> > This is why I used RETURN to give the return value a name, so you could
> > write
> > 	__acquires(&RETURN->lock)
> 
> 
> Right, but if it doesn't actually evaluate the expression used in the
> context this is going to be problematic.

It probably could -- but the question is what context to evaluate it in.

> > But I was also trying to make sparse actually evaluate the first
> > argument so it could tell the difference between two locks, which you
> > might not even care about ... (it would be nice though I think)
> 
> Right, so what I thought we could maybe do is inject code in the
> callsites of these functions.
> 
> So after the OP_CALL emit a piece of code that works like the
> __context__ stmt and can reference the return value that exists at that
> point.
> 
> This also makes the conditional thing quite simple to do.

Indeed, but you'd need some sort of expression rewriting. Consider

void lock_obj(obj_t *o) __acquires(&o->lock);

void lock_obj(obj_t *obj)
{
	__acquire(&obj->lock);

	...
}


void foo(void)
{
	...
	lock_obj(&f);
	...
	unlock_obj(&f);
	...
}


Now you suddenly need to replace "&o->lock" with "&(&f)->lock", when
checking the function itself it really is called "obj", not "o". Not
that sparse actually checks that the function behaviour matches the
declaration today though.

johannes


PS: Something else I had wanted to remind you of: the cond_lock thing
only works due to some sort of optimiser pass (is there such a thing?)
in sparse, sometimes it fails mysteriously because the condition isn't
the exact same condition or something.