I just noticed this with some obviously correct code... and verified
that it's a regression in current GIT version of "sparse" since it
now rejects code which previously passed just fine.
The issue is a not-uncommon idiom, where a function must be called
with a lock held, and briefly drops it. The way this has previously
been addressed, originally suggested by Linus and used in various
places in the kernel (but, I observe, not in the "sparse" internal
validation test cases) is:
static void
finish_urb(struct ohci_hcd *ohci, struct urb *urb, int status)
__releases(ohci->lock)
__acquires(ohci->lock)
{
...
}
But current versions of "sparse" complain (wrongly):
drivers/usb/host/ohci-q.c:66:2: warning: context imbalance in 'finish_urb': __context__ statement expected different context
drivers/usb/host/ohci-q.c:66:2: context '<noident>': wanted >= 0, got -1
Presumably this is this a known bug ... is a fix on the way?
(Meanwhile, I can just ignore this bogus output.)
- Dave
--
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
