Re: sparse context warning problem ...

[Johannes Berg <johannes@sipsolutions.net>]

[-- Attachment #1: Type: text/plain, Size: 1745 bytes --]


> I used the OHCI example because it was a clear and readily
> available/reproducible example of how this is a regression;
> but I came across the problem with a different driver.  In
> that driver, I just made sure that the strings were now
> identical ... and the failures still came up with "sparse".
> 
> That's on a UP build.  (Albeit with PREEMPT and all the
> debug options available ... since I'm debugging!)

I guess you get the spinlock_api_up.h version when building w/o SMP and
w/o CONFIG_DEBUG_SPINLOCK, but it doesn't really matter. The mismatch is
there one way or another.

> Yeah, well the lock being acquired or released *IS* "ohci->lock",
> but the spinlock calls don't take the lock, they take pointers
> to it!
> 
> If you were to argue that understanding pointers like that is a
> lot to demand of "sparse", I might agree.  But that won't change
> the fact that locks themselves are not pointers to locks.  ;)

Well, yes, but for purposes of comparing the expression it would be a
lot simpler to change the code since otherwise sparse would have to be
aware of whether a function takes a pointer to a lock or not. I don't
see why one couldn't use the context tracking stuff for something not
passed via pointers when the callee doesn't need to take/modify the
context.

> > Ultimately, this whole problem comes from the fact that sparse accepted
> > adding an expression, documented it, but never complained if they
> > slightly mismatched as above.
> 
> This still doesn't quite add up, though...

?

Take this to an old sparse:

__acquire(FOO);
__release(BAR);

and it will not complain about a context violation. My patches attempt
to change that, with fallouts.

johannes

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 828 bytes --]