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 [216.205.24.124]) by sourceware.org (Postfix) with ESMTP id D648A385840D for ; Mon, 30 Aug 2021 09:31:01 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org D648A385840D Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-419-u9xMilKqN4K00KMYGcIttA-1; Mon, 30 Aug 2021 05:31:00 -0400 X-MC-Unique: u9xMilKqN4K00KMYGcIttA-1 Received: from smtp.corp.redhat.com (int-mx04.intmail.prod.int.phx2.redhat.com [10.5.11.14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 2C9ED8799E0; Mon, 30 Aug 2021 09:30:59 +0000 (UTC) Received: from oldenburg.str.redhat.com (unknown [10.39.194.140]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 52B2D5D9DE; Mon, 30 Aug 2021 09:30:58 +0000 (UTC) From: Florian Weimer To: Adhemerval Zanella Cc: libc-alpha@sourceware.org Subject: Re: [PATCH v2 10/19] nptl: Use tidlock when accessing TID on pthread_getaffinity_np References: <20210823195047.543237-1-adhemerval.zanella@linaro.org> <20210823195047.543237-11-adhemerval.zanella@linaro.org> <874kbc707x.fsf@oldenburg.str.redhat.com> Date: Mon, 30 Aug 2021 11:30:56 +0200 In-Reply-To: (Adhemerval Zanella's message of "Thu, 26 Aug 2021 14:29:38 -0300") Message-ID: <87lf4js2i7.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.79 on 10.5.11.14 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain X-Spam-Status: No, score=-6.7 required=5.0 tests=BAYES_00, DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, RCVD_IN_DNSWL_LOW, RCVD_IN_MSPIKE_H2, SPF_HELO_NONE, SPF_NONE, TXREP autolearn=ham autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) 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: Mon, 30 Aug 2021 09:31:03 -0000 * Adhemerval Zanella: >> The pthread_cancel reference looks like a cut-and-paste-bug. > > It is, but I think it is applicable. Maybe: > > /* Block all signal, since the lock is not recursive and used on > async-signal-safe functions. */ Just mention async-signal-safe, please. I do not think recursive locks can achieve async-signal-safety. >>> + sigset_t oldmask; >>> + __libc_signal_block_all (&oldmask); >>> + lll_lock (pd->tidlock, LLL_PRIVATE); >>> + >>> + int res = pd->tid == 0 >>> + ? -ESRCH >>> + : INTERNAL_SYSCALL_CALL (sched_getaffinity, pd->tid, >>> + MIN (INT_MAX, cpusetsize), cpuset); >>> + >>> + lll_unlock (pd->tidlock, LLL_PRIVATE); >>> + __libc_signal_restore_set (&oldmask); >>> + >>> + if (res < 0) >>> + return -res; >> >> ESRCH doesn't look like the right error code here. Should we return an >> affinity mask without any bits set? > > Why not? Returning anything but an error does not improve things here > since the information won't make much sense. Also it follows what other > symbols is already doing (such as pthread_cancel()). POSIX reserves ESRCH for using a pthread_t thread ID outside of the thread lifetime. In glibc, this is always undefined. In contrast, the case above involves a valid thread ID of a thread that has exited. Returning ESRCH suggests that the thread lifetime has ended, which is not true. Thanks, Florian