Glad I put on my shark repellent. On Sun, 27 Apr 2014 20:20:26 +0200 (CEST) Thomas Gleixner <tglx@xxxxxxxxxxxxx> wrote: > > We really have better things to do, than changing the rules just to > please some random (probably commercial) application which has been > programmed along the coding rules from hell. > Peter had already pointed out that the current behavior is actually specified by the standards. This patch is thus NULL and void. I only posted this patch because you haven't bitched at me in a while and I figured I was due. I just noticed this when we were trying to debug why an application is reporting EDEADLOCK on a lock. This was a side discussion as there were no timeout locks in the application. It looks more like a bug in the glibc implementation, as they have both RECURSIVE and PRIO_INHERIT set on the mutex, and it seems that it is deadlocking on a lock it already owns when it tries to retake it. -- Steve -- To unsubscribe from this list: send the line "unsubscribe linux-rt-users" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
