On Sun, Jan 3, 2010 at 11:48 PM, Josh Triplett <josh@xxxxxxxxxxxxxxxx> wrote:
>> void fction(int a)
>> {
>> lock();
>> lock();
>> unlock();
>> unlock();
>> }
>> Sparse gives no warning in this code - I would expect that second call
>> to lock() would violate the 'in' limit of __acquires attribute, but it
>> does not. I'm wondering if this is actually a problem in sparse, or am I
>> doing something wrong?
Sorry I am late to the party. I think sparse does not complain on this
code because sparse has no way to track *which* lock it is taking.
Some thing like:
lock(A);
lock(B);
unlock(B);
unlock(A);
It is perfectly fine. So sparse is not suppose to complain there.
> As far as I know, Sparse currently treats the "in" context as a minimum
> requirement, not an exact requirement. Thus, a context of 0 ends up
> meaning "may or may not hold the lock", while 1 means "must hold the
> lock at least once".
You can interpret it that way, but that is not how I see it.
The context is not suppose to go to negative, that is why we have 'in' and 'out'
context. When a function perform unlock, you are suppose to give a
positive value in
'in' context to avoid geting negative. As long as the context does not
go negative,
sparse only care about the delta of 'in' and 'out' value. It counts
the context to
the exact number. See the following code:
if (insn->opcode == OP_RET)
return entry != exit ? imbalance(ep, bb, entry, exit, "wrong count
at exit") : 0;
So I don't think it is a bug. If you disagree, please give me more detail.
Chris
--
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
