On Fri, Apr 6, 2018 at 8:50 PM, Mauro Carvalho Chehab
<mchehab@xxxxxxxxxx> wrote:
>
> duplicating everything doesn't sound right. Ok, we might implement
> a __ddb_output_start() function with everything but the lock,
> then a new ddb_output_start() with just:
Yes. That should avoid the warning and share the code.
And if the shared code is small, inlining will automatically do the
right thing. And if the shared code is large, the small wrapper to get
locking right won't be a big deal.
Of course, you *can* just choose to say that sparse doesn't understand
the code, and ignore the warnings. It's true. But if you are otherwise
sparse-clean, maybe just making sparse happy here too is a good idea.
It does force you to try to think about locking a bit, and it does
tend to make the locking easier to follow even for humans. Having a
lock taken in one context and then released in some other context can
be confusing even if you aren't sparse.
So it's often just nicer if you see "unconditional lock" + some locked
code + "unconditional unlock" instead of having conditions that you
can get wrong.
It's just that sparse really *requires* that pattern in order to
understand locks.
Linus
--
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
