From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by sourceware.org (Postfix) with ESMTPS id 861DB3860C08 for ; Fri, 27 May 2022 07:36:45 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 861DB3860C08 Received: from mimecast-mx02.redhat.com (mx3-rdu2.redhat.com [66.187.233.73]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-610-HhPnR2-4OZ-lJ4VKIcpKEw-1; Fri, 27 May 2022 03:36:41 -0400 X-MC-Unique: HhPnR2-4OZ-lJ4VKIcpKEw-1 Received: from smtp.corp.redhat.com (int-mx04.intmail.prod.int.rdu2.redhat.com [10.11.54.4]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id 754E729AB419; Fri, 27 May 2022 07:36:21 +0000 (UTC) Received: from oldenburg.str.redhat.com (unknown [10.39.192.71]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 8AB9420296A6; Fri, 27 May 2022 07:36:06 +0000 (UTC) From: Florian Weimer To: Noah Goldstein Cc: Noah Goldstein via Libc-alpha Subject: Re: Questions regarding pthread mutex lock/unlock functions in pthread_cond_wait? References: <87y1yoaf5q.fsf@oldenburg.str.redhat.com> <87k0a89skp.fsf@oldenburg.str.redhat.com> Date: Fri, 27 May 2022 09:36:03 +0200 In-Reply-To: (Noah Goldstein's message of "Thu, 26 May 2022 19:10:13 -0500") Message-ID: <87bkvjh1gc.fsf@oldenburg.str.redhat.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.2 (gnu/linux) MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.78 on 10.11.54.4 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain X-Spam-Status: No, score=-5.4 required=5.0 tests=BAYES_00, DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_NONE, TXREP, T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org X-BeenThere: libc-alpha@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Libc-alpha mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 May 2022 07:36:47 -0000 * Noah Goldstein: > On Thu, May 26, 2022 at 11:17 AM Florian Weimer wrote: >> >> * Noah Goldstein: >> >> > On Thu, May 26, 2022 at 3:09 AM Florian Weimer wrote: >> >> >> >> * Noah Goldstein via Libc-alpha: >> >> >> >> > 1) Do we need `__pthread_mutex_unlock_usercnt`? >> >> >> >> POSIX says: >> >> >> >> | Attempting to destroy a locked mutex, or a mutex that another thread >> >> | is attempting to lock, or a mutex that is being used in a >> >> | pthread_cond_timedwait() or pthread_cond_wait() call by another >> >> | thread, results in undefined behavior. >> >> >> >> This does not change for PTHREAD_MUTEX_ERRORCHECK mutexes, so I think we >> >> can remove usercnt. >> > >> > Open to a patch removing the `__pthread_mutex_unlock_usercnt` >> > function? >> >> And for making that field unused, yes. > > We have a fair number of tests to check that destroy on a "used" lock > returns EBUSY. Yes, I think those are invalid and needs to be adjusted. LTP probably needs updating as well. > User code might have started to rely on it. Maybe best to keep or you > think still go ahead? For robust mutexes, maybe we should remove a locked mutex from the current thread's locked list instead. Not doing so causes memory corruption at a distance that could be difficult to debug. That would be an improvement over the current situation, I think. Thanks, Florian