> 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:
signature.asc
Description: This is a digitally signed message part
