From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-3.1 required=5.0 tests=DKIM_INVALID,DKIM_SIGNED, HTML_MESSAGE,MAILING_LIST_MULTI,RCVD_IN_DNSWL_MED,RCVD_IN_MSPIKE_H3, RCVD_IN_MSPIKE_WL autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 26078 invoked from network); 24 Sep 2020 15:08:36 -0000 Received: from mother.openwall.net (195.42.179.200) by inbox.vuxu.org with ESMTPUTF8; 24 Sep 2020 15:08:36 -0000 Received: (qmail 5266 invoked by uid 550); 24 Sep 2020 15:08:31 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Reply-To: musl@lists.openwall.com Received: (qmail 32311 invoked from network); 24 Sep 2020 14:58:40 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=iotechsys-com.20150623.gappssmtp.com; s=20150623; h=mime-version:from:date:message-id:subject:to; bh=kmZEzUDFXzLNMOS4Gi+jO3xFYzwfjzb2e6Im0CWBytU=; b=UbMprfZ7AhM5pxDdFrIhCktBU4DK6jVgYysEs6/IQydWCxlKpFMIFUXCM2BgQCrYbd P84ips5IcyprPyuRjS4MwXPdyLmBhyQfCQO9t/h5Ec8ZCPcE/XyjDplj6Ux0/1mNqcKK TuHh5yhyQFIp5KjhNj1OKdSF9gDcCpi2bLKPT1+cpLUPVlNQpzKMIBn4FFOHzfxi+7e0 poRe6cPP2q/37EtbayU5Y3EQAM4WuvG2mTdGWclZC+2wMe2q1/PQKSzlB71FVG+dZKbI K9il5IUCftdPTkH7Jow/1At+BVNI1/bexHSzAEJpbjTXnqtYDuj/X++jI2oFC0jKf4T1 IZxw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=kmZEzUDFXzLNMOS4Gi+jO3xFYzwfjzb2e6Im0CWBytU=; b=SAt/YCCkRndTIsa7SlUvo1QjegWGvWo9Jw4Ls4mlXWJk9RpIsxklwrOPa2t9sz5DCU wYnZYXONwGQikZtSF/Pd3QYDZyXMnDMPVHDqV6HC5CFJvc59zv9+EZRs1K4QY/dk3hdm dpceJfRuqJapA63/gXd273amS1WpwHvbfyqqSymKIAtfdmv8jJChX3gh7TvH6H48cLvI 12BAhZBQiuagz6PcSVY5igc+rjTyrfqsAeSZhJg1acdAmZv3abA7BbAHJcXEoE9Agk2M LCmaf9ojLilWukT77o7XSnunQ7lRrdb4SKHad3VF0dYad2oskTTConz5kpnzhD1auXgZ Ggow== X-Gm-Message-State: AOAM5306BitlakKVPq4jtDop2qq+L2zO7QDoakr58H+grPLEAwm0cysO OlJOZJPfekO3JSRmrlTM5vLZ478kNk8J8AXol7waXeoPklCy9g== X-Google-Smtp-Source: ABdhPJzgSPlhZ1bFo4RdoqZqkZ04md5thfrRHK/XbiuZsZ/5raMIFu0sqF/RnX8WC06QiNTpJvlBE3OCcNLCCyQeAqQ= X-Received: by 2002:a37:ac09:: with SMTP id e9mr23661qkm.213.1600959508050; Thu, 24 Sep 2020 07:58:28 -0700 (PDT) MIME-Version: 1.0 From: Edward Scott Date: Thu, 24 Sep 2020 15:58:17 +0100 Message-ID: To: musl@lists.openwall.com Content-Type: multipart/alternative; boundary="000000000000c71b8305b0106ec7" Subject: [musl] Bug with priority inheritance and condition variables --000000000000c71b8305b0106ec7 Content-Type: text/plain; charset="UTF-8" Hello, There appears to be a bug when using priority inheritance in combination with condition variables. I have some code that reproduces the bug: https://github.com/edward-scott/musl-prio-inherit-cv-bug Using git bisect I traced the origin of the bug to this commit: https://git.musl-libc.org/cgit/musl/commit/?id=54ca677983d47529bab8752315ac1a2b49888870 which is the commit that is described as "implement priority inheritance mutexes". >From my analysis it appears that _m_waiters is used by the priority inheritance logic to maintain some state (as described in the commit message) but that conflicts with some use of _m_waiters in the condition variable implementation. The consequence is that pthread_mutex_lock erroneously returns EDEADLK. I don't understand the code well enough to produce a fix. The demo code (a cut version of some production code) will reproduce the failure. Commenting out the pthread_mutexattr_setprotocol call in the iot_mutex_init function at the end of the thread.c file will cause the code to work as intended (without priority inheritance). The code works fine either way with the GNU lib. BTW can I recommend that the "magic numbers" used to represent mutex modes be replaced at some point with defined constants as it would make the code much easier to follow. This is my first post to this list so I hope this message is on the right list and is helpful. Edward Scott --000000000000c71b8305b0106ec7 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hello,

There appears to be a bug when u= sing=C2=A0priority inheritance in combination with condition variables. I h= ave some code that reproduces the bug:


Us= ing git bisect I traced the origin of the bug to this commit:
which is the commit that is described as "implement priori= ty inheritance mutexes".

From my analysis it = appears that _m_waiters is used by the priority=C2=A0inheritance logic to m= aintain some state (as described=C2=A0in the commit message) but that confl= icts with some use of _m_waiters in the condition variable implementation.<= /div>

The consequence is that=C2=A0pthread_mutex_lock er= roneously returns=C2=A0EDEADLK.

I don't unders= tand the code well enough=C2=A0to produce a fix.

T= he demo code (a cut version of some production code) will reproduce the fai= lure. Commenting out the=C2=A0pthread_mutexattr_setprotocol call in the=C2= =A0iot_mutex_init function=C2=A0at the end of the thread.c file will cause = the code to work as intended (without priority inheritance). The code works= fine either way with the GNU lib.

BTW can I recom= mend that the "magic numbers"=C2=A0 used to represent mutex modes= be replaced at some point with defined constants as it would make the code= much easier to follow.

This is my first post to t= his list so I hope this message is on the right list and is helpful.
<= div>
Edward Scott

--000000000000c71b8305b0106ec7--