[{"id":3677390,"web_url":"http://patchwork.ozlabs.org/comment/3677390/","msgid":"<52db35a1-7d72-40d5-9c6f-3e5082402c7b@linaro.org>","list_archive_url":null,"date":"2026-04-14T20:14:53","subject":"Re: [PATCH] nptl: futex_lock_pi deadlock detection provides valuable\n information but it is turned into a rather cryptic assertion failure","submitter":{"id":66065,"url":"http://patchwork.ozlabs.org/api/people/66065/","name":"Adhemerval Zanella Netto","email":"adhemerval.zanella@linaro.org"},"content":"On 08/04/26 17:07, Moritz KLAMMLER (FERCHAU) wrote:\n> Thanks for your detailed review. Those additional test support helpers\n> I haven't been aware of do help simplify the code a great amount indeed.\n> \n>>> +#ifndef TST_DEADLK_MUTEX_PI\n>>> +# define TST_DEADLK_MUTEX_PI 0\n>>> +#endif\n>>\n>> Just use the TST_DEADLK_MUTEX_PI=1 and move this test to\n>> tst-deadlk-pi.c.\n> \n> Ah, sorry, I forgot to explain that point in my previous message. I had\n> originally added this configurability based on the assumption that we\n> might want to use it to also test that non-PI mutexes actually do\n> deadlock by making these XFAIL tests, but didn't went as far as actually\n> doing that. However, based on your other feedback ...\n> \n>>> The added test case currently only checks for EDEADLK to be returned,\n>>> but doesn't cover the cases where we still expect the deadlock to\n>>> happen. I could add these as well, but it would introduce an\n>>> (unreasonably?) long delay, waiting for the alarm clock to go off\n>>> eventually. Would you rather take this delay over the lack of test\n>>> coverage? Please also let me know whether having one test executable\n>>> that loops over the various types (current patch) or one executable\n>>> per type would be preferred.\n>>\n>> I would prefer the later (one less binary to build and run). For the\n>> deadlock to happen, it would be better to spawn a new process with\n>> support_capture_subprocess, trigger the deadlock, and wait it with\n>> short delayed_exit value.\n> \n> ... I went ahead and merged everything into a single tst-deadlk.c file\n> which now checks PI and non-PI mutexes alike. Since the number of\n> combinations became quite large, I refactored the test code to remove\n> the explicit list in lieu of some nested loops and a simple\n> should_detect_deadlock predicate function.\n> \n> I've picked 3 s for a delayed_exit value, hoping that this wold be a\n> sensible choice, given that nptl/tst-eintr1.c uses the same (and seems\n> to be the only other NPTL test case currently using delayed_exit).\n> Alas, this makes the test register approx. 30 s on the clock. I've\n> raised the overall timeout (which should never be hit) to 60 s\n> accordingly. Are you okay which such a slow test or do we need to\n> improve on this? We could, for example, do all the waiting for all\n> the subprocesses in parallel, but I'm afraid that it would add quite\n> some complexity. A lower-hanging fruit might be to reduce the delay\n> from 3 s to 1 s, which has worked well for my computer even with high\n> concurrent CPU load, but I'm not sure how universally acceptable it\n> might be.\n> \n> I found that still using alarm(3) in the subprocess and then expecting\n> -SIGALRM in the parent would result in slightly simpler code compared\n> to the delayed_exit but since you recommended it and I've also seen\n> that other test cases have been refactored in the past specifically to\n> replace alarm with delayed_exit, I assume that this is preferred way\n> to go.\n> \n> Looking forward to your feedback on the updated patch.\nCarlos, you brought to my attention that glibc current Error Handling\nguideline [1] states:\n\n \"If it's user code invoking undefined behavior, then it should fail \n early and catastrophically so that developers don't get the false \n impression that their code is OK when it happens not to break the \n use cases they test adequately.\"\n\nHowever, this patch changes the ERRORCHECK and RECURSIVE pthread types \nand, although POSIX only states a *shall fail* for self-deadlock, it does \npermit an error return for multi-mutex deadlock in the *may fail*.\n\nThis change still has the potential to break code that does not handle\nEDEADLK in such cases; however this currently aborts the process anyway.\nSo different than I has said (sorry if I forgot all the details on Monday's\ncall), this is *not* UB and I think that issuing a fatal error like\nfutex_fatal_error is not the course of action here. \n\nThe assert really has not place since kernel does allow to have fast deadlock\ncheck and POSIX allows it.\n\n[1] https://sourceware.org/glibc/wiki/Style_and_Conventions#Error_Handling\n[2] https://pubs.opengroup.org/onlinepubs/9799919799/functions/pthread_mutex_lock.html","headers":{"Return-Path":"","X-Original-To":["incoming@patchwork.ozlabs.org","libc-alpha@sourceware.org"],"Delivered-To":["patchwork-incoming@legolas.ozlabs.org","libc-alpha@sourceware.org"],"Authentication-Results":["legolas.ozlabs.org;\n\tdkim=pass (2048-bit key;\n unprotected) header.d=linaro.org header.i=@linaro.org header.a=rsa-sha256\n header.s=google header.b=ihzKfOKp;\n\tdkim-atps=neutral","legolas.ozlabs.org;\n spf=pass (sender SPF authorized) smtp.mailfrom=sourceware.org\n (client-ip=2620:52:6:3111::32; helo=vm01.sourceware.org;\n envelope-from=libc-alpha-bounces~incoming=patchwork.ozlabs.org@sourceware.org;\n receiver=patchwork.ozlabs.org)","sourceware.org;\n\tdkim=pass (2048-bit key,\n unprotected) header.d=linaro.org header.i=@linaro.org header.a=rsa-sha256\n header.s=google header.b=ihzKfOKp","sourceware.org;\n dmarc=pass (p=none dis=none) header.from=linaro.org","sourceware.org; spf=pass smtp.mailfrom=linaro.org","server2.sourceware.org;\n arc=none smtp.remote-ip=2607:f8b0:4864:20::1334"],"Received":["from vm01.sourceware.org (vm01.sourceware.org\n [IPv6:2620:52:6:3111::32])\n\t(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)\n\t key-exchange x25519 server-signature ECDSA (secp384r1) server-digest SHA384)\n\t(No client certificate requested)\n\tby legolas.ozlabs.org (Postfix) with ESMTPS id 4fwFrV4hvyz1y2d\n\tfor ; Wed, 15 Apr 2026 06:15:22 +1000 (AEST)","from vm01.sourceware.org (localhost [127.0.0.1])\n\tby sourceware.org (Postfix) with ESMTP id D6DC74BA23C0\n\tfor ; Tue, 14 Apr 2026 20:15:20 +0000 (GMT)","from mail-dy1-x1334.google.com (mail-dy1-x1334.google.com\n [IPv6:2607:f8b0:4864:20::1334])\n by sourceware.org (Postfix) with ESMTPS id 122624BA2E08\n for ; Tue, 14 Apr 2026 20:14:58 +0000 (GMT)","by mail-dy1-x1334.google.com with SMTP id\n 5a478bee46e88-2d868d014a5so2856219eec.1\n for ; Tue, 14 Apr 2026 13:14:58 -0700 (PDT)","from ?IPV6:2804:1b3:a7c3:2557:c10c:f31f:5ab:e991?\n ([2804:1b3:a7c3:2557:c10c:f31f:5ab:e991])\n by smtp.gmail.com with ESMTPSA id\n 5a478bee46e88-2de3e05c819sm659133eec.14.2026.04.14.13.14.55\n (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);\n Tue, 14 Apr 2026 13:14:56 -0700 (PDT)"],"DKIM-Filter":["OpenDKIM Filter v2.11.0 sourceware.org D6DC74BA23C0","OpenDKIM Filter v2.11.0 sourceware.org 122624BA2E08"],"DMARC-Filter":"OpenDMARC Filter v1.4.2 sourceware.org 122624BA2E08","ARC-Filter":"OpenARC Filter v1.0.0 sourceware.org 122624BA2E08","ARC-Seal":"i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1776197698; cv=none;\n b=ENON+wP4gjHFUbK3TxcLcn+sZE90y9MQxUntS6we1xP5JG5APzWnaXWLia2EET3LhSSr3iqO+k6WHmPLCfiMFYOIbiW3q062dY4ZRvAtl1CQlGsYmsYomPGjthxyBnyGyYyrDn8g6I6cNujXLWHuqtPHCXVYpIh8tQ1+fCQUQpE=","ARC-Message-Signature":"i=1; a=rsa-sha256; d=sourceware.org; s=key;\n t=1776197698; c=relaxed/simple;\n bh=+Sa+KU06xIpV3KCNzuLnNl55JPz5ESaIrwn9MvSU14k=;\n h=DKIM-Signature:Message-ID:Date:MIME-Version:Subject:To:From;\n b=OwMPMxGWGLqWIKZdrKIgsySmoQFpfwwNSw588BLGoIZBK+s+QBGfb6NvDGpHhFOTo0zctuJOE3dnI6ux1fJSUvAVUlv7DEhn+Yyz/Gl5hHLKdZiq1zHGzwE23kglQ1ssdKXctyUfvmQcWRen82CUHn/c3j0/N/bB8TxUiHtOvI4=","ARC-Authentication-Results":"i=1; server2.sourceware.org","DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed;\n d=linaro.org; s=google; t=1776197697; x=1776802497; darn=sourceware.org;\n h=content-transfer-encoding:in-reply-to:organization:from\n :content-language:references:to:subject:user-agent:mime-version:date\n :message-id:from:to:cc:subject:date:message-id:reply-to;\n bh=6jffH3LY+1u3/B5iho3dxOUHGZ4w1X4B0iVFNgGON/M=;\n b=ihzKfOKpOsPK48fj4UANgypDOjUKu3NGjvhyVzPyLsvoctmkk/54BMsGvzMUzi5B7J\n xWAPbm8VPiTGi+gOHzXNysDEg/XMcGuhx5G4SbIBdDeRrGuMjtM8JVigDbQq61OlC3L3\n Qy2DxcPEE2GqPqXhx3yIS9X8uCp0ApKN/KzAMfMa0aso9lbH1WDJtEbF4yUxWICIDoNP\n a6cVws8OZRFzUoAXvd6e2CLyG/DDo7YlHDL909NN8PU6kKKrtfK3v3TCmHQk+PkbqI8c\n ZnIYp7z1zuFZ4qoGuUAEyhY+t5P2SuKXJAcFacKM5vmvHxij9FnZIB3qHBu+AOJbfa+J\n 1UVQ==","X-Google-DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed;\n d=1e100.net; s=20251104; t=1776197697; x=1776802497;\n h=content-transfer-encoding:in-reply-to:organization:from\n :content-language:references:to:subject:user-agent:mime-version:date\n :message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date\n :message-id:reply-to;\n bh=6jffH3LY+1u3/B5iho3dxOUHGZ4w1X4B0iVFNgGON/M=;\n b=rvtgPjZ91RQIzbDaIhSV1Yx99FSxzAu6DRpHF4l6QT0LpSe4zP3Hq7l4jK1k3n6RIy\n cG8UlZfhDi4Z2nJtl624+UX2drgWPyAABgqLX7iKUY88lzug2+wAo5xJCp0XlECHrBPH\n GPa8Uus4S0KefKAXNsZ9QJwBuvwgVoWxSzXvU2fgcGyQJjV5RJoczXq2/UQzVXWVbCY7\n p4urX7AtgFpNE8OSkPWBfjNyV/nu7RKOSKz95TS+NjtRUL9bZA6nDB6iV6QDlwW4U3v+\n GeWclTr5cXwa8BI8we/edCEvlplpvBygvRUgUMJpSjeNdgXfaaaDRo0mjofPIeyGiHf1\n DOew==","X-Forwarded-Encrypted":"i=1;\n AFNElJ8Gh/jG8GU9xbhtxWMBuEKg++ZDUr7G7x/XgKbcJcfg4fM7k4L9PM6ZtbaCOYWmCHsLRrCVr2y6xyV4@sourceware.org","X-Gm-Message-State":"AOJu0YwS2aGTTnk1Yxx3a8Ud9F+yf7T09EXPUgEYwAIj3jO3WFtKaFqy\n 6AnocvpiDHOtf+rKFp6CDJITtf/3RAb1bsu9qkgygCzfG3Et21GM5EYDf1cCe9LB5hjXLGXhMUY\n QiJp0","X-Gm-Gg":"AeBDietMtcPS8I8ay2s6qSFuf84baImnaq618qbiqp/ay6c/EhfrcgOHxv18g31fyLz\n /KEQqhQq/7+C3kIjNjtRQfhxtT32sGIIGaaf+lRMBu+fm4mjbW0PLpQzeXpnA+eXkCU4ofq2ECe\n zowt3FJa9FxLCRCV74sGtsVq/Ux+0CpeP+RjVmFWXjBCJG4I0FyXjHw1weDENOmJQvUoPTLKmTm\n duY2kJeFE5dgoJeC3Jy0XQxh8o+usQs+qKWhBEmZo+xk9Lnbos3ztpR/CBfTyiuv7fPlVfWwBHf\n hxJjrZPh4FVBAfBqD2d3sGCqKBJ769FPUW4/c7MpWFwj5fK0dNvHJeBoZc/JmvzjtqkXJ1OnlOA\n eFq5xVndoFBMjgOgM97AoF5I4XOXTmt+IPCpeoe5n3AiZiF2GlGpRGJDpthyJ6Sfa3XlgTuxsxU\n 4T6cPDKZILJNtOol6OR5uppzZXcb+ajoA3f+kenptLfehfFKZ83ugEiuVyy73xYqPGIfrNNJ6BQ\n ZN7lUxM2lTgXvwZB7jU5dYmO8ByZasI9mrKwaoiEw==","X-Received":"by 2002:a05:693c:25c7:b0:2c1:558c:16e1 with SMTP id\n 5a478bee46e88-2d58678f385mr11720218eec.4.1776197696906;\n Tue, 14 Apr 2026 13:14:56 -0700 (PDT)","Message-ID":"<52db35a1-7d72-40d5-9c6f-3e5082402c7b@linaro.org>","Date":"Tue, 14 Apr 2026 17:14:53 -0300","MIME-Version":"1.0","User-Agent":"Mozilla Thunderbird","Subject":"Re: [PATCH] nptl: futex_lock_pi deadlock detection provides valuable\n information but it is turned into a rather cryptic assertion failure","To":"\"Moritz KLAMMLER (FERCHAU)\" ,\n \"libc-alpha@sourceware.org\" ,\n Carlos O'Donell ","References":"\n \n <2bf1c649-8a6a-4f9e-9bc7-c01f2fce81c6@linaro.org>\n \n <34621bae-9591-4a43-84f8-245692d31fbc@linaro.org>\n ","Content-Language":"en-US","From":"Adhemerval Zanella Netto ","Organization":"Linaro","In-Reply-To":"\n ","Content-Type":"text/plain; charset=UTF-8","Content-Transfer-Encoding":"7bit","X-BeenThere":"libc-alpha@sourceware.org","X-Mailman-Version":"2.1.30","Precedence":"list","List-Id":"Libc-alpha mailing list ","List-Unsubscribe":",\n ","List-Archive":"","List-Post":"","List-Help":"","List-Subscribe":",\n ","Errors-To":"libc-alpha-bounces~incoming=patchwork.ozlabs.org@sourceware.org"}},{"id":3677399,"web_url":"http://patchwork.ozlabs.org/comment/3677399/","msgid":"<23650a5e-baf4-4811-91f8-6950b1d0a3ed@redhat.com>","list_archive_url":null,"date":"2026-04-14T20:45:37","subject":"Re: [PATCH] nptl: futex_lock_pi deadlock detection provides valuable\n information but it is turned into a rather cryptic assertion failure","submitter":{"id":22438,"url":"http://patchwork.ozlabs.org/api/people/22438/","name":"Carlos O'Donell","email":"carlos@redhat.com"},"content":"On 4/14/26 4:14 PM, Adhemerval Zanella Netto wrote:\n> \n> \n> On 08/04/26 17:07, Moritz KLAMMLER (FERCHAU) wrote:\n>> Thanks for your detailed review. Those additional test support helpers\n>> I haven't been aware of do help simplify the code a great amount indeed.\n>>\n>>>> +#ifndef TST_DEADLK_MUTEX_PI\n>>>> +# define TST_DEADLK_MUTEX_PI 0\n>>>> +#endif\n>>>\n>>> Just use the TST_DEADLK_MUTEX_PI=1 and move this test to\n>>> tst-deadlk-pi.c.\n>>\n>> Ah, sorry, I forgot to explain that point in my previous message. I had\n>> originally added this configurability based on the assumption that we\n>> might want to use it to also test that non-PI mutexes actually do\n>> deadlock by making these XFAIL tests, but didn't went as far as actually\n>> doing that. However, based on your other feedback ...\n>>\n>>>> The added test case currently only checks for EDEADLK to be returned,\n>>>> but doesn't cover the cases where we still expect the deadlock to\n>>>> happen. I could add these as well, but it would introduce an\n>>>> (unreasonably?) long delay, waiting for the alarm clock to go off\n>>>> eventually. Would you rather take this delay over the lack of test\n>>>> coverage? Please also let me know whether having one test executable\n>>>> that loops over the various types (current patch) or one executable\n>>>> per type would be preferred.\n>>>\n>>> I would prefer the later (one less binary to build and run). For the\n>>> deadlock to happen, it would be better to spawn a new process with\n>>> support_capture_subprocess, trigger the deadlock, and wait it with\n>>> short delayed_exit value.\n>>\n>> ... I went ahead and merged everything into a single tst-deadlk.c file\n>> which now checks PI and non-PI mutexes alike. Since the number of\n>> combinations became quite large, I refactored the test code to remove\n>> the explicit list in lieu of some nested loops and a simple\n>> should_detect_deadlock predicate function.\n>>\n>> I've picked 3 s for a delayed_exit value, hoping that this wold be a\n>> sensible choice, given that nptl/tst-eintr1.c uses the same (and seems\n>> to be the only other NPTL test case currently using delayed_exit).\n>> Alas, this makes the test register approx. 30 s on the clock. I've\n>> raised the overall timeout (which should never be hit) to 60 s\n>> accordingly. Are you okay which such a slow test or do we need to\n>> improve on this? We could, for example, do all the waiting for all\n>> the subprocesses in parallel, but I'm afraid that it would add quite\n>> some complexity. A lower-hanging fruit might be to reduce the delay\n>> from 3 s to 1 s, which has worked well for my computer even with high\n>> concurrent CPU load, but I'm not sure how universally acceptable it\n>> might be.\n>>\n>> I found that still using alarm(3) in the subprocess and then expecting\n>> -SIGALRM in the parent would result in slightly simpler code compared\n>> to the delayed_exit but since you recommended it and I've also seen\n>> that other test cases have been refactored in the past specifically to\n>> replace alarm with delayed_exit, I assume that this is preferred way\n>> to go.\n>>\n>> Looking forward to your feedback on the updated patch.\n> Carlos, you brought to my attention that glibc current Error Handling\n> guideline [1] states:\n> \n> \"If it's user code invoking undefined behavior, then it should fail\n> early and catastrophically so that developers don't get the false\n> impression that their code is OK when it happens not to break the\n> use cases they test adequately.\"\n> \n> However, this patch changes the ERRORCHECK and RECURSIVE pthread types\n> and, although POSIX only states a *shall fail* for self-deadlock, it does\n> permit an error return for multi-mutex deadlock in the *may fail*.\n> \n> This change still has the potential to break code that does not handle\n> EDEADLK in such cases; however this currently aborts the process anyway.\n> So different than I has said (sorry if I forgot all the details on Monday's\n> call), this is *not* UB and I think that issuing a fatal error like\n> futex_fatal_error is not the course of action here.\n> \n> The assert really has not place since kernel does allow to have fast deadlock\n> check and POSIX allows it.\n\nIf we aren't triggering undefined behaviour then I think it's perfectly\nacceptable to return a \"may fail\" error to the caller.","headers":{"Return-Path":"","X-Original-To":["incoming@patchwork.ozlabs.org","libc-alpha@sourceware.org"],"Delivered-To":["patchwork-incoming@legolas.ozlabs.org","libc-alpha@sourceware.org"],"Authentication-Results":["legolas.ozlabs.org;\n\tdkim=pass (1024-bit key;\n unprotected) header.d=redhat.com header.i=@redhat.com header.a=rsa-sha256\n header.s=mimecast20190719 header.b=DwZ6W3cE;\n\tdkim-atps=neutral","legolas.ozlabs.org;\n spf=pass (sender SPF authorized) smtp.mailfrom=sourceware.org\n (client-ip=38.145.34.32; helo=vm01.sourceware.org;\n envelope-from=libc-alpha-bounces~incoming=patchwork.ozlabs.org@sourceware.org;\n receiver=patchwork.ozlabs.org)","sourceware.org;\n\tdkim=pass (1024-bit key,\n unprotected) header.d=redhat.com header.i=@redhat.com header.a=rsa-sha256\n header.s=mimecast20190719 header.b=DwZ6W3cE","sourceware.org; dmarc=pass (p=quarantine dis=none)\n header.from=redhat.com","sourceware.org; spf=pass smtp.mailfrom=redhat.com","server2.sourceware.org;\n arc=none smtp.remote-ip=170.10.129.124"],"Received":["from vm01.sourceware.org (vm01.sourceware.org [38.145.34.32])\n\t(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)\n\t key-exchange x25519 server-signature ECDSA (secp384r1) server-digest SHA384)\n\t(No client certificate requested)\n\tby legolas.ozlabs.org (Postfix) with ESMTPS id 4fwGWz642Gz1yCv\n\tfor ; Wed, 15 Apr 2026 06:46:07 +1000 (AEST)","from vm01.sourceware.org (localhost [127.0.0.1])\n\tby sourceware.org (Postfix) with ESMTP id DB3FA4BA2E1C\n\tfor ; Tue, 14 Apr 2026 20:46:05 +0000 (GMT)","from us-smtp-delivery-124.mimecast.com\n (us-smtp-delivery-124.mimecast.com [170.10.129.124])\n by sourceware.org (Postfix) with ESMTP id 17FCD4BA543C\n for ; Tue, 14 Apr 2026 20:45:44 +0000 (GMT)","from mail-qv1-f70.google.com (mail-qv1-f70.google.com\n [209.85.219.70]) by relay.mimecast.com with ESMTP with STARTTLS\n (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id\n us-mta-595-Cn9ruEmCO4KVj_03sylaew-1; Tue, 14 Apr 2026 16:45:40 -0400","by mail-qv1-f70.google.com with SMTP id\n 6a1803df08f44-8a5f6110cadso100931326d6.3\n for ; Tue, 14 Apr 2026 13:45:40 -0700 (PDT)","from [192.168.0.116] ([198.48.244.52])\n by smtp.gmail.com with ESMTPSA id\n 6a1803df08f44-8ac8aea242fsm118021876d6.34.2026.04.14.13.45.38\n (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);\n Tue, 14 Apr 2026 13:45:38 -0700 (PDT)"],"DKIM-Filter":["OpenDKIM Filter v2.11.0 sourceware.org DB3FA4BA2E1C","OpenDKIM Filter v2.11.0 sourceware.org 17FCD4BA543C"],"DMARC-Filter":"OpenDMARC Filter v1.4.2 sourceware.org 17FCD4BA543C","ARC-Filter":"OpenARC Filter v1.0.0 sourceware.org 17FCD4BA543C","ARC-Seal":"i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1776199544; cv=none;\n b=oGxA5ZJYRhNnv6iza0RFXs0Gt+gm38N3mM9Cjo/ATBva09uMdBbdfNcJnPuMUu7Z8Kyt9Xx0SynxjHJetv/XU2npR4uKJRC2nXh3Rmec73zfbXPvcMvqFbQA+ElyObc2iEoFZ9Wh4taQYocjYpYV07gv5nL8Ud21/GtZvZTIg1I=","ARC-Message-Signature":"i=1; a=rsa-sha256; d=sourceware.org; s=key;\n t=1776199544; c=relaxed/simple;\n bh=VszRGD+Ju/L02REaWSs3TH/UF2ELnlgaSWG8Ct3X4Dg=;\n h=DKIM-Signature:Message-ID:Date:MIME-Version:Subject:To:From;\n b=HSrgcp99D14Ki1oCc7PNLgy4WA2gaiOAP7HPR+IXa9O/hUzr4hukFqassD9zlecfq3ekN0QJPqXvChbBUr7kbKHrPOtyRPuLYZyECkcGVZzRIG91sUFDGa/TtEARFUjf4HaUfHlaP/Q5l+5H+JDtVG3zDX1FcoFNDrSNICgU++o=","ARC-Authentication-Results":"i=1; server2.sourceware.org","DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com;\n s=mimecast20190719; t=1776199543;\n h=from:from:reply-to:subject:subject:date:date:message-id:message-id:\n to:to:cc:mime-version:mime-version:content-type:content-type:\n content-transfer-encoding:content-transfer-encoding:\n in-reply-to:in-reply-to:references:references;\n bh=YzGTLodUu7V0v3ktAoi8ayl8pBQ2YllOm4KDhdTqbPY=;\n b=DwZ6W3cEtRkVbjW9MtxSjMrR66X7CHewSEbPMQD/fF1V4f7O0vWM6gvLylR1rP1hUJhAkj\n sCetsSRyYxhrj8hLc2MqQl5QZ+dRzSBWJQdRXYvl+eJhOCoHs1KDZ90F/Ve0d9F9Xb5RoH\n 0L+HJ16Vd8DgOB9Zk4tkRHC7r9X9yOM=","X-MC-Unique":"Cn9ruEmCO4KVj_03sylaew-1","X-Mimecast-MFC-AGG-ID":"Cn9ruEmCO4KVj_03sylaew_1776199540","X-Google-DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed;\n d=1e100.net; s=20251104; t=1776199540; x=1776804340;\n h=content-transfer-encoding:in-reply-to:organization:from\n :content-language:references:to:subject:user-agent:mime-version:date\n :message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date\n :message-id:reply-to;\n bh=YzGTLodUu7V0v3ktAoi8ayl8pBQ2YllOm4KDhdTqbPY=;\n b=T4Q3G/NtKkHYDdZf7I1R4juH52riJn6IRMkLcFMV4rCDjaZy6KiHrcK2iWsmUGYcK1\n SuCFhhJWDfrUZ8DlUNFl0BlM/nJ26GjMYoO2oX7xVFleAl86pj2SR52uJhFhSjnqrfFu\n X0yYhFu1sbVqQaSzUberW+X7K4htm6EyN6dshjOs2WH0HVdTV/mfZWUTMD63NE1H1GuL\n ONFMwLOT1qPZ+rWOgEq2cipnCX/ze7V1e57SgWMnUAcnOLDPudCH/BfLX08u3kt+ayeH\n 42bvy57yAVE7+B+08F+B5w6VYL7+y04jacnKkETsfhmfb85AQH9sy1/FEiwk5IFvWFKD\n yJ2g==","X-Forwarded-Encrypted":"i=1;\n AFNElJ8BfHdkM32UwNtTdapWUtcDfezbJdSYO5aWVi7LEKCqe2kthl8AiY2f6v9L0Ac53nsDRIxntZ3rJb0q@sourceware.org","X-Gm-Message-State":"AOJu0YxWKOKwfN4ch3xnp0KaV6f/rHr1jbxxgULxgbZxfIWUCzwqtI1P\n 7ztTv9pNjVh1sNYc8eK1g5IQ+fzen/9TD2pVXF+3gAuZp8k73l+/MA1d3vCd69mXb0j2GB+DDz0\n SRvV7pSE3SC25OfrfRH4M05g0Sg4cVHBGpy8Y8mIlVKwP864jUjAi6uqK0KI4JQ==","X-Gm-Gg":"AeBDietK2bobvR9q5EbfwO7U8Fb67hMqxILb13CEBYvkpYtOiX/ONk/uizkyDGyONk2\n XutB+jByKF3rbDPONANFJ6cG9jkSJGjoZP84nYhd6XFp4Mt2gxCXtzhH/M0llejvKbqO22E62QN\n pbKPcNVV07d5ps8cUhetcx95v4XyUx3dj1N95+vMhQ1ADtozAWQERwEeJWB4HJFhDwmOxjP+3Ib\n Nder8GDc18KTwu5KAbM//3gzb7O3JGl0PB2J9iEGu9TFUvkUzQOUuJPZ3JIi/Wm7tiy/h13rZRC\n FccOCR3vBztX5kHxuv1JpjkP3JnzaFA9TaOxP4VYl0Bc3FD8NIkMX7Wrhmu7e298k7AEfel3ESv\n fJBY5ZeA7cUmdRVQn3FFG0Cs3l4UgNtc7h8U3By5MDQbvr3ftLVbnGSvO2/TJnz3I39qIofIVwH\n jIXF01kT3iWknW4cfhCz9f8LuaICXshRdN","X-Received":["by 2002:a05:6214:319d:b0:89c:e5f0:8f33 with SMTP id\n 6a1803df08f44-8ac8615fad1mr308940676d6.10.1776199539734;\n Tue, 14 Apr 2026 13:45:39 -0700 (PDT)","by 2002:a05:6214:319d:b0:89c:e5f0:8f33 with SMTP id\n 6a1803df08f44-8ac8615fad1mr308940166d6.10.1776199539224;\n Tue, 14 Apr 2026 13:45:39 -0700 (PDT)"],"Message-ID":"<23650a5e-baf4-4811-91f8-6950b1d0a3ed@redhat.com>","Date":"Tue, 14 Apr 2026 16:45:37 -0400","MIME-Version":"1.0","User-Agent":"Mozilla Thunderbird","Subject":"Re: [PATCH] nptl: futex_lock_pi deadlock detection provides valuable\n information but it is turned into a rather cryptic assertion failure","To":"Adhemerval Zanella Netto ,\n \"Moritz KLAMMLER (FERCHAU)\" ,\n \"libc-alpha@sourceware.org\" ","References":"\n \n <2bf1c649-8a6a-4f9e-9bc7-c01f2fce81c6@linaro.org>\n \n <34621bae-9591-4a43-84f8-245692d31fbc@linaro.org>\n \n <52db35a1-7d72-40d5-9c6f-3e5082402c7b@linaro.org>","From":"Carlos O'Donell ","Organization":"Red Hat, LLC.","In-Reply-To":"<52db35a1-7d72-40d5-9c6f-3e5082402c7b@linaro.org>","X-Mimecast-Spam-Score":"0","X-Mimecast-MFC-PROC-ID":"14iYT0BG4bFn3w01i-ITEBphBT1A_y08l-6u_aH1Vjg_1776199540","X-Mimecast-Originator":"redhat.com","Content-Language":"en-US","Content-Type":"text/plain; charset=UTF-8; format=flowed","Content-Transfer-Encoding":"7bit","X-BeenThere":"libc-alpha@sourceware.org","X-Mailman-Version":"2.1.30","Precedence":"list","List-Id":"Libc-alpha mailing list ","List-Unsubscribe":",\n ","List-Archive":"","List-Post":"","List-Help":"","List-Subscribe":",\n ","Errors-To":"libc-alpha-bounces~incoming=patchwork.ozlabs.org@sourceware.org"}},{"id":3677510,"web_url":"http://patchwork.ozlabs.org/comment/3677510/","msgid":"","list_archive_url":null,"date":"2026-04-15T07:24:58","subject":"Re: [PATCH] nptl: futex_lock_pi deadlock detection provides\n valuable information but it is turned into a rather cryptic assertion\n failure","submitter":{"id":14312,"url":"http://patchwork.ozlabs.org/api/people/14312/","name":"Florian Weimer","email":"fweimer@redhat.com"},"content":"* Carlos O'Donell:\n\n> If we aren't triggering undefined behaviour then I think it's perfectly\n> acceptable to return a \"may fail\" error to the caller.\n\nDoing that triggers undefined behavior in this case if the caller\nignores the EDEADLK right, no?\n\nThanks,\nFlorian","headers":{"Return-Path":"","X-Original-To":["incoming@patchwork.ozlabs.org","libc-alpha@sourceware.org"],"Delivered-To":["patchwork-incoming@legolas.ozlabs.org","libc-alpha@sourceware.org"],"Authentication-Results":["legolas.ozlabs.org;\n\tdkim=pass (1024-bit key;\n unprotected) header.d=redhat.com header.i=@redhat.com header.a=rsa-sha256\n header.s=mimecast20190719 header.b=iuhrvU4t;\n\tdkim-atps=neutral","legolas.ozlabs.org;\n spf=pass (sender SPF authorized) smtp.mailfrom=sourceware.org\n (client-ip=38.145.34.32; helo=vm01.sourceware.org;\n envelope-from=libc-alpha-bounces~incoming=patchwork.ozlabs.org@sourceware.org;\n receiver=patchwork.ozlabs.org)","sourceware.org;\n\tdkim=pass (1024-bit key,\n unprotected) header.d=redhat.com header.i=@redhat.com header.a=rsa-sha256\n header.s=mimecast20190719 header.b=iuhrvU4t","sourceware.org; dmarc=pass (p=quarantine dis=none)\n header.from=redhat.com","sourceware.org; spf=pass smtp.mailfrom=redhat.com","server2.sourceware.org;\n arc=none smtp.remote-ip=170.10.133.124"],"Received":["from vm01.sourceware.org (vm01.sourceware.org [38.145.34.32])\n\t(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)\n\t key-exchange x25519 server-signature ECDSA (secp384r1) server-digest SHA384)\n\t(No client certificate requested)\n\tby legolas.ozlabs.org (Postfix) with ESMTPS id 4fwXjk6PK3z1yCv\n\tfor ; Wed, 15 Apr 2026 17:25:29 +1000 (AEST)","from vm01.sourceware.org (localhost [127.0.0.1])\n\tby sourceware.org (Postfix) with ESMTP id 6E90A4BA2E14\n\tfor ; Wed, 15 Apr 2026 07:25:27 +0000 (GMT)","from us-smtp-delivery-124.mimecast.com\n (us-smtp-delivery-124.mimecast.com [170.10.133.124])\n by sourceware.org (Postfix) with ESMTP id 733144BA23C2\n for ; Wed, 15 Apr 2026 07:25:07 +0000 (GMT)","from mx-prod-mc-08.mail-002.prod.us-west-2.aws.redhat.com\n (ec2-35-165-154-97.us-west-2.compute.amazonaws.com [35.165.154.97]) by\n relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3,\n cipher=TLS_AES_256_GCM_SHA384) id us-mta-6-CEkRAoO6PbuqvXtTD8kxVA-1; Wed,\n 15 Apr 2026 03:25:04 -0400","from mx-prod-int-03.mail-002.prod.us-west-2.aws.redhat.com\n (mx-prod-int-03.mail-002.prod.us-west-2.aws.redhat.com [10.30.177.12])\n (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)\n key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest\n SHA256)\n (No client certificate requested)\n by mx-prod-mc-08.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTPS\n id C4B021800352; Wed, 15 Apr 2026 07:25:02 +0000 (UTC)","from fweimer-oldenburg.csb.redhat.com (unknown [10.44.33.133])\n by mx-prod-int-03.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with\n ESMTPS\n id 0CADC19560B6; Wed, 15 Apr 2026 07:25:00 +0000 (UTC)"],"DKIM-Filter":["OpenDKIM Filter v2.11.0 sourceware.org 6E90A4BA2E14","OpenDKIM Filter v2.11.0 sourceware.org 733144BA23C2"],"DMARC-Filter":"OpenDMARC Filter v1.4.2 sourceware.org 733144BA23C2","ARC-Filter":"OpenARC Filter v1.0.0 sourceware.org 733144BA23C2","ARC-Seal":"i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1776237907; cv=none;\n b=PZeD5MndtRT4hkutzK5OSJGeEQV2oztM+Z2MvNs9aNaFHKOu5g+O4AqjQOsPAMFGKbJMJKjWn7QrfU7GinJUpE5fNmm6CkpVj6r4pdZK8xLF0V3r+LQ/k2mHH08Sdy/2wwPZu2ifyZOkQDJIlMyJaj0WHozfMfaU8mHeGKxhxL4=","ARC-Message-Signature":"i=1; a=rsa-sha256; d=sourceware.org; s=key;\n t=1776237907; c=relaxed/simple;\n bh=9KhMTIftCnj1Q92WR5V5TdhWsxTQZK5/847wJfDTkSI=;\n h=DKIM-Signature:From:To:Subject:Date:Message-ID:MIME-Version;\n b=C9/b+tFA1UmjLbQmzrR13jT06Q4OYQbl4KK0qgyjJvEOd3gRAwVGaHfMMtCUEWD0OhSuacONjKbZOeHO0wpsJMY/wnKIni2ovlE8h7omOsprfaj6stSrEtTR/3NpC6z4us9hcHVh7PwIWrfeR81gaPHl1iueyxfuuxw2FviOnA0=","ARC-Authentication-Results":"i=1; server2.sourceware.org","DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com;\n s=mimecast20190719; t=1776237906;\n h=from:from:reply-to:subject:subject:date:date:message-id:message-id:\n to:to:cc:cc:mime-version:mime-version:content-type:content-type:\n in-reply-to:in-reply-to:references:references;\n bh=9KhMTIftCnj1Q92WR5V5TdhWsxTQZK5/847wJfDTkSI=;\n b=iuhrvU4to/+jt+PXO65n8gdJ0xBduo1xcmv1VjQ31bUEMV7+zoMSDuDBxHNZDL1P1u4GUX\n eJNJshXx9ktOzt+waGUO6gRCfKFm+areAWzvdScY3sZT6mkdvXz4SpN6ob1Dm3XENf+jSB\n 201lLcA9gc2SYvEuJEzFnTJ/XJnGvhk=","X-MC-Unique":"CEkRAoO6PbuqvXtTD8kxVA-1","X-Mimecast-MFC-AGG-ID":"CEkRAoO6PbuqvXtTD8kxVA_1776237903","From":"Florian Weimer ","To":"Carlos O'Donell ","Cc":"Adhemerval Zanella Netto , \"Moritz\n KLAMMLER (FERCHAU)\" ,\n \"libc-alpha@sourceware.org\" ","Subject":"Re: [PATCH] nptl: futex_lock_pi deadlock detection provides\n valuable information but it is turned into a rather cryptic assertion\n failure","In-Reply-To":"<23650a5e-baf4-4811-91f8-6950b1d0a3ed@redhat.com> (Carlos\n O'Donell's message of \"Tue, 14 Apr 2026 16:45:37 -0400\")","References":"\n \n <2bf1c649-8a6a-4f9e-9bc7-c01f2fce81c6@linaro.org>\n \n <34621bae-9591-4a43-84f8-245692d31fbc@linaro.org>\n \n <52db35a1-7d72-40d5-9c6f-3e5082402c7b@linaro.org>\n <23650a5e-baf4-4811-91f8-6950b1d0a3ed@redhat.com>","Date":"Wed, 15 Apr 2026 09:24:58 +0200","Message-ID":"","User-Agent":"Gnus/5.13 (Gnus v5.13)","MIME-Version":"1.0","X-Scanned-By":"MIMEDefang 3.0 on 10.30.177.12","X-Mimecast-Spam-Score":"0","X-Mimecast-MFC-PROC-ID":"s5D9F3Mz39RtIVhhRmz_JCds1WFsPHkSJQIv9PCUEBc_1776237903","X-Mimecast-Originator":"redhat.com","Content-Type":"text/plain","X-BeenThere":"libc-alpha@sourceware.org","X-Mailman-Version":"2.1.30","Precedence":"list","List-Id":"Libc-alpha mailing list ","List-Unsubscribe":",\n ","List-Archive":"","List-Post":"","List-Help":"","List-Subscribe":",\n ","Errors-To":"libc-alpha-bounces~incoming=patchwork.ozlabs.org@sourceware.org"}},{"id":3677660,"web_url":"http://patchwork.ozlabs.org/comment/3677660/","msgid":"<52c94712-799a-42e8-b996-526728f8b8bd@linaro.org>","list_archive_url":null,"date":"2026-04-15T13:22:08","subject":"Re: [PATCH] nptl: futex_lock_pi deadlock detection provides valuable\n information but it is turned into a rather cryptic assertion failure","submitter":{"id":66065,"url":"http://patchwork.ozlabs.org/api/people/66065/","name":"Adhemerval Zanella Netto","email":"adhemerval.zanella@linaro.org"},"content":"On 15/04/26 04:24, Florian Weimer wrote:\n> * Carlos O'Donell:\n> \n>> If we aren't triggering undefined behaviour then I think it's perfectly\n>> acceptable to return a \"may fail\" error to the caller.\n> \n> Doing that triggers undefined behavior in this case if the caller\n> ignores the EDEADLK right, no?\n\nThe 'may fail' for multi-mutex deadlock is defined even for POSIX 2001 [1],\nso I am not sure if we can consider this UB.\n\n[1] https://pubs.opengroup.org/onlinepubs/009695399/functions/pthread_mutex_lock.html","headers":{"Return-Path":"","X-Original-To":["incoming@patchwork.ozlabs.org","libc-alpha@sourceware.org"],"Delivered-To":["patchwork-incoming@legolas.ozlabs.org","libc-alpha@sourceware.org"],"Authentication-Results":["legolas.ozlabs.org;\n\tdkim=pass (2048-bit key;\n unprotected) header.d=linaro.org header.i=@linaro.org header.a=rsa-sha256\n header.s=google header.b=ey+GpFtA;\n\tdkim-atps=neutral","legolas.ozlabs.org;\n spf=pass (sender SPF authorized) smtp.mailfrom=sourceware.org\n (client-ip=38.145.34.32; helo=vm01.sourceware.org;\n envelope-from=libc-alpha-bounces~incoming=patchwork.ozlabs.org@sourceware.org;\n receiver=patchwork.ozlabs.org)","sourceware.org;\n\tdkim=pass (2048-bit key,\n unprotected) header.d=linaro.org header.i=@linaro.org header.a=rsa-sha256\n header.s=google header.b=ey+GpFtA","sourceware.org;\n dmarc=pass (p=none dis=none) header.from=linaro.org","sourceware.org; spf=pass smtp.mailfrom=linaro.org","server2.sourceware.org;\n arc=none smtp.remote-ip=2607:f8b0:4864:20::132b"],"Received":["from vm01.sourceware.org (vm01.sourceware.org [38.145.34.32])\n\t(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)\n\t key-exchange x25519 server-signature ECDSA (secp384r1) server-digest SHA384)\n\t(No client certificate requested)\n\tby legolas.ozlabs.org (Postfix) with ESMTPS id 4fwhdq5cm2z1yCv\n\tfor ; Wed, 15 Apr 2026 23:22:39 +1000 (AEST)","from vm01.sourceware.org (localhost [127.0.0.1])\n\tby sourceware.org (Postfix) with ESMTP id 5414B4BA2E2B\n\tfor ; Wed, 15 Apr 2026 13:22:37 +0000 (GMT)","from mail-dy1-x132b.google.com (mail-dy1-x132b.google.com\n [IPv6:2607:f8b0:4864:20::132b])\n by sourceware.org (Postfix) with ESMTPS id DE85B4BA2E07\n for ; Wed, 15 Apr 2026 13:22:16 +0000 (GMT)","by mail-dy1-x132b.google.com with SMTP id\n 5a478bee46e88-2dee127b3c5so600250eec.1\n for ; Wed, 15 Apr 2026 06:22:16 -0700 (PDT)","from ?IPV6:2804:1b3:a7c3:2557:103e:c228:16d9:245b?\n ([2804:1b3:a7c3:2557:103e:c228:16d9:245b])\n by smtp.gmail.com with ESMTPSA id\n 5a478bee46e88-2de8c606925sm3158388eec.12.2026.04.15.06.22.10\n (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);\n Wed, 15 Apr 2026 06:22:12 -0700 (PDT)"],"DKIM-Filter":["OpenDKIM Filter v2.11.0 sourceware.org 5414B4BA2E2B","OpenDKIM Filter v2.11.0 sourceware.org DE85B4BA2E07"],"DMARC-Filter":"OpenDMARC Filter v1.4.2 sourceware.org DE85B4BA2E07","ARC-Filter":"OpenARC Filter v1.0.0 sourceware.org DE85B4BA2E07","ARC-Seal":"i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1776259337; cv=none;\n b=Fr0mjJ/iOP/SN7gzn/IA3DIxfNIhhKEb2+/ORSOgw9L4c3PC++je1nPAAcejcyLLRkj/KcATBEKEEMY26yP7w6AVdOZ8mL1Obm0aeQ5qHlGcfxFxh6esMxXNqJRJn7BoIPZSrvUCDQMOQjm+V+akn8HjJgBid49Cdv84xnhkxhI=","ARC-Message-Signature":"i=1; a=rsa-sha256; d=sourceware.org; s=key;\n t=1776259337; c=relaxed/simple;\n bh=Ac/YD9EfQabXvK1FHAgJudFwC1bjexGqcOIIDPal900=;\n h=DKIM-Signature:Message-ID:Date:MIME-Version:Subject:To:From;\n b=KwHevIKj/KKGvD2H5DwFkrrbgIUATH+xtAajmZCVYJosMg0TXpIJlKVENOr+f9nSgUMhj4m3d3tYWmJvJIskAxTwS2I0Awgy//NlZYbEOLGu9cwRCTthf0IEzW+t1LsnyhUloZ6OK/+m68a0crtR2EeACboEMShlL0VLf59nwYc=","ARC-Authentication-Results":"i=1; server2.sourceware.org","DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed;\n d=linaro.org; s=google; t=1776259336; x=1776864136; darn=sourceware.org;\n h=content-transfer-encoding:in-reply-to:organization:from\n :content-language:references:cc:to:subject:user-agent:mime-version\n :date:message-id:from:to:cc:subject:date:message-id:reply-to;\n bh=CwA5DYQY4yRnQeIn8kNIo2u61eX1zdjKMq6mp4XXmcI=;\n b=ey+GpFtAM0pfxuw0jSU1YOeSlz/12oWqIGwvCX4zbjVFAiWLBxnZHQdVaLQlJgXTHp\n Rf2T7vH2OjmoplMbuJqRKgz0QGVisZQJBaIUwfGNgI+fx2SXWtLqyFTSnPZzV65qHwYd\n JTflG3yLyJL430Jkcki9bZWUhcIQM9XF7IAPNjViDhflQHSfmKJbxW8Ny9AVZDUwx0qr\n io74ut3BLq00YghHx6sdAreS8a3wT6ONut8YER0ZUV7YSG8FKisUZyDCsginbWYiYZbE\n smP60R+BUNB6AwNFPZGZMg3Y31hrpe+Vcg/o/ZFnjhORmbbLz4B3e12nRptK39VVXf8D\n 2paQ==","X-Google-DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed;\n d=1e100.net; s=20251104; t=1776259336; x=1776864136;\n h=content-transfer-encoding:in-reply-to:organization:from\n :content-language:references:cc:to:subject:user-agent:mime-version\n :date:message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date\n :message-id:reply-to;\n bh=CwA5DYQY4yRnQeIn8kNIo2u61eX1zdjKMq6mp4XXmcI=;\n b=Gdf/HxXzrrsPea4HPqxlDb2iB+NkwD5PAbQHvoy0WxR5qYKPMEnQKXHAGekUvgQ7eH\n JxIi1c//bQvMEwFjMzaiTEW3NPH5nDmXxIva1dom/sJ2/bl537Mdijppy0oKmP7sbSz9\n gaYw9Ww00IqALwwe8ATRy1TLXeyvhc7iAXfYvUJnJqvZGSO805H9/l0NNui6YvJ04mqH\n M+zjV989VY2cGpgfUQ4IddXwkW/VeS/Garoixt7d+y4EGnJlLi4yPmo4kgmlWyKlprlF\n c4ztkY7xlqKGadbEUqWvTfgQZT+r4KnWl6bQBig6smCuS88BihMDfhX6pGI1R1zZ3f/0\n bCEw==","X-Forwarded-Encrypted":"i=1;\n AFNElJ/4kTZGdsCEaNTSiB9288MHlCPahhfVPySv8aZzvZpnHzy/Bbi1WBn7bUZWLf3e6JVl6Ubmq+1ABnhV@sourceware.org","X-Gm-Message-State":"AOJu0YwPCiSqKy4Qhrl4j/BOIym8hUI+Vq7qJlObC+MI2DxlZRxr02uV\n 7gykY396ljeglSkmP6VkF59l7Q9D4UAJwv844D8irIaxs+rpL2B6fIsNiPeXBdWJ/hY=","X-Gm-Gg":"AeBDievqOuJnVywO6mlRnm9Jk9608b0gm7NJDWK0A5fyBU16MVxh04o6gVRWg/5Idn4\n B2lgoskAPqOszBfrw08JYSv9kjg9BydnRGzCF6m2jRF/jqoF+GB/vF/9qBYvpnHqMNOo5szBVb5\n RHy4CnwfoBh6OIyJQnkpPi+38hrTbAv2umROsa0PqBaKLJG/TFz9LuDQuZWLmxEKRgO2E6kXVKQ\n eTh1p9nTfzrn0nEEYtDKPg0DkBZd5i2dOBYxq3d4tYLrqMFbFtMRbuk1OWZMKt1a0oixl6aysYk\n fb5V8BHwL9F/MQv+BZv7HGbVrw0M2cxA9LepYHv6FkeulK3k/l/7Owu461zahP7XI1ON7xwSJjg\n uKPWQrXxbou1DflS4YZ2/VeCXela8heau9X/LkizMUT0MVI+P0k41oKzPw0CJ9yJTZxeG0qshgm\n uwa5PK8srAgEhs1g4w8XRbT+lF/HpWA+FFyFwIRleL6KWioFnqkKIo1IenDQpbRonTvpGDx+lE1\n vKPjl8V+Y4Z2qiEUgQ0BhrNpsXW19udaorF1OCmfsK9","X-Received":"by 2002:a05:7300:e790:b0:2db:2089:460f with SMTP id\n 5a478bee46e88-2db20894cfbmr4774815eec.19.1776259335574;\n Wed, 15 Apr 2026 06:22:15 -0700 (PDT)","Message-ID":"<52c94712-799a-42e8-b996-526728f8b8bd@linaro.org>","Date":"Wed, 15 Apr 2026 10:22:08 -0300","MIME-Version":"1.0","User-Agent":"Mozilla Thunderbird","Subject":"Re: [PATCH] nptl: futex_lock_pi deadlock detection provides valuable\n information but it is turned into a rather cryptic assertion failure","To":"Florian Weimer , Carlos O'Donell ","Cc":"\"Moritz KLAMMLER (FERCHAU)\" ,\n \"libc-alpha@sourceware.org\" ","References":"\n \n <2bf1c649-8a6a-4f9e-9bc7-c01f2fce81c6@linaro.org>\n \n <34621bae-9591-4a43-84f8-245692d31fbc@linaro.org>\n \n <52db35a1-7d72-40d5-9c6f-3e5082402c7b@linaro.org>\n <23650a5e-baf4-4811-91f8-6950b1d0a3ed@redhat.com>\n ","Content-Language":"en-US","From":"Adhemerval Zanella Netto ","Organization":"Linaro","In-Reply-To":"","Content-Type":"text/plain; charset=UTF-8","Content-Transfer-Encoding":"7bit","X-BeenThere":"libc-alpha@sourceware.org","X-Mailman-Version":"2.1.30","Precedence":"list","List-Id":"Libc-alpha mailing list ","List-Unsubscribe":",\n ","List-Archive":"","List-Post":"","List-Help":"","List-Subscribe":",\n ","Errors-To":"libc-alpha-bounces~incoming=patchwork.ozlabs.org@sourceware.org"}},{"id":3677688,"web_url":"http://patchwork.ozlabs.org/comment/3677688/","msgid":"","list_archive_url":null,"date":"2026-04-15T14:02:19","subject":"Re: [PATCH] nptl: futex_lock_pi deadlock detection provides\n valuable information but it is turned into a rather cryptic assertion\n failure","submitter":{"id":14312,"url":"http://patchwork.ozlabs.org/api/people/14312/","name":"Florian Weimer","email":"fweimer@redhat.com"},"content":"* Adhemerval Zanella Netto:\n\n> On 15/04/26 04:24, Florian Weimer wrote:\n>> * Carlos O'Donell:\n>> \n>>> If we aren't triggering undefined behaviour then I think it's perfectly\n>>> acceptable to return a \"may fail\" error to the caller.\n>> \n>> Doing that triggers undefined behavior in this case if the caller\n>> ignores the EDEADLK right, no?\n>\n> The 'may fail' for multi-mutex deadlock is defined even for POSIX 2001 [1],\n> so I am not sure if we can consider this UB.\n>\n> [1] https://pubs.opengroup.org/onlinepubs/009695399/functions/pthread_mutex_lock.html\n\nIt's likely to end up in UB because the lock is not taken, the caller\ndoesn't realize this, and enters the code for the critical section\nwithout any protection against data races.\n\nThanks,\nFlorian","headers":{"Return-Path":"","X-Original-To":["incoming@patchwork.ozlabs.org","libc-alpha@sourceware.org"],"Delivered-To":["patchwork-incoming@legolas.ozlabs.org","libc-alpha@sourceware.org"],"Authentication-Results":["legolas.ozlabs.org;\n\tdkim=pass (1024-bit key;\n unprotected) header.d=redhat.com header.i=@redhat.com header.a=rsa-sha256\n header.s=mimecast20190719 header.b=JuJJ3rBi;\n\tdkim-atps=neutral","legolas.ozlabs.org;\n spf=pass (sender SPF authorized) smtp.mailfrom=sourceware.org\n (client-ip=38.145.34.32; helo=vm01.sourceware.org;\n envelope-from=libc-alpha-bounces~incoming=patchwork.ozlabs.org@sourceware.org;\n receiver=patchwork.ozlabs.org)","sourceware.org;\n\tdkim=pass (1024-bit key,\n unprotected) header.d=redhat.com header.i=@redhat.com header.a=rsa-sha256\n header.s=mimecast20190719 header.b=JuJJ3rBi","sourceware.org; dmarc=pass (p=quarantine dis=none)\n header.from=redhat.com","sourceware.org; spf=pass smtp.mailfrom=redhat.com","server2.sourceware.org;\n arc=none smtp.remote-ip=170.10.129.124"],"Received":["from vm01.sourceware.org (vm01.sourceware.org [38.145.34.32])\n\t(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)\n\t key-exchange x25519 server-signature ECDSA (secp384r1) server-digest SHA384)\n\t(No client certificate requested)\n\tby legolas.ozlabs.org (Postfix) with ESMTPS id 4fwjXM2B6Cz1yHM\n\tfor ; Thu, 16 Apr 2026 00:02:59 +1000 (AEST)","from vm01.sourceware.org (localhost [127.0.0.1])\n\tby sourceware.org (Postfix) with ESMTP id 419A44BA2E09\n\tfor ; Wed, 15 Apr 2026 14:02:57 +0000 (GMT)","from us-smtp-delivery-124.mimecast.com\n (us-smtp-delivery-124.mimecast.com [170.10.129.124])\n by sourceware.org (Postfix) with ESMTP id 70CB64BA23F1\n for ; Wed, 15 Apr 2026 14:02:31 +0000 (GMT)","from mx-prod-mc-03.mail-002.prod.us-west-2.aws.redhat.com\n (ec2-54-186-198-63.us-west-2.compute.amazonaws.com [54.186.198.63]) by\n relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3,\n cipher=TLS_AES_256_GCM_SHA384) id us-mta-323-0Decn0PhPC-8l_XoXsa4SA-1; Wed,\n 15 Apr 2026 10:02:24 -0400","from mx-prod-int-06.mail-002.prod.us-west-2.aws.redhat.com\n (mx-prod-int-06.mail-002.prod.us-west-2.aws.redhat.com [10.30.177.93])\n (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)\n key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest\n SHA256)\n (No client certificate requested)\n by mx-prod-mc-03.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTPS\n id E3EE81956062; Wed, 15 Apr 2026 14:02:23 +0000 (UTC)","from fweimer-oldenburg.csb.redhat.com (unknown [10.44.33.133])\n by mx-prod-int-06.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with\n ESMTPS\n id 362F51800348; Wed, 15 Apr 2026 14:02:21 +0000 (UTC)"],"DKIM-Filter":["OpenDKIM Filter v2.11.0 sourceware.org 419A44BA2E09","OpenDKIM Filter v2.11.0 sourceware.org 70CB64BA23F1"],"DMARC-Filter":"OpenDMARC Filter v1.4.2 sourceware.org 70CB64BA23F1","ARC-Filter":"OpenARC Filter v1.0.0 sourceware.org 70CB64BA23F1","ARC-Seal":"i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1776261751; cv=none;\n b=h+lRyVF7R+Zp3p4Dvy3KE/i4qhoJxI/jV1iKSPepiOYBzTfpGzUgFywEBGWEzL9po9fbFoia411PGmykXjDN+b3tycAR2dG+6b2/lH9z7D+O+gmIrMcox/mGymlT1Ib2u9gMwM9Dx4iFKOYcbwkJStBq/2Mc47JJhe/KAqF8XAY=","ARC-Message-Signature":"i=1; a=rsa-sha256; d=sourceware.org; s=key;\n t=1776261751; c=relaxed/simple;\n bh=MRMdxWUlMuwwt8UQIRHyt6zqKVr2NQsky4Lz4Ifz+Mg=;\n h=DKIM-Signature:From:To:Subject:Date:Message-ID:MIME-Version;\n b=B1B8ieO0OntAHXsv21kg7VTrJeZTiwckGfdJdAyJSZU7rqUMC3CrGsl2EGjRRi2GNhFVc7rRym8Y0yHiN1GnK53rsxotZ32R6y0akjEfPANLYLgytwUm//PHOLWw9/pmozrMnKPqSvB1meN4iUriX4AtByonLajL/ywCpEDrBDA=","ARC-Authentication-Results":"i=1; server2.sourceware.org","DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com;\n s=mimecast20190719; t=1776261751;\n h=from:from:reply-to:subject:subject:date:date:message-id:message-id:\n to:to:cc:cc:mime-version:mime-version:content-type:content-type:\n in-reply-to:in-reply-to:references:references;\n bh=cQutolUS23Eame0poSJhjp4TS4zC/eDjASF1gI4j874=;\n b=JuJJ3rBiRDo8QcsKgrf0VGJIYq0rpFl01blAMugvHg2KfnBJPr68/IDTBKTnE81+rbttsW\n r/kFDbZcJdUV26mN5LOPZaY0bOHICyQCwMfmRNzbOrrc9VstX1Ox4B/0GW0/tfsl3xdC8k\n Axx1zyTsqKUoyYzszfQ2ju8G2+0XStg=","X-MC-Unique":"0Decn0PhPC-8l_XoXsa4SA-1","X-Mimecast-MFC-AGG-ID":"0Decn0PhPC-8l_XoXsa4SA_1776261744","From":"Florian Weimer ","To":"Adhemerval Zanella Netto ","Cc":"Carlos O'Donell , \"Moritz KLAMMLER (FERCHAU)\"\n , \"libc-alpha@sourceware.org\"\n ","Subject":"Re: [PATCH] nptl: futex_lock_pi deadlock detection provides\n valuable information but it is turned into a rather cryptic assertion\n failure","In-Reply-To":"<52c94712-799a-42e8-b996-526728f8b8bd@linaro.org> (Adhemerval\n Zanella Netto's message of \"Wed, 15 Apr 2026 10:22:08 -0300\")","References":"\n \n <2bf1c649-8a6a-4f9e-9bc7-c01f2fce81c6@linaro.org>\n \n <34621bae-9591-4a43-84f8-245692d31fbc@linaro.org>\n \n <52db35a1-7d72-40d5-9c6f-3e5082402c7b@linaro.org>\n <23650a5e-baf4-4811-91f8-6950b1d0a3ed@redhat.com>\n \n <52c94712-799a-42e8-b996-526728f8b8bd@linaro.org>","Date":"Wed, 15 Apr 2026 16:02:19 +0200","Message-ID":"","User-Agent":"Gnus/5.13 (Gnus v5.13)","MIME-Version":"1.0","X-Scanned-By":"MIMEDefang 3.4.1 on 10.30.177.93","X-Mimecast-Spam-Score":"0","X-Mimecast-MFC-PROC-ID":"8qMMiHV5EOyFbHhAJbI5BI9gJ_zL3B_-LteHHYtia-w_1776261744","X-Mimecast-Originator":"redhat.com","Content-Type":"text/plain","X-BeenThere":"libc-alpha@sourceware.org","X-Mailman-Version":"2.1.30","Precedence":"list","List-Id":"Libc-alpha mailing list ","List-Unsubscribe":",\n ","List-Archive":"","List-Post":"","List-Help":"","List-Subscribe":",\n ","Errors-To":"libc-alpha-bounces~incoming=patchwork.ozlabs.org@sourceware.org"}},{"id":3677695,"web_url":"http://patchwork.ozlabs.org/comment/3677695/","msgid":"<75b91c7c-385f-41d1-8ddc-fa1b86cefe8f@linaro.org>","list_archive_url":null,"date":"2026-04-15T14:18:31","subject":"Re: [PATCH] nptl: futex_lock_pi deadlock detection provides valuable\n information but it is turned into a rather cryptic assertion failure","submitter":{"id":66065,"url":"http://patchwork.ozlabs.org/api/people/66065/","name":"Adhemerval Zanella Netto","email":"adhemerval.zanella@linaro.org"},"content":"On 15/04/26 11:02, Florian Weimer wrote:\n> * Adhemerval Zanella Netto:\n> \n>> On 15/04/26 04:24, Florian Weimer wrote:\n>>> * Carlos O'Donell:\n>>>\n>>>> If we aren't triggering undefined behaviour then I think it's perfectly\n>>>> acceptable to return a \"may fail\" error to the caller.\n>>>\n>>> Doing that triggers undefined behavior in this case if the caller\n>>> ignores the EDEADLK right, no?\n>>\n>> The 'may fail' for multi-mutex deadlock is defined even for POSIX 2001 [1],\n>> so I am not sure if we can consider this UB.\n>>\n>> [1] https://pubs.opengroup.org/onlinepubs/009695399/functions/pthread_mutex_lock.html\n> \n> It's likely to end up in UB because the lock is not taken, the caller\n> doesn't realize this, and enters the code for the critical section\n> without any protection against data races.\n\nBut currently any program that issues this scenario will abort anyway,\nand it also depends whether glibc is built with assert enabled.\n\nIt also follow the error-checking semantic that it *should* return\nan error, so I think it is unlikely to cause a regression because\nI would expect error checking is a standard when this mutex type is\nused.\n\nThe recursive check *might* trigger some issues, but even then for \nnon-pi mutexes this is a deadlock anyway. Maybe just change for\nerror-checking and let robust fall the path of __futex_abstimed_wait64.","headers":{"Return-Path":"","X-Original-To":["incoming@patchwork.ozlabs.org","libc-alpha@sourceware.org"],"Delivered-To":["patchwork-incoming@legolas.ozlabs.org","libc-alpha@sourceware.org"],"Authentication-Results":["legolas.ozlabs.org;\n\tdkim=pass (2048-bit key;\n unprotected) header.d=linaro.org header.i=@linaro.org header.a=rsa-sha256\n header.s=google header.b=dpXefl97;\n\tdkim-atps=neutral","legolas.ozlabs.org;\n spf=pass (sender SPF authorized) smtp.mailfrom=sourceware.org\n (client-ip=38.145.34.32; helo=vm01.sourceware.org;\n envelope-from=libc-alpha-bounces~incoming=patchwork.ozlabs.org@sourceware.org;\n receiver=patchwork.ozlabs.org)","sourceware.org;\n\tdkim=pass (2048-bit key,\n unprotected) header.d=linaro.org header.i=@linaro.org header.a=rsa-sha256\n header.s=google header.b=dpXefl97","sourceware.org;\n dmarc=pass (p=none dis=none) header.from=linaro.org","sourceware.org; spf=pass smtp.mailfrom=linaro.org","server2.sourceware.org;\n arc=none smtp.remote-ip=2607:f8b0:4864:20::1233"],"Received":["from vm01.sourceware.org (vm01.sourceware.org [38.145.34.32])\n\t(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)\n\t key-exchange x25519 server-signature ECDSA (secp384r1) server-digest SHA384)\n\t(No client certificate requested)\n\tby legolas.ozlabs.org (Postfix) with ESMTPS id 4fwjtq0MRcz1yHM\n\tfor ; Thu, 16 Apr 2026 00:18:59 +1000 (AEST)","from vm01.sourceware.org (localhost [127.0.0.1])\n\tby sourceware.org (Postfix) with ESMTP id 28CA84BA2E17\n\tfor ; Wed, 15 Apr 2026 14:18:57 +0000 (GMT)","from mail-dl1-x1233.google.com (mail-dl1-x1233.google.com\n [IPv6:2607:f8b0:4864:20::1233])\n by sourceware.org (Postfix) with ESMTPS id D9E114BA2E09\n for ; Wed, 15 Apr 2026 14:18:36 +0000 (GMT)","by mail-dl1-x1233.google.com with SMTP id\n a92af1059eb24-128b9b7e3edso4944158c88.0\n for ; Wed, 15 Apr 2026 07:18:36 -0700 (PDT)","from ?IPV6:2804:1b3:a7c3:2557:103e:c228:16d9:245b?\n ([2804:1b3:a7c3:2557:103e:c228:16d9:245b])\n by smtp.gmail.com with ESMTPSA id\n a92af1059eb24-12c5e6a860fsm1998337c88.11.2026.04.15.07.18.32\n (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);\n Wed, 15 Apr 2026 07:18:34 -0700 (PDT)"],"DKIM-Filter":["OpenDKIM Filter v2.11.0 sourceware.org 28CA84BA2E17","OpenDKIM Filter v2.11.0 sourceware.org D9E114BA2E09"],"DMARC-Filter":"OpenDMARC Filter v1.4.2 sourceware.org D9E114BA2E09","ARC-Filter":"OpenARC Filter v1.0.0 sourceware.org D9E114BA2E09","ARC-Seal":"i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1776262717; cv=none;\n b=yGD8dtDbS0mqGLDJmG23fqd/qAkDOmbDYlTiMVrV2Y0yw+DuQPEp/uOQqJPYjtBO9vb5ZmpyX4uFIfOB/1EkHSMPCU5OZs8kN6MPbu3O3ypuAFh181qGIa9RWLQp7S5QbKdEHeu/ew/KyEt9Sn+GGYvGinK5uTPOu5cZSCxx+iE=","ARC-Message-Signature":"i=1; a=rsa-sha256; d=sourceware.org; s=key;\n t=1776262717; c=relaxed/simple;\n bh=pcFbfqE0AlitcIYntM93Zq8zLoQbWmjEa8NFocfST8g=;\n h=DKIM-Signature:Message-ID:Date:MIME-Version:Subject:To:From;\n b=RnvYlYYE4cp611EQPTjpIDf5hp3bO0yVqL4p2/EfuZCtTn8YgXVYC9/A2MO2Tf7h+PrCTvoCAfg4GJufKe7RcPJM1M5fwU7LJSYuxrcN9DaTNd8uLqnUDkFS4KDyFuxXtgX29W+q8RyYWS5DBAG0wVHDfsB7LRtZ5ISTfBIbSxU=","ARC-Authentication-Results":"i=1; server2.sourceware.org","DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed;\n d=linaro.org; s=google; t=1776262715; x=1776867515; darn=sourceware.org;\n h=content-transfer-encoding:in-reply-to:organization:from\n :content-language:references:cc:to:subject:user-agent:mime-version\n :date:message-id:from:to:cc:subject:date:message-id:reply-to;\n bh=0NOr856EeObknJ4w8rxlKdnURheu45/0P1+U/NtdeEU=;\n b=dpXefl97SQ9QGYdj2NlgI9CCsotOCiAldcyeiwCpX/3KTL+mtY4rWClQhpE7XxhYaP\n xabbMmgI9rw9VSlTXaEacKKVDJ0ofxRGcHsKQ0VkDTykk9sNv+oRMjZbp5o3CqMKL0jT\n ZcBh8TuH1do5wqf6nP990LOuqokdrtSKmI7PgUxpl6zOHpEwXjNQAady2WzFxcCSWyqJ\n HA9VjiMZjO+IOozc1YHBg0KAEuqvNxFttBQOamEMs7r2i8Xo8Q8ZuvuIYPMq+NPIR8Mc\n UWPTpYSU7h9sYJ3nHf5y4nK/OyXTtDXhBIyxftasilVY1TxeKDDhxIJP4Banptpd4J/Z\n joog==","X-Google-DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed;\n d=1e100.net; s=20251104; t=1776262715; x=1776867515;\n h=content-transfer-encoding:in-reply-to:organization:from\n :content-language:references:cc:to:subject:user-agent:mime-version\n :date:message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date\n :message-id:reply-to;\n bh=0NOr856EeObknJ4w8rxlKdnURheu45/0P1+U/NtdeEU=;\n b=di4/B2V3Ro4mfkHBJ6fIpRxFskiFTg4I2X7LMmDCOHzgJcXqhCzWJomg3bf0o3+g0J\n 7DyZBFlg0BqQRGVrnlQrgQ+vTDt9V9h5DhPHe6VmfXXN2gF5l066Ykf+O8peeFLTh0yH\n mlEo/NC9ZoC3keKf/8pm/MrZ9iioQFq2ErBqPeLglmE4HpINOrptHGyVWM/QXm0/x8gB\n 4SXHfwr5dPSG38vCJ3zXOHCuZRSCm1gvmcA1TVPl49EESbBZS/7AaCjNkK5TslDugycz\n DTHs9OoNjA6UFW3/DPprLEMeF1+FRTMQooCmvhCQQ5F4RCDT+IW0Lp2flGVT5xhri5BU\n 2cDA==","X-Forwarded-Encrypted":"i=1;\n AFNElJ9NUPZj2FpmuE763tM/7AlO2T8ztV4NI3YAX1GSmhvfhOoEq7nRIdsbzfSTk3KiylrHlGqpn5ZTkDRU@sourceware.org","X-Gm-Message-State":"AOJu0YxkHrn5gtzQje+ymPu1QeQ8Mt7Qn9we5BrPyXaAON4/NRxRQU/l\n VXknseBvZa+05bPO0wcqlaTsTptfiv7ExcoCk99gAOFBbzvBDT10UdZ3Yk7TrAeCHfo=","X-Gm-Gg":"AeBDiet/diJX+e4SEbTctDAw+iwIfzFzurFvgaVG5o3SsRSiiWYwR5htohZZmOgX2qG\n RXzz6xoSK0ecGIuBUfKZO1XwNEPSQQUppyi3AiEXcKSXmlOHyxy2l1v5bx96NdpXX5hCjaeZFkp\n Vt5+4S9gFLqWsyl8cufNbcICR7Gg2Ow2OV+78d2xI5Btg0KPyXRD6wk8MfO8CLG5J/mTpkQroOU\n 5qHWkvGBqljs+rmWrMxfIjYOtuGrMOfil7/kj7LZq8Lvo5JFlG79sx78ANuFrZA3xVFjjrVpXE9\n q06f5PeoczeKbTC7PMOIokyHsY6DLJoSoGyyOFOjZ3Szdknaxf3IQdR5wiJOWNu+CD031XtsfC8\n TiGqIcj+BgZp/kTANBCvJJw3NCfIZJ1kYgJ83ER40f4bJtyn9GF5PF72I5uf6gdkna1AvxhdMIM\n JqV4gWHo2ZSd+ofPtxVX5Yejn92MKKZKPRWDxLFDbmj89TIOmRDNr3gsMhmlipNzIkcso4JCGKh\n CV+JeRlxAOv1wLlsdiNxyF0eBhs+71a9JGkNmuBVO4Z","X-Received":"by 2002:a05:7022:6b8d:b0:11b:88a7:e1b0 with SMTP id\n a92af1059eb24-12c34edee56mr13231925c88.26.1776262714985;\n Wed, 15 Apr 2026 07:18:34 -0700 (PDT)","Message-ID":"<75b91c7c-385f-41d1-8ddc-fa1b86cefe8f@linaro.org>","Date":"Wed, 15 Apr 2026 11:18:31 -0300","MIME-Version":"1.0","User-Agent":"Mozilla Thunderbird","Subject":"Re: [PATCH] nptl: futex_lock_pi deadlock detection provides valuable\n information but it is turned into a rather cryptic assertion failure","To":"Florian Weimer ","Cc":"Carlos O'Donell ,\n \"Moritz KLAMMLER (FERCHAU)\" ,\n \"libc-alpha@sourceware.org\" ","References":"\n \n <2bf1c649-8a6a-4f9e-9bc7-c01f2fce81c6@linaro.org>\n \n <34621bae-9591-4a43-84f8-245692d31fbc@linaro.org>\n \n <52db35a1-7d72-40d5-9c6f-3e5082402c7b@linaro.org>\n <23650a5e-baf4-4811-91f8-6950b1d0a3ed@redhat.com>\n \n <52c94712-799a-42e8-b996-526728f8b8bd@linaro.org>\n ","Content-Language":"en-US","From":"Adhemerval Zanella Netto ","Organization":"Linaro","In-Reply-To":"","Content-Type":"text/plain; charset=UTF-8","Content-Transfer-Encoding":"7bit","X-BeenThere":"libc-alpha@sourceware.org","X-Mailman-Version":"2.1.30","Precedence":"list","List-Id":"Libc-alpha mailing list ","List-Unsubscribe":",\n ","List-Archive":"","List-Post":"","List-Help":"","List-Subscribe":",\n ","Errors-To":"libc-alpha-bounces~incoming=patchwork.ozlabs.org@sourceware.org"}},{"id":3679423,"web_url":"http://patchwork.ozlabs.org/comment/3679423/","msgid":"","list_archive_url":null,"date":"2026-04-20T14:25:36","subject":"[PATCH] nptl: futex_lock_pi deadlock detection provides valuable\n information but it is turned into a rather cryptic assertion failure","submitter":{"id":93041,"url":"http://patchwork.ozlabs.org/api/people/93041/","name":"Moritz KLAMMLER (FERCHAU)","email":"Moritz.Klammler@ferchau.com"},"content":"> But currently any program that issues this scenario will abort anyway,\n> and it also depends whether glibc is built with assert enabled.\n>\n> It also follow the error-checking semantic that it *should* return\n> an error, so I think it is unlikely to cause a regression because\n> I would expect error checking is a standard when this mutex type is\n> used.\n>\n> The recursive check *might* trigger some issues, but even then for\n> non-pi mutexes this is a deadlock anyway. Maybe just change for\n> error-checking and let robust fall the path of __futex_abstimed_wait64.\n\nShould I update the patch accordingly to have only error-checking PI\nmutex propagate the EDEADLK and deliberately deadlock in all other\ncases? Running into the assertion seems to be the least desirable\noption to me.","headers":{"Return-Path":"","X-Original-To":["incoming@patchwork.ozlabs.org","libc-alpha@sourceware.org"],"Delivered-To":["patchwork-incoming@legolas.ozlabs.org","libc-alpha@sourceware.org"],"Authentication-Results":["legolas.ozlabs.org;\n\tdkim=fail reason=\"signature verification failed\" (2048-bit key;\n unprotected) header.d=ferchau.com header.i=@ferchau.com header.a=rsa-sha256\n header.s=s2048 header.b=YCO35CGv;\n\tdkim=pass (1024-bit key;\n unprotected) header.d=ablegroupde.onmicrosoft.com header.i=@ablegroupde.onmicrosoft.com\n header.a=rsa-sha256 header.s=selector1-ablegroupde-onmicrosoft-com\n header.b=dxfgQ0Oy;\n\tdkim-atps=neutral","legolas.ozlabs.org;\n spf=pass (sender SPF authorized) smtp.mailfrom=sourceware.org\n (client-ip=38.145.34.32; helo=vm01.sourceware.org;\n envelope-from=libc-alpha-bounces~incoming=patchwork.ozlabs.org@sourceware.org;\n receiver=patchwork.ozlabs.org)","sourceware.org;\n\tdkim=fail reason=\"signature verification failed\" (2048-bit key,\n unprotected) header.d=ferchau.com header.i=@ferchau.com header.a=rsa-sha256\n header.s=s2048 header.b=YCO35CGv;\n\tdkim=pass (1024-bit key,\n unprotected) header.d=ablegroupde.onmicrosoft.com header.i=@ablegroupde.onmicrosoft.com\n header.a=rsa-sha256 header.s=selector1-ablegroupde-onmicrosoft-com\n header.b=dxfgQ0Oy","sourceware.org;\n dmarc=pass (p=none dis=none) header.from=ferchau.com","sourceware.org; spf=pass smtp.mailfrom=ferchau.com","server2.sourceware.org;\n arc=pass smtp.remote-ip=212.211.156.0","dkim=none (message not signed)\n header.d=none;dmarc=none action=none header.from=ferchau.com;"],"Received":["from vm01.sourceware.org (vm01.sourceware.org [38.145.34.32])\n\t(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)\n\t key-exchange x25519 server-signature ECDSA (secp384r1) server-digest SHA384)\n\t(No client certificate requested)\n\tby legolas.ozlabs.org (Postfix) with ESMTPS id 4fznpj5Ylcz1yD4\n\tfor ; Tue, 21 Apr 2026 00:26:05 +1000 (AEST)","from vm01.sourceware.org (localhost [127.0.0.1])\n\tby sourceware.org (Postfix) with ESMTP id B4CFF4D8D1E6\n\tfor ; Mon, 20 Apr 2026 14:26:03 +0000 (GMT)","from mx2.ferchau.com (smtp.ablegroup.de [212.211.156.0])\n by sourceware.org (Postfix) with ESMTPS id ADD8E4A9933A\n for ; Mon, 20 Apr 2026 14:25:40 +0000 (GMT)","from gmzrzex001.ferchau.local ([10.100.54.1])\n by mx2.ferchau.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384;\n 20 Apr 2026 16:25:38 +0200","from GMZRZEX002.Ferchau.local (10.100.54.2) by\n GMZRZEX001.Ferchau.local (10.100.54.1) with Microsoft SMTP Server\n (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id\n 15.2.2562.35; Mon, 20 Apr 2026 16:25:38 +0200","from GV1PR07CU001.outbound.protection.outlook.com (40.93.214.97) by\n exchange.ferchau.com (172.16.19.112) with Microsoft SMTP Server\n (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id\n 15.2.2562.35 via Frontend Transport; Mon, 20 Apr 2026 16:25:38 +0200","from PR3PR06MB6889.eurprd06.prod.outlook.com (2603:10a6:102:87::9)\n by PR3PR06MB6763.eurprd06.prod.outlook.com (2603:10a6:102:6f::22) with\n Microsoft SMTP Server (version=TLS1_2,\n cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9818.32; Mon, 20 Apr\n 2026 14:25:36 +0000","from PR3PR06MB6889.eurprd06.prod.outlook.com\n ([fe80::7396:2256:3ddb:4637]) by PR3PR06MB6889.eurprd06.prod.outlook.com\n ([fe80::7396:2256:3ddb:4637%3]) with mapi id 15.20.9818.032; Mon, 20 Apr 2026\n 14:25:36 +0000"],"DKIM-Filter":["OpenDKIM Filter v2.11.0 sourceware.org B4CFF4D8D1E6","OpenDKIM Filter v2.11.0 sourceware.org ADD8E4A9933A"],"DMARC-Filter":"OpenDMARC Filter v1.4.2 sourceware.org ADD8E4A9933A","ARC-Filter":"OpenARC Filter v1.0.0 sourceware.org ADD8E4A9933A","ARC-Seal":["i=2; a=rsa-sha256; d=sourceware.org; s=key; t=1776695141; cv=pass;\n b=Xm0Y/1lb+VjqDRFLwXWdm/JFUwk1g6gjLieKrbOzKSC/2RT5oKN2+12BunGNy1yxxSZOAiRe7UpXZCkMbiYF7gelHdZI/rNneeUAHxLE8Hb3H6a8cDMU+ENvzl3tHeidei4+nFQGE4zZ4OLH27V3FdU4Y1+F+uhryMZnEuwfSjo=","i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;\n b=benJ4yQpT7OhTgExCwh5QYKuxT/IREAT+VlNwtGdnvrjn6lyGtOh2GXCuGvfo8iHl+pM2w8MYkmZvHe2KLgbiLC+pmvs/eboYoFoFKFMiq6o1y/ekzf1tJrxDz5M6vll+IZsz49F+gGbOmUmkEoWSi8JBpk7jTi+cYWzOrh448bTIKUKufxDKrR+etTRM89WJFzprTlalU9kHUo12fc6NONaIQ+U/5oeOEkqpBzP5rM7N7giz1zz9U5V0LNgy32K3pCSRzbFOIMcdFZyxMTUCxDgbuaubIORzWAAe3iQ7MT8V1B+8pwmPJ/h0WJHv5EeCjoNXuXy9eu0Z50WvHTl4g=="],"ARC-Message-Signature":["i=2; a=rsa-sha256; d=sourceware.org; s=key;\n t=1776695141; c=relaxed/simple;\n bh=AWHs6dBoAVNuRPwtqusJfZ1c+zbKCBW3wqDjvZVxgkc=;\n h=DKIM-Signature:DKIM-Signature:From:To:Subject:Date:Message-ID:\n MIME-Version;\n b=OM3lY0aGLNnbCn58EcXXU1wRa8cfFCetmq3Oy7AFyb3qS1D78biA1nT0LoEeJToELHm60vpCEWC0VxFRwBDZ0/V/TaWhicqyk9Dw0qx1Tr9NQSPBXQXBkdvuI+hFlncTqvsZ3gMpvfACtsRslgq44h+9eeKjXigKCOtsDws0RmY=","i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;\n s=arcselector10001;\n h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;\n bh=AJcNQ8Kr1WCnMO+wABjoGHSk9Q9SsAqpNUXSuGXVbFc=;\n b=p25CEBJ5mW/8iEGXAKDuFxBWcLmmp3DcOgWxYPoZlF7BLJJW3GdJYqK8boy7WM9TC86T8PZoPqRpkqrW5Eclsg2xRpRufUW/5LMvDWmo480XUyWT8S/4RDNvpy1ckAZTEj29T09PV+XHmRVO3cv1Qgn0f11eH/fVXA+laMKkfZ28Rg+zXh1pcEZ34+DA4psqZGh7UMQxUNL8Qljp0BT4TUZL9IfxVj0q+ftupxpBjcWjZqG3Rjo9AI5GI5vc55ZG0bjKa1QqbMy3d+iSwCVX1snuTUK2e6bSmIcpMx0uu8HQ3e43dDoAfMmvgcJZJo0eh/5ueBitC9IB7Pcjhimf/A=="],"ARC-Authentication-Results":["i=2; server2.sourceware.org","i=1; mx.microsoft.com 1; spf=pass\n smtp.mailfrom=ferchau.com; dmarc=pass action=none header.from=ferchau.com;\n dkim=pass header.d=ferchau.com; arc=none"],"DKIM-Signature":["v=1; a=rsa-sha256; c=relaxed/relaxed;\n d=ferchau.com; i=@ferchau.com; q=dns/txt; s=s2048;\n t=1776695140; x=1808231140; h=arc-seal:arc-message-signature:\n arc-authentication-results:dkim-signature:from:to:cc:\n subject:thread-topic:thread-index:date:message-id:\n references:in-reply-to:accept-language:content-language:\n x-ms-has-attach:x-ms-tnef-correlator:msip_labels:\n authentication-results:x-ms-publictraffictype:\n x-ms-traffictypediagnostic:\n x-ms-office365-filtering-correlation-id:\n x-ms-exchange-senderadcheck:x-ms-exchange-antispam-relay:\n x-microsoft-antispam:x-microsoft-antispam-message-info:\n x-forefront-antispam-report:\n x-ms-exchange-antispam-messagedata-chunkcount:\n x-ms-exchange-antispam-messagedata-0:content-type:\n content-transfer-encoding:mime-version:\n x-exchange-routingpolicychecked:\n x-ms-exchange-crosstenant-authas:\n x-ms-exchange-crosstenant-authsource:\n x-ms-exchange-crosstenant-network-message-id:\n x-ms-exchange-crosstenant-originalarrivaltime:\n x-ms-exchange-crosstenant-fromentityheader:\n x-ms-exchange-crosstenant-id:\n x-ms-exchange-crosstenant-mailboxtype:\n x-ms-exchange-crosstenant-userprincipalname:\n x-ms-exchange-transport-crosstenantheadersstamped:\n x-cse-connectionguid:x-cse-msgguid:ironport-data:\n ironport-hdrordr:x-talos-cuid:x-talos-muid:x-ironport-av;\n bh=AJcNQ8Kr1WCnMO+wABjoGHSk9Q9SsAqpNUXSuGXVbFc=;\n b=YCO35CGvkreDun4g+pfsXxijjsfOfMUskwYfvxZnqlBlSUjKZP85t45S\n 5fYCWXAvEfVnaRf5CR98UT5L5zOsechjde9zCRO2ESLZKF9oijhWG/I/S\n mMJEqOupsR/mVIqQroJnNzdd3uW1D5lhW7Q4qMDoQM8X2bzZbcbM8zehE\n 3psXf041WTT43+hd0R78aGK2rEjXJw4sQ2FnvqjAnONB0EuxuUgLoH43g\n +aWRCwIoudolrwPZTR99jISa9OEQCBnY/ndrQHOa+qCuXszDyzNdMGGdA\n yEHWFubvFT1D4h5Y+ZUAZDz3TZQebjcCoxrMR4Rxsh0EWDExeL4EN64Ba Q==;","v=1; a=rsa-sha256; c=relaxed/relaxed;\n d=ablegroupde.onmicrosoft.com; s=selector1-ablegroupde-onmicrosoft-com;\n h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;\n bh=AJcNQ8Kr1WCnMO+wABjoGHSk9Q9SsAqpNUXSuGXVbFc=;\n b=dxfgQ0OyM3velQ7ugTOHeQJUNAQXRPH33/1nISrpYrN+nG0f6lQYUJ6MLUnKrjUWSlK6t+S+x2FbGKgxmSvBwQfY68tgMzWr8EiYKa81wD1LG70Pj4vR+bykScOaXmjnKJb29AueUfJWsbYG9vhvfu2UziY0KiBSN6RlrIm7BKw="],"X-CSE-ConnectionGUID":"P13b8HgeRCSquBLb/O0H2g==","X-CSE-MsgGUID":"p0/uwzIgRTuCNQ7AMkT9+w==","IronPort-Data":"A9a23:Bwdnkqy9a0P0yNg7J+96t+cuxyrEfRIJ4+MujC+fZmUNrF6WrkVSn\n zEaWDjVOv+Iamunftt1PIzl8hkGuJKDz4RiTlA+/C00HyNBpPSeCIXCJC8cHc8ywu4v7a5Dx\n 59DAjUVBJlsFhcwnj/0bP656yU6jfjWLlbFILasEjhrQgN5QzsWhxtmmuoo6qZlmtHR7zml4\n LsemOWBfgX+s9JIGjhMsfzb9Ek35K2aVA4w5TTSW9ga5DcyqFFIVPrzFYnpR1PkT49dGPKNR\n uqr5NmR4mPD8h4xPcium7D9f1diaua60d+m0yc+twCK23CulwRqukoJHKN0hXR/0l1lq+tMJ\n OBl7vRcf+uJ0prkw4zxWzEAe8130DYvFLXveRBTuuTLp6HKnueFL1yDwyjaMKVBktubD12i+\n tQgcWsHPjCMitid+6umYM1mweN7DJPkadZ3VnFIlVk1DN4JZKL5cYj6vYcBmhk9nMtOFOuYY\n 80SYD4HgBboOkUJYw9PTs9i2r7AanrXKlW0rHqworA2/3qV7wh41b3pPcD9dNGQTsVcgwCTo\n WeuE2HRWEtCZIfGklJp9Fq03qjSgjHaV7guCZaez6FDpV6vly8MXUh+uVyT5KPRZlSFc9tTK\n 0ER9zAwpKx05kWtQ935VjW8oXiNpBlaXMBfe8U09wyMz6fOyxyUCmgNUnhKb9lOnMQ/Xzgtz\n XeTkt/pDCApu7qQIVqZ972f6Dq2ISgcBXQFeDUPQBQM+dSlp5s85i8jVf5sFbyvnNDlQWmph\n T6HtiM+jqhVickA3qHTEU37vg9Ab6PhFmYdjjg7lEr8hu+lTOZJv7CV1GU=","IronPort-HdrOrdr":"A9a23:sEkqQa0QV5wz6XmEkei/6gqjBchxeYIsimQD101hICG9Kvbo8f\n xHnJwgtSMc+wxhHU3I+OrwfJVoLkmskaKdjbN+AV7AZniThILLFvAE0WKK+VSJcEGQygc379\n YCT0EKMqyUMbEMt7eZ3ODXKbcd6ejC3LGjhO/YwXsodgd3dqFm4T5+DwaQAmd2SANFCZdRLu\n vq2iLrzADLRV0nKuCAQlUVVenKoNPG0Lj8ZwQdOhIh4A6SyRu19b/TCXGjr14jegIK5Y1n3X\n nOkgT/6Knmmeq80AXg22ja6IkTsMf9y+FEGNeHhqEuW33RY0eTFc9cso+5zX0ISdKUmRoXeR\n 730lgd1vFImjnsl6eO0FXQMkfboXcTAjTZuCalaDPY0LTEbQN/L8pEiYhQaAacz2UL+PlT/u\n Zq8gui2qZ/PFflnCDw7dDTSlVPuWDxmEEFu6oyohVkIMgjgDg7l/1cwKuAe61wXB4SrrpXZt\n VGHYXS4u1bfkidaG2ctm5zwMa0VnB2BRueRFMe0/bloAS+sUoJvnfw/vZv7kso5dY4Ud1J9u\n 7EOqNnmPVHSdIXd7t0AKMETdGsAmLATBrQOCbKSG6XYZ0vKjbIsdr68b817OaldNgBy4Yzgo\n 3IVBdduXQpc0zjBMWS1NlA8wzLQm+6QTPxo/sulaRRq/n5Xv7mICeDQFchn4+ppOgeGNTSX7\n KpNJdfE5bYXBXT8a0g5XyEZ3CTEwhgbCQ4gKdGZ7vVmLOwFmTDjJ2nTMru","X-Talos-CUID":"9a23:dN34m2C4kXaHfzX6ExE+r0REOs8oSFbm1Wr6B0X/Lj5JErLAHA==","X-Talos-MUID":"9a23:06fa8wn9TsjgTF/yGpbfdnp6bIB1/LaPB3oxjL4ggpatEC9ManSC2WE=","X-IronPort-AV":"E=Sophos;i=\"6.23,190,1770591600\";\n d=\"scan'208\";a=\"2208313\"","From":"\"Moritz KLAMMLER (FERCHAU)\" ","To":"Adhemerval Zanella Netto , Florian Weimer\n ","CC":"Carlos O'Donell , \"libc-alpha@sourceware.org\"\n ","Subject":"[PATCH] nptl: futex_lock_pi deadlock detection provides valuable\n information but it is turned into a rather cryptic assertion failure","Thread-Topic":"[PATCH] nptl: futex_lock_pi deadlock detection provides valuable\n information but it is turned into a rather cryptic assertion\n failure","Thread-Index":"\n AQHcbnK4Dzm02VYQ8EyWQ8MgFDPAAbUl6RwAgKa+5hCABn8tAIADIbsWgAlw5YCAAAiXgIAAssIhgABjqgCAAAtZQoAABGiAgAfb1aE=","Date":"Mon, 20 Apr 2026 14:25:36 +0000","Message-ID":"\n ","References":"\n \n <2bf1c649-8a6a-4f9e-9bc7-c01f2fce81c6@linaro.org>\n \n <34621bae-9591-4a43-84f8-245692d31fbc@linaro.org>\n \n <52db35a1-7d72-40d5-9c6f-3e5082402c7b@linaro.org>\n <23650a5e-baf4-4811-91f8-6950b1d0a3ed@redhat.com>\n \n <52c94712-799a-42e8-b996-526728f8b8bd@linaro.org>\n \n <75b91c7c-385f-41d1-8ddc-fa1b86cefe8f@linaro.org>","In-Reply-To":"<75b91c7c-385f-41d1-8ddc-fa1b86cefe8f@linaro.org>","Accept-Language":"de-DE, en-US","Content-Language":"de-DE","X-MS-Has-Attach":"","X-MS-TNEF-Correlator":"","msip_labels":"","authentication-results":["legolas.ozlabs.org;\n\tdkim=fail reason=\"signature verification failed\" (2048-bit key;\n unprotected) header.d=ferchau.com header.i=@ferchau.com header.a=rsa-sha256\n header.s=s2048 header.b=YCO35CGv;\n\tdkim=pass (1024-bit key;\n unprotected) header.d=ablegroupde.onmicrosoft.com header.i=@ablegroupde.onmicrosoft.com\n header.a=rsa-sha256 header.s=selector1-ablegroupde-onmicrosoft-com\n header.b=dxfgQ0Oy;\n\tdkim-atps=neutral","legolas.ozlabs.org;\n spf=pass (sender SPF authorized) smtp.mailfrom=sourceware.org\n (client-ip=38.145.34.32; helo=vm01.sourceware.org;\n envelope-from=libc-alpha-bounces~incoming=patchwork.ozlabs.org@sourceware.org;\n receiver=patchwork.ozlabs.org)","sourceware.org;\n\tdkim=fail reason=\"signature verification failed\" (2048-bit key,\n unprotected) header.d=ferchau.com header.i=@ferchau.com header.a=rsa-sha256\n header.s=s2048 header.b=YCO35CGv;\n\tdkim=pass (1024-bit key,\n unprotected) header.d=ablegroupde.onmicrosoft.com header.i=@ablegroupde.onmicrosoft.com\n header.a=rsa-sha256 header.s=selector1-ablegroupde-onmicrosoft-com\n header.b=dxfgQ0Oy","sourceware.org;\n dmarc=pass (p=none dis=none) header.from=ferchau.com","sourceware.org; spf=pass smtp.mailfrom=ferchau.com","server2.sourceware.org;\n arc=pass smtp.remote-ip=212.211.156.0","dkim=none (message not signed)\n header.d=none;dmarc=none action=none header.from=ferchau.com;"],"x-ms-publictraffictype":"Email","x-ms-traffictypediagnostic":"PR3PR06MB6889:EE_|PR3PR06MB6763:EE_","x-ms-office365-filtering-correlation-id":"1efc21a0-de46-417e-bd65-08de9ee8b0a8","x-ms-exchange-senderadcheck":"1","x-ms-exchange-antispam-relay":"0","x-microsoft-antispam":"BCL:0;\n ARA:13230040|366016|1800799024|376014|38070700021|56012099003|18002099003|22082099003;","x-microsoft-antispam-message-info":"\n 1u03d6TZr4gAhOLfy+9kf+DspSYUZvYDq93JkZd5cDPiJjPI6rgM9vMqen6A9gL5yi1MuBLer7R/EMNGnOxveStpYy1U36YCHRgP98gH0cvBabWIubJFkq1XZ2w0prCcMdc9IX2TQ4Zu7CUXuWyYTN9ZaTgWhsNGmI4MU5q6r5FqRcZGBk1TiL525H8iaClSqvIxDbogq9K4m5QJfCw+f0ptYELd48GV/p5NqZM9elIPyvH1ZmHpnpEUFvWnZFQpaw7pLcIhN7hfwst+UjFBxeAlaYQ2wHRlXbOzQtCi5ugbhH+o1yCo17PR4iRdwHT+bKXiZ9oXD2O5R1LfueXXAD6zgNZoNCTt2R5Kq0KsqJPFfa4lzawsO4cPgCRNplLQKF8pQ76OLdT9NTkk1pbnhbUJFxk9u+foW1ek+OMecLC0wtrBymGHGNEAc6DkumyOhfkHruufyl6Lpgv7VSxMoz+NBQXDKQxtx/0vK+dqTIWxYRp0lTLvbcSezgI3CvbINjfBePI7bbkYeT0fzEIfxxaqnS8vRL4odjJ0qEJmJ6GKJY9VQSauuOxik8nHljkyI7tL/e6E4S0YltLM9Sek0/Ic0cibhGTuf2tfz2h1rAVDno+2bTBkSZCoGPW+cekjC6Hch+NsC3TWyNApjydUPFG8cJhU9mY71k1mU52SPsAEWAjxglTQBLEU+jjq/u5fMZVf8rPpCb4cSPyHwJPmIr3267luhI9/hybqDSlNzz90wkYmhER1vpjjdRX6pVQmq/XC10Zr1UYtC3G82q1yKn1lLB02EyAhOdfDDgO3nnI=","x-forefront-antispam-report":"CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:;\n IPV:NLI; SFV:NSPM; H:PR3PR06MB6889.eurprd06.prod.outlook.com; PTR:; CAT:NONE;\n SFS:(13230040)(366016)(1800799024)(376014)(38070700021)(56012099003)(18002099003)(22082099003);\n DIR:OUT; SFP:1102;","x-ms-exchange-antispam-messagedata-chunkcount":"1","x-ms-exchange-antispam-messagedata-0":"=?iso-8859-1?q?P5rVhFsFMidXZQjB7zAWs6j?=\n\t=?iso-8859-1?q?ZB8wvfu0rXajRtW/Tapm+BUTxic5kdiz6l5FC58vEh4c5hWNWC44Jn9x3orc?=\n\t=?iso-8859-1?q?y2KQq8lOHJhX66UuNHjLJ0Bsildsx9+j8LBknaOWommrT+qwdCf4GsVYGcZt?=\n\t=?iso-8859-1?q?Z4LrjAaIBD2oCwCQ8lnelhLW0jhn7qQ27OzCduHzbigPB5q3kaD9fdYREYgY?=\n\t=?iso-8859-1?q?nvUXFYKbOy8FsTTINJbBugp/xYoIR+N+7hKIsTOg/gFCYwjlFgOE4Y7S6YTM?=\n\t=?iso-8859-1?q?DaYWY35EO7zdGGMR7kMRbvg6Vo0UTzkLE6HAyH3GPpjTnahEjHd74vqFWjef?=\n\t=?iso-8859-1?q?PmzyW52y4z/Gjj1hH0V6Yf+p4LzDse1dve/ohY9JNftnnJH0FylL9WuCdm2n?=\n\t=?iso-8859-1?q?WW0gqIrogvRrglqZ8mx5HWkHUDBt06I9YlGlBiAYY+1MEE1qBiefN4MwBGM3?=\n\t=?iso-8859-1?q?kaSBP0Hz8XRQzoTxElKj6ZhnG8r+We5mb/uouopkygbjNswMveUiTMNxo7/N?=\n\t=?iso-8859-1?q?CpMABYuswTLP/Y6kagBuDldyaMn6G3nZCWTS8yX2NVG/COlrE8f++7vjMyDs?=\n\t=?iso-8859-1?q?faBhQK7xYuatfMLjCtdbV2krOyoI3DWZdayRTBKF8lzcb2dzsCkqaLk4kBdy?=\n\t=?iso-8859-1?q?S4pTdr81mjAcNCrJr/BLYrcvqI7lt8cJtqA5pq26joIsZfziLETS8+i8HL4+?=\n\t=?iso-8859-1?q?cv8hi9ZfbJGxETCf696rXnvlstbrpbZxDvmkhfP7zbbf/tOe4WbVGiXOxG3+?=\n\t=?iso-8859-1?q?oDXiX3SHRRKUW1VMCr8FqaWbVDk8yQGvEc5c79NFoGQ8cZfSx5u6Q6B6H64h?=\n\t=?iso-8859-1?q?7zC7f0aSaUpVXzIRSfzTBgfCAJocC3ZwGxhQuuyWiHYFMRoc18utmeG6onRD?=\n\t=?iso-8859-1?q?uLHHPBDCnvpcLK95V1+lBOFyFWpdudNqTTV+ZbWMdtohi3oc9FFx5+upHi8l?=\n\t=?iso-8859-1?q?wR96Z/ly45/sjIrn5JvSk+woP1G7ldncchiAefIeQ5L2WhPBfLSPxG8hITOE?=\n\t=?iso-8859-1?q?GR69wFUSuyiKF2sHsv0Kt9999IUgvP86k28grKAxiyJCKZMU9pDJyELaoMc1?=\n\t=?iso-8859-1?q?ux4+nB7z0xcCKtKh8SXNhbYDxQP8w9HgaM1UZv7PAiDGzUf2JC6LJ95KGL9r?=\n\t=?iso-8859-1?q?m9NYPsW8/JS0kMBE9WEx2RoLQhY7Yc/DXMxvtQXTAd/EvoCrlMKvIUkUzD3F?=\n\t=?iso-8859-1?q?iuKl+gG4De8T1vX9qITiYwILzEXENQGXanQLEV+VaKJ4QWRmaPL6Xg7ATbIa?=\n\t=?iso-8859-1?q?J8q5WjNrRfpfruc45vceAEsjo+szgWXGNwrpW5YlDZkyblahtKm5MTosEG45?=\n\t=?iso-8859-1?q?YjqZwqbgVIytEAdEj+1qBsEq/EgUyuFrEAV4SA79tqSy8qB11nTgdXfdc2LF?=\n\t=?iso-8859-1?q?76IHC19PuwnJZdUWeoSEiKVCffdilntsu8rJ/TR2raQfj/OTbEjYCcMntTWu?=\n\t=?iso-8859-1?q?MIRYrAgnAhLb+MVstaryXphLsaKBPAPIXPDYBGdUUpQ7TWFJrPWqtFb0dx8c?=\n\t=?iso-8859-1?q?gKcS3m7LFwihHncO8tD5E5J84KagdlhDHqiqv1UDhmf79BPI5QpNf9GBdj8u?=\n\t=?iso-8859-1?q?lfqTbn7RbKwpAC/yvAFqhoISfzBDzofOR2a+09DXpUs7+KuF+N/2JuR3x+7g?=\n\t=?iso-8859-1?q?sTZ53As/PZXgfgKNCwcDxzor5EKTSnKBcoFq5RIiLIAP26VuWyBbIEe0Q28/?=\n\t=?iso-8859-1?q?gH3MADe1lJRsCSTjLe6j0u8fedQRKA+OF2yE4A4HaemImD5uAsTOo91wNs4E?=\n\t=?iso-8859-1?q?rKKniNicAyx6foYLY6JR5Md5+Xx7/oeUmwqWm1Z0qvb12nQ=3D=3D?=","Content-Type":"text/plain; charset=\"iso-8859-1\"","Content-Transfer-Encoding":"quoted-printable","MIME-Version":"1.0","X-Exchange-RoutingPolicyChecked":"\n lhsOUAOZphSgcbSSjXHFQilC7vBro1ws/jyGs8ux+VZH/xAC38dihJKzUyjt7kWeUNadHBjKV5Aso/jVcQnnBK9rmSnpC0VmK3GzIqrqBMVOYXLwzT1bkmBcCuUjnbZXoRhUDks0+VukidMpNeOmrPk/6ied3joPWbl+9cahYhzRk54TUdixfQ9BVoPZC7knwhBZRy47ctxB+M0NpTcrxPH8Hxa9FqrSvt2MzcBItBa0h2BOiNDQMlJLSdv4yj9kOkADgLwdvr58uNGRGYxSz5VwA5rd+xMacWR0GCzKUHrMZrOH75sp64lAqheWQCfULPJpod/mTVgp1FE122NIEw==","X-MS-Exchange-CrossTenant-AuthAs":"Internal","X-MS-Exchange-CrossTenant-AuthSource":"PR3PR06MB6889.eurprd06.prod.outlook.com","X-MS-Exchange-CrossTenant-Network-Message-Id":"\n 1efc21a0-de46-417e-bd65-08de9ee8b0a8","X-MS-Exchange-CrossTenant-originalarrivaltime":"20 Apr 2026 14:25:36.6485 (UTC)","X-MS-Exchange-CrossTenant-fromentityheader":"Hosted","X-MS-Exchange-CrossTenant-id":"9a3c2f68-d5b5-4769-b2f8-8d6fe142b164","X-MS-Exchange-CrossTenant-mailboxtype":"HOSTED","X-MS-Exchange-CrossTenant-userprincipalname":"\n 2YrHgGeDZstdZHRxcDbY1yPfSGHeOsUCo+7RKAhxFhGXZpSEAc4+KbNbpNnqa8cGnmPfacHyBMQ59Y8SyliciE9HpyJsOkHJYDG7zum7z1M=","X-MS-Exchange-Transport-CrossTenantHeadersStamped":"PR3PR06MB6763","X-BeenThere":"libc-alpha@sourceware.org","X-Mailman-Version":"2.1.30","Precedence":"list","List-Id":"Libc-alpha mailing list ","List-Unsubscribe":",\n ","List-Archive":"","List-Post":"","List-Help":"","List-Subscribe":",\n ","Errors-To":"libc-alpha-bounces~incoming=patchwork.ozlabs.org@sourceware.org"}},{"id":3679444,"web_url":"http://patchwork.ozlabs.org/comment/3679444/","msgid":"","list_archive_url":null,"date":"2026-04-20T15:52:35","subject":"Re: [PATCH] nptl: futex_lock_pi deadlock detection provides valuable\n information but it is turned into a rather cryptic assertion failure","submitter":{"id":66065,"url":"http://patchwork.ozlabs.org/api/people/66065/","name":"Adhemerval Zanella Netto","email":"adhemerval.zanella@linaro.org"},"content":"On 20/04/26 11:25, Moritz KLAMMLER (FERCHAU) wrote:\n>> But currently any program that issues this scenario will abort anyway,\n>> and it also depends whether glibc is built with assert enabled.\n>>\n>> It also follow the error-checking semantic that it *should* return\n>> an error, so I think it is unlikely to cause a regression because\n>> I would expect error checking is a standard when this mutex type is\n>> used.\n>>\n>> The recursive check *might* trigger some issues, but even then for\n>> non-pi mutexes this is a deadlock anyway. Maybe just change for\n>> error-checking and let robust fall the path of __futex_abstimed_wait64.\n> \n> Should I update the patch accordingly to have only error-checking PI\n> mutex propagate the EDEADLK and deliberately deadlock in all other\n> cases? Running into the assertion seems to be the least desirable\n> option to me.\n\nI think this should a reasonable approach, I am not sure if Florian still\nthink this might not be acceptable.","headers":{"Return-Path":"","X-Original-To":["incoming@patchwork.ozlabs.org","libc-alpha@sourceware.org"],"Delivered-To":["patchwork-incoming@legolas.ozlabs.org","libc-alpha@sourceware.org"],"Authentication-Results":["legolas.ozlabs.org;\n\tdkim=pass (2048-bit key;\n unprotected) header.d=linaro.org header.i=@linaro.org header.a=rsa-sha256\n header.s=google header.b=HedkJ7RF;\n\tdkim-atps=neutral","legolas.ozlabs.org;\n spf=pass (sender SPF authorized) smtp.mailfrom=sourceware.org\n (client-ip=38.145.34.32; helo=vm01.sourceware.org;\n envelope-from=libc-alpha-bounces~incoming=patchwork.ozlabs.org@sourceware.org;\n receiver=patchwork.ozlabs.org)","sourceware.org;\n\tdkim=pass (2048-bit key,\n unprotected) header.d=linaro.org header.i=@linaro.org header.a=rsa-sha256\n header.s=google header.b=HedkJ7RF","sourceware.org;\n dmarc=pass (p=none dis=none) header.from=linaro.org","sourceware.org; spf=pass smtp.mailfrom=linaro.org","server2.sourceware.org;\n arc=none smtp.remote-ip=2607:f8b0:4864:20::122d"],"Received":["from vm01.sourceware.org (vm01.sourceware.org [38.145.34.32])\n\t(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)\n\t key-exchange x25519 server-signature ECDSA (secp384r1) server-digest SHA384)\n\t(No client certificate requested)\n\tby legolas.ozlabs.org (Postfix) with ESMTPS id 4fzqlB233dz1yHr\n\tfor ; Tue, 21 Apr 2026 01:53:10 +1000 (AEST)","from vm01.sourceware.org (localhost [127.0.0.1])\n\tby sourceware.org (Postfix) with ESMTP id 645514AADCC8\n\tfor ; Mon, 20 Apr 2026 15:53:08 +0000 (GMT)","from mail-dl1-x122d.google.com (mail-dl1-x122d.google.com\n [IPv6:2607:f8b0:4864:20::122d])\n by sourceware.org (Postfix) with ESMTPS id 49E564B358B9\n for ; Mon, 20 Apr 2026 15:52:40 +0000 (GMT)","by mail-dl1-x122d.google.com with SMTP id\n a92af1059eb24-12c565dd3a7so83739c88.1\n for ; Mon, 20 Apr 2026 08:52:40 -0700 (PDT)","from ?IPV6:2804:1b3:a7c3:d5d0:c49:69f8:6bda:7b88?\n ([2804:1b3:a7c3:d5d0:c49:69f8:6bda:7b88])\n by smtp.gmail.com with ESMTPSA id\n a92af1059eb24-12c749c422csm15379094c88.3.2026.04.20.08.52.37\n (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);\n Mon, 20 Apr 2026 08:52:38 -0700 (PDT)"],"DKIM-Filter":["OpenDKIM Filter v2.11.0 sourceware.org 645514AADCC8","OpenDKIM Filter v2.11.0 sourceware.org 49E564B358B9"],"DMARC-Filter":"OpenDMARC Filter v1.4.2 sourceware.org 49E564B358B9","ARC-Filter":"OpenARC Filter v1.0.0 sourceware.org 49E564B358B9","ARC-Seal":"i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1776700363; cv=none;\n b=HCs0N/KZMOPNS7iHdtAweBNLzUI8FvxAYDwn2/Hn5GtU9R1UHdwzt2/RnSYcM7PbHdkeYVdGdjgH1qrjy+4kWl+JF8mIYqa2l2c9J9/mVqyK8aH8gBl2OtoCFiX/H7JkxWlVrLEG160LsoeYckvOjksej3Vm/2PtAUx2bZTH5dc=","ARC-Message-Signature":"i=1; a=rsa-sha256; d=sourceware.org; s=key;\n t=1776700363; c=relaxed/simple;\n bh=1ZQ/uZMn3Jf44GJY9DGNzNtiqi0MheJ9wCkMdIUcZpA=;\n h=DKIM-Signature:Message-ID:Date:MIME-Version:Subject:To:From;\n b=vSeSZ0ctdcHXQ/xU2pltiK/ELdYvwLFP3Ikh1WP0iJfFveNgPiEDhDZ6mRMkp3xQqdBLSezG9+VCcYxEbeB+VNA9v3MRDTU6l1Isipx5AFzJfgRq2EjvFwWsR75U5edqhO1QdIaP49SUA7lEim4+naziMdAL6jVQMqsF1md1x/s=","ARC-Authentication-Results":"i=1; server2.sourceware.org","DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed;\n d=linaro.org; s=google; t=1776700359; x=1777305159; darn=sourceware.org;\n h=content-transfer-encoding:in-reply-to:organization:from\n :content-language:references:cc:to:subject:user-agent:mime-version\n :date:message-id:from:to:cc:subject:date:message-id:reply-to;\n bh=aTDcbLbhB0cfWx/LF5sle1eo5KU/7KROy7nk/7S0sfE=;\n b=HedkJ7RF/dqVZqtR+o3e+p+8nbYVfxtNrjCIuSQbqvwIjnvMFEOSv4ktJ3TTSNzkut\n 2JF2g9XPj9Fe8/Xek5iywnpyXjf/+7y1lcALNxw3bU1nQPDNZvb5C2tvDPuLwCqcjSGf\n zRk8ADWU+oadZMH5LiNheDIqINFwgY3m+0z/YHrdL4cK9BN8oSrWksui//k73dA+5c+w\n kvzdtuHOBPrUbKcHOACDmZ982/Qc3IBhTte6ETgGuEyi925IkwmXIMj59EiL3+YWHXRS\n Vaznarvrsd5rqmMGg7YZWHZRo8fD8DJPQUqgZv/6zkP+eFrqal0TCnSEb9oApRtxYfpZ\n BlZg==","X-Google-DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed;\n d=1e100.net; s=20251104; t=1776700359; x=1777305159;\n h=content-transfer-encoding:in-reply-to:organization:from\n :content-language:references:cc:to:subject:user-agent:mime-version\n :date:message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date\n :message-id:reply-to;\n bh=aTDcbLbhB0cfWx/LF5sle1eo5KU/7KROy7nk/7S0sfE=;\n b=N9SX942+5lQeWDMLD/JLAySqt9J5KchS20vfAc7MpOxI2TFEOMFc5SLEXlO65/RocJ\n QaOeh9bmw75+45TWkU79eGkU2nv3FM5HBd57j+f4yruXJ/RX4TCZCl0eSfF4nO4TpHPW\n Sl/Mb54b5qi0rkaI1UO8lofHnazprUvuJ/pYv3fCkSyLxtaGixndLylk3T9AWEQP2cYg\n xYCAZ4FGqZaUpYo8U+CarCM4p+t/iSY3i5bu+ZfXJp/CtH0RPOGXxGlqUJ6VJ5v84iMq\n ms9LnvnwDnF4yjCsU2sFkRH+NYGluxG/xmJYToLWeyfgq0vH9ZGbMyRiB0iWoNHSielM\n osyg==","X-Forwarded-Encrypted":"i=1;\n AFNElJ/yOaZwxGLauqYLiDlUQVw0Jt+VHuZY88eNgv3Sq1QKnO4dkuwD1aA1jgkR9OtlvmAgAAvcmwbdswoo@sourceware.org","X-Gm-Message-State":"AOJu0Yw3cZ3hUSf0OpGPgwSqpb1s7lWtuSO9LoWjrkr0oc1rs+6IHLnK\n g8RpBGyE8ICKJQm5uLqgyt24Z3/CZJWMQ39g4Zgo7Job2zpH7MBdLWxqjB/9z29azeXlMztsaKz\n TO8nj","X-Gm-Gg":"AeBDievrxWDyezxpnPHmyzhQSFVRtgvSxtxNYSvnYRqC4Cya76Kc/xSjZQBhOXm3VYn\n omoe3G379/1BEZsgKIh/Gt9Uv+HPTPMy+zHdlexxUhYXiZObbz1jGjXmCTONDnxfLQnbHChuNgm\n zcvz2ApcC1Aid29D5VmzMYyBmJnKDMQGTiEY73KxMQhzZ7VQsL9K1gCGnc0lbRa/7CfdQQLWRaS\n gvMiL+OE7RkwrZerppW1bCH9NrO66B7vRhyGQBBzVoKrTfQWK2swCQSJmHpAruQ4ODRdK7SZsWI\n xO/VL2VWMStaIc8/JT1XH7iIzxnjgGi8N68OQ/KRpxmkYEjHq4UHtgQHK5MUQc7Dgl/y3xicg5q\n 5LGERwG9YxzpOFtmGFQci4266oYucK2ISDt4iB/ossvGSGvE1qktI2hLRs4AXfcUpPoQXV6Xph4\n POvMg+cFUSL5Ht1pp9RIqmnsAz2IbqFHEMQwUWwbjrq6DNO9DlbjWSRpR9Qdx+ipHJA5Lz8Buqh\n DwquHj2Gm38dU11LHcDN7JKC3vNh5Y5ttvctChsJQ==","X-Received":"by 2002:a05:7022:6b96:b0:11b:bf3f:5240 with SMTP id\n a92af1059eb24-12c73f70cd0mr6503146c88.9.1776700359060;\n Mon, 20 Apr 2026 08:52:39 -0700 (PDT)","Message-ID":"","Date":"Mon, 20 Apr 2026 12:52:35 -0300","MIME-Version":"1.0","User-Agent":"Mozilla Thunderbird","Subject":"Re: [PATCH] nptl: futex_lock_pi deadlock detection provides valuable\n information but it is turned into a rather cryptic assertion failure","To":"\"Moritz KLAMMLER (FERCHAU)\" ,\n Florian Weimer ","Cc":"Carlos O'Donell ,\n \"libc-alpha@sourceware.org\" ","References":"\n \n <2bf1c649-8a6a-4f9e-9bc7-c01f2fce81c6@linaro.org>\n \n <34621bae-9591-4a43-84f8-245692d31fbc@linaro.org>\n \n <52db35a1-7d72-40d5-9c6f-3e5082402c7b@linaro.org>\n <23650a5e-baf4-4811-91f8-6950b1d0a3ed@redhat.com>\n \n <52c94712-799a-42e8-b996-526728f8b8bd@linaro.org>\n \n <75b91c7c-385f-41d1-8ddc-fa1b86cefe8f@linaro.org>\n ","Content-Language":"en-US","From":"Adhemerval Zanella Netto ","Organization":"Linaro","In-Reply-To":"\n ","Content-Type":"text/plain; charset=UTF-8","Content-Transfer-Encoding":"7bit","X-BeenThere":"libc-alpha@sourceware.org","X-Mailman-Version":"2.1.30","Precedence":"list","List-Id":"Libc-alpha mailing list ","List-Unsubscribe":",\n ","List-Archive":"","List-Post":"","List-Help":"","List-Subscribe":",\n ","Errors-To":"libc-alpha-bounces~incoming=patchwork.ozlabs.org@sourceware.org"}}]