On 05/10/2013 09:57 AM, Peter Zijlstra wrote:
> So you're doing instance tracking and not creating classes like the kernel
> lockdep does? While that reduces false positives it also greatly reduces the
> effectiveness of lockdep.
>
> The power of lock-classes is that it increases the chance of catching
> potential
> deadlocks without there ever actually being a deadlock.
Originally I had classes working as you've pointed out, until the first time
I've
tried running lockdep on qemu.
They appear to have wrappers for every api call known to man, including all the
posix locking apis.
Basically, instead of directly calling pthread_mutex_lock() for example, there's
a wrapper named qemu_mutex_lock() that calls the api above:
void qemu_mutex_lock(QemuMutex *mutex)
{
int err;
err = pthread_mutex_lock(&mutex->lock);
if (err)
error_exit(err, __func__);
}
So as you might imagine, the first time I ran it my log exploded with warnings.
I've poked around the source of other big projects, and the example above is
somewhat common with projects that wrap everything to be compatible with
different
architectures or apis - which is something that doesn't happen in the kernel.
Thanks,
Sasha
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
