On Wed, 14 May 2014, Carlos O'Donell wrote:
> On 05/14/2014 05:22 AM, Peter Zijlstra wrote:
> >>> I believe the thinking goes that if we get to here, then the lock is in an
> >>> inconsistent state (between kernel and userspace). I don't have an answer
> >>> for
> >>> why pausing forever would be preferable to returning an error however...
> >>
> >> What error would we return?
> >
> > EDEADLK is a valid user return for pthread_mutex_lock() as per:
> >
> >
> > http://pubs.opengroup.org/onlinepubs/009695399/functions/pthread_mutex_lock.html
>
> How is that correct? It isn't a deadlock we've detected but inconsistent
> state between glibc and the kernel. In this case glibc should assert.
> Delaying indefinitely with pause() never seems correct (despite that being
> what we do today).
If there is inconsistent state detected then the kernel will return
-EPERM or -EINVAL. So lets put inconsistent state aside.
In glibc you only can detect the simple AA dead lock, i.e lock owner
tries to lock the lock it owns again. Trivial, right ?
But glibc has no idea which lock chains are involved and might lead to
a dead lock caused by nested locking, simplest and most popular being
ABBA.
The kernel can (if the implementation is fixed, patch is available
already) very well detect ABBA and even more complex nested lock
deadlocks. So it rightfully returns -EDEADLK and that is completely
correct versus the spec and the call site can do something about it.
And that's not different from the glibc detected AA deadlock at
all. It's just detected by a different mechanism.
On kernel side we currently provide this service only for the PI
futexes because we have a kernel side state representation as long as
the user space state is not corrupted.
Back then when it was implemented the dead lock detection actually
worked and was agreed on by both sides - kernel and glibc - to be
usefull and essential to the whole endavour.
Hope that helps.
Thanks,
tglx
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
