From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on dcvr.yhbt.net X-Spam-Level: X-Spam-ASN: AS31976 209.132.180.0/23 X-Spam-Status: No, score=-4.0 required=3.0 tests=AWL,BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_EF,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,RCVD_IN_DNSWL_MED,SPF_HELO_PASS,SPF_PASS shortcircuit=no autolearn=ham autolearn_force=no version=3.4.2 Received: from sourceware.org (server1.sourceware.org [209.132.180.131]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dcvr.yhbt.net (Postfix) with ESMTPS id 1CD861F461 for ; Tue, 25 Jun 2019 12:07:10 +0000 (UTC) DomainKey-Signature: a=rsa-sha1; c=nofws; d=sourceware.org; h=list-id :list-unsubscribe:list-subscribe:list-archive:list-post :list-help:sender:from:to:cc:subject:references:date:in-reply-to :message-id:mime-version:content-type; q=dns; s=default; b=VxKIB hgGEeEwYBwT7VO9+LKnueBKA8P527ha05gmfEuxKf0vfiZZQCrF6BkDfXT+Xvnbr ogaiwQLQinn5tr58ezM/ZdBQduk+kAFqyEDeLWbnOxjCASHLzTDEHpQLbrur88vg CHflFG7R09zYUQqByXEhfZ1/0y59ULZge8yyXo= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=sourceware.org; h=list-id :list-unsubscribe:list-subscribe:list-archive:list-post :list-help:sender:from:to:cc:subject:references:date:in-reply-to :message-id:mime-version:content-type; s=default; bh=mpf+DeEYUuL w4dikZXHA6vMOlMI=; b=uVZUnO1m3MuaWFpCnyg5qGRBIE/c+aNoTp+hn9Orugz t75N+ewtdtmyY1THyQ00eWHD1J6moHtIOvPvSnkbK2b5xQnQVI9PaRlJHobsSADf fZ1dPRUIdjg/CTZ9QwLzlPekSJquxdvLOD4fbC+jFXGwIIWzepo+A/y/+C5TqzjU = Received: (qmail 95880 invoked by alias); 25 Jun 2019 12:07:07 -0000 Mailing-List: contact libc-alpha-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Unsubscribe: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: libc-alpha-owner@sourceware.org Received: (qmail 95867 invoked by uid 89); 25 Jun 2019 12:07:07 -0000 Authentication-Results: sourceware.org; auth=none X-HELO: mx1.redhat.com From: Florian Weimer To: Arnd Bergmann Cc: Andreas Schwab , Alistair Francis , GNU C Library , Adhemerval Zanella , Palmer Dabbelt , macro@wdc.com, Zong Li , Zong Li , Alistair Francis Subject: Re: [RFC v2 06/20] sysdeps/futex: Use futex_time64 if avaliable References: <1e92bb4f2cc06e8f3adfbd9de653c8e93c0d288a.1561421042.git.alistair.francis@wdc.com> <877e996hnp.fsf@oldenburg2.str.redhat.com> Date: Tue, 25 Jun 2019 14:06:48 +0200 In-Reply-To: (Arnd Bergmann's message of "Tue, 25 Jun 2019 13:41:29 +0200") Message-ID: <87blyl50o7.fsf@oldenburg2.str.redhat.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain * Arnd Bergmann: > On Tue, Jun 25, 2019 at 1:26 PM Andreas Schwab wrote: >> On Jun 25 2019, Florian Weimer wrote: >> > >> > I don't think a compile-time check in generic code is correct here. It >> > will cause binaries to fail to run on older kernels which do not have >> > the system call. This is obviously not a concern for 32-bit RISC-V, but >> > it is not acceptable for i386, for example. >> > >> > I still think you should define __NR_futex in RV32 . >> >> For existing 32-bit archs there needs to be a runtime check (if both >> __NR_futex and __NR_futex_time64 are defined). > > That opens the question what type this function should take, > because one of the two will require the time argument to be > converted. > > For instance pthread_timedjoin_np() is a public interface > that will need an additional version to deal with time64. > Should pthread_timedjoin_np() convert the user timespec > to __timespec64 and pass it down to lll_futex_syscall(), > which then converts it back to timespec before calling > __NR_futex() on 32-bit architectures, or is there a way to > avoid the double conversion? My expectation is that glibc will not provide a 32-bit struct timespec for architectures which do not have a 32-bit __NR_futex system call. It's a 64-bit only world. Before the 2038 deadline, we will not support kernels that removed support for the 32-bit system calls. Based on that, I expect that the 32-bit struct timespec variant of pthread_timedjoin_np calls futex, and the 64-bit variant (probably named pthread_timedjoin64_np or something like that, or used by default under appropriate feature selection macros) will call futex_time64. This has the advantage that the type of call is visible at the syscall layer, and could eventually trigger kenrel warnings. With translation, that wouldn't be the case. It also increases compatibility with seccomp filters which know of the old system calls, but not the new ones. Thanks, Florian