From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-qt1-x843.google.com (mail-qt1-x843.google.com [IPv6:2607:f8b0:4864:20::843]) by sourceware.org (Postfix) with ESMTPS id 7B9E93857C6B for ; Wed, 30 Sep 2020 13:14:07 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 7B9E93857C6B Received: by mail-qt1-x843.google.com with SMTP id v54so1087847qtj.7 for ; Wed, 30 Sep 2020 06:14:07 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:autocrypt :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=74Byarv1d+oj2AaBpxSGgxqjEyh6BJvsDitemB2lnok=; b=eXlkx116QOUk+srnpVlY01mfvVOAO+VQgjiMq/TGEVHV3oLUEetjd4mGL1O0hWtyMd dHbUfM8ybolVF9ANzR6qso76BkiOPAM8eKYTj/zFfXJzanMUi93A+DxABR5O3klPBzJW 1N092xcbuno7/D4KXviEGll6o1sqyzO1rYUOd5w+hNZkAfcFm0F/st4EqjQ7us5ZlGR/ CGCDywoQgoQV0mcSfd575Bzyjrh/E7XIcaF9uWETmrdwStUO56Jmzhe/y4eXSz1zTzJq rnQWaCNn6TyJu6IvXHVgpCgivAW61OTj5oHnhv/XR1J27xrRc4tfZtb2eJM3fJcbRpp4 DdpQ== X-Gm-Message-State: AOAM530lfna0joJUdTbTu849JxG0VUIONTs/cSHXtQYQNC957HDs+GwV GU9Mil6fAmszQePU7hreql42IQ== X-Google-Smtp-Source: ABdhPJyhm51POfv0+6DK4fchOhg49yvw41RA/BgsMiezzCUS4hx8v1UywkTv1OJHL9AHMoGVo5mg1A== X-Received: by 2002:ac8:6f12:: with SMTP id g18mr2192578qtv.217.1601471646482; Wed, 30 Sep 2020 06:14:06 -0700 (PDT) Received: from [192.168.1.4] ([177.194.48.209]) by smtp.googlemail.com with ESMTPSA id a12sm1920174qkh.31.2020.09.30.06.14.02 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 30 Sep 2020 06:14:05 -0700 (PDT) Subject: Re: [PATCH v2 2/3] Y2038: nptl: Provide futex_abstimed_wait64 supporting 64 bit time To: Lukasz Majewski Cc: Joseph Myers , Paul Eggert , Alistair Francis , Arnd Bergmann , Alistair Francis , GNU C Library , Florian Weimer , Carlos O'Donell , Stepan Golosunov , Andreas Schwab , Zack Weinberg , Jeff Law References: <20200919130759.31916-1-lukma@denx.de> <20200919130759.31916-2-lukma@denx.de> <20200930144710.662d9d99@jawa> From: Adhemerval Zanella Autocrypt: addr=adhemerval.zanella@linaro.org; prefer-encrypt=mutual; keydata= mQINBFcVGkoBEADiQU2x/cBBmAVf5C2d1xgz6zCnlCefbqaflUBw4hB/bEME40QsrVzWZ5Nq 8kxkEczZzAOKkkvv4pRVLlLn/zDtFXhlcvQRJ3yFMGqzBjofucOrmdYkOGo0uCaoJKPT186L NWp53SACXguFJpnw4ODI64ziInzXQs/rUJqrFoVIlrPDmNv/LUv1OVPKz20ETjgfpg8MNwG6 iMizMefCl+RbtXbIEZ3TE/IaDT/jcOirjv96lBKrc/pAL0h/O71Kwbbp43fimW80GhjiaN2y WGByepnkAVP7FyNarhdDpJhoDmUk9yfwNuIuESaCQtfd3vgKKuo6grcKZ8bHy7IXX1XJj2X/ BgRVhVgMHAnDPFIkXtP+SiarkUaLjGzCz7XkUn4XAGDskBNfbizFqYUQCaL2FdbW3DeZqNIa nSzKAZK7Dm9+0VVSRZXP89w71Y7JUV56xL/PlOE+YKKFdEw+gQjQi0e+DZILAtFjJLoCrkEX w4LluMhYX/X8XP6/C3xW0yOZhvHYyn72sV4yJ1uyc/qz3OY32CRy+bwPzAMAkhdwcORA3JPb kPTlimhQqVgvca8m+MQ/JFZ6D+K7QPyvEv7bQ7M+IzFmTkOCwCJ3xqOD6GjX3aphk8Sr0dq3 4Awlf5xFDAG8dn8Uuutb7naGBd/fEv6t8dfkNyzj6yvc4jpVxwARAQABtElBZGhlbWVydmFs IFphbmVsbGEgTmV0dG8gKExpbmFybyBWUE4gS2V5KSA8YWRoZW1lcnZhbC56YW5lbGxhQGxp bmFyby5vcmc+iQI3BBMBCAAhBQJXFRpKAhsDBQsJCAcDBRUKCQgLBRYCAwEAAh4BAheAAAoJ EKqx7BSnlIjv0e8P/1YOYoNkvJ+AJcNUaM5a2SA9oAKjSJ/M/EN4Id5Ow41ZJS4lUA0apSXW NjQg3VeVc2RiHab2LIB4MxdJhaWTuzfLkYnBeoy4u6njYcaoSwf3g9dSsvsl3mhtuzm6aXFH /Qsauav77enJh99tI4T+58rp0EuLhDsQbnBic/ukYNv7sQV8dy9KxA54yLnYUFqH6pfH8Lly sTVAMyi5Fg5O5/hVV+Z0Kpr+ZocC1YFJkTsNLAW5EIYSP9ftniqaVsim7MNmodv/zqK0IyDB GLLH1kjhvb5+6ySGlWbMTomt/or/uvMgulz0bRS+LUyOmlfXDdT+t38VPKBBVwFMarNuREU2 69M3a3jdTfScboDd2ck1u7l+QbaGoHZQ8ZNUrzgObltjohiIsazqkgYDQzXIMrD9H19E+8fw kCNUlXxjEgH/Kg8DlpoYJXSJCX0fjMWfXywL6ZXc2xyG/hbl5hvsLNmqDpLpc1CfKcA0BkK+ k8R57fr91mTCppSwwKJYO9T+8J+o4ho/CJnK/jBy1pWKMYJPvvrpdBCWq3MfzVpXYdahRKHI ypk8m4QlRlbOXWJ3TDd/SKNfSSrWgwRSg7XCjSlR7PNzNFXTULLB34sZhjrN6Q8NQZsZnMNs TX8nlGOVrKolnQPjKCLwCyu8PhllU8OwbSMKskcD1PSkG6h3r0AquQINBFcVGkoBEACgAdbR Ck+fsfOVwT8zowMiL3l9a2DP3Eeak23ifdZG+8Avb/SImpv0UMSbRfnw/N81IWwlbjkjbGTu oT37iZHLRwYUFmA8fZX0wNDNKQUUTjN6XalJmvhdz9l71H3WnE0wneEM5ahu5V1L1utUWTyh VUwzX1lwJeV3vyrNgI1kYOaeuNVvq7npNR6t6XxEpqPsNc6O77I12XELic2+36YibyqlTJIQ V1SZEbIy26AbC2zH9WqaKyGyQnr/IPbTJ2Lv0dM3RaXoVf+CeK7gB2B+w1hZummD21c1Laua +VIMPCUQ+EM8W9EtX+0iJXxI+wsztLT6vltQcm+5Q7tY+HFUucizJkAOAz98YFucwKefbkTp eKvCfCwiM1bGatZEFFKIlvJ2QNMQNiUrqJBlW9nZp/k7pbG3oStOjvawD9ZbP9e0fnlWJIsj 6c7pX354Yi7kxIk/6gREidHLLqEb/otuwt1aoMPg97iUgDV5mlNef77lWE8vxmlY0FBWIXuZ yv0XYxf1WF6dRizwFFbxvUZzIJp3spAao7jLsQj1DbD2s5+S1BW09A0mI/1DjB6EhNN+4bDB SJCOv/ReK3tFJXuj/HbyDrOdoMt8aIFbe7YFLEExHpSk+HgN05Lg5TyTro8oW7TSMTk+8a5M kzaH4UGXTTBDP/g5cfL3RFPl79ubXwARAQABiQIfBBgBCAAJBQJXFRpKAhsMAAoJEKqx7BSn lIjvI/8P/jg0jl4Tbvg3B5kT6PxJOXHYu9OoyaHLcay6Cd+ZrOd1VQQCbOcgLFbf4Yr+rE9l mYsY67AUgq2QKmVVbn9pjvGsEaz8UmfDnz5epUhDxC6yRRvY4hreMXZhPZ1pbMa6A0a/WOSt AgFj5V6Z4dXGTM/lNManr0HjXxbUYv2WfbNt3/07Db9T+GZkpUotC6iknsTA4rJi6u2ls0W9 1UIvW4o01vb4nZRCj4rni0g6eWoQCGoVDk/xFfy7ZliR5B+3Z3EWRJcQskip/QAHjbLa3pml xAZ484fVxgeESOoaeC9TiBIp0NfH8akWOI0HpBCiBD5xaCTvR7ujUWMvhsX2n881r/hNlR9g fcE6q00qHSPAEgGr1bnFv74/1vbKtjeXLCcRKk3Ulw0bY1OoDxWQr86T2fZGJ/HIZuVVBf3+ gaYJF92GXFynHnea14nFFuFgOni0Mi1zDxYH/8yGGBXvo14KWd8JOW0NJPaCDFJkdS5hu0VY 7vJwKcyHJGxsCLU+Et0mryX8qZwqibJIzu7kUJQdQDljbRPDFd/xmGUFCQiQAncSilYOcxNU EMVCXPAQTteqkvA+gNqSaK1NM9tY0eQ4iJpo+aoX8HAcn4sZzt2pfUB9vQMTBJ2d4+m/qO6+ cFTAceXmIoFsN8+gFN3i8Is3u12u8xGudcBPvpoy4OoG Message-ID: Date: Wed, 30 Sep 2020 10:14:00 -0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 MIME-Version: 1.0 In-Reply-To: <20200930144710.662d9d99@jawa> Content-Type: text/plain; charset=windows-1252 Content-Language: en-US Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-13.6 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, GIT_PATCH_0, NICE_REPLY_A, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) 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: Wed, 30 Sep 2020 13:14:09 -0000 On 30/09/2020 09:47, Lukasz Majewski wrote: > Hi Adhemerval, > >> On 19/09/2020 10:07, Lukasz Majewski wrote: >>> This is the helper function, which uses struct __timespec64 >>> to provide 64 bit absolute time to futex syscalls. >>> >>> The aim of this function is to move convoluted pre-processor >>> macro code from sysdeps/nptl/lowlevellock-futex.h to C >>> function in futex-internal.c >>> >>> The futex_abstimed_wait64 function has been put into a separate >>> file on the purpose - to avoid issues apparent on the m68k >>> architecture related to small number of available registers (there >>> is not enough registers to put all necessary arguments in them if >>> the above function would be added to futex-internal.h with >>> __always_inline attribute). >>> >>> Additional precautions for m68k port have been taken - the >>> futex-internal.c file will be compiled with -fno-inline flag. >> >> LGTM with a nit regarding style and a clarification about >> '-fno-inline'. > > Please find the explanation below. > >> >>> >>> --- >>> Changes for v2: >>> - Handle the case when *abstime pointer is NULL >>> --- >>> sysdeps/nptl/futex-internal.c | 70 >>> +++++++++++++++++++++++++++ sysdeps/nptl/futex-internal.h | >>> 6 +++ sysdeps/unix/sysv/linux/m68k/Makefile | 2 + >>> 3 files changed, 78 insertions(+) >>> >>> diff --git a/sysdeps/nptl/futex-internal.c >>> b/sysdeps/nptl/futex-internal.c index 3366aac162..3211b4c94f 100644 >>> --- a/sysdeps/nptl/futex-internal.c >>> +++ b/sysdeps/nptl/futex-internal.c >>> @@ -45,6 +45,29 @@ __futex_abstimed_wait_cancelable32 (unsigned >>> int* futex_word, abstime != NULL ? &ts32 : NULL, >>> NULL /* Unused. */, >>> FUTEX_BITSET_MATCH_ANY); } >>> + >>> +static int >>> +__futex_abstimed_wait32 (unsigned int* futex_word, >>> + unsigned int expected, clockid_t clockid, >>> + const struct __timespec64* abstime, >>> + int private) >>> +{ >>> + struct timespec ts32; >>> + >>> + if (abstime != NULL && ! in_time_t_range (abstime->tv_sec)) >>> + return -EOVERFLOW; >>> + >>> + unsigned int clockbit = (clockid == CLOCK_REALTIME) ? >>> + FUTEX_CLOCK_REALTIME : 0; >>> + int op = __lll_private_flag (FUTEX_WAIT_BITSET | clockbit, >>> private); + >>> + if (abstime != NULL) >>> + ts32 = valid_timespec64_to_timespec (*abstime); >>> + >>> + return INTERNAL_SYSCALL_CALL (futex, futex_word, op, expected, >>> + abstime != NULL ? &ts32 : NULL, >>> + NULL /* Unused. */, >>> FUTEX_BITSET_MATCH_ANY); +} >>> #endif >>> >>> int >> >> Ok. >> >>> @@ -97,3 +120,50 @@ __futex_abstimed_wait_cancelable64 (unsigned >>> int* futex_word, futex_fatal_error (); >>> } >>> } >>> + >>> +int >>> +__futex_abstimed_wait64 (unsigned int* futex_word, unsigned int >>> expected, >>> + clockid_t clockid, >>> + const struct __timespec64* abstime, int >>> private) +{ >>> + unsigned int clockbit; >>> + int err; >>> + >>> + /* Work around the fact that the kernel rejects negative timeout >>> values >>> + despite them being valid. */ >>> + if (__glibc_unlikely ((abstime != NULL) && (abstime->tv_sec < >>> 0))) >>> + return ETIMEDOUT; >>> + >>> + if (! lll_futex_supported_clockid(clockid)) >>> + return EINVAL; >> >> Space before parentheses. > > Ok. Fixed. > >> >>> + >>> + clockbit = (clockid == CLOCK_REALTIME) ? FUTEX_CLOCK_REALTIME : >>> 0; >>> + int op = __lll_private_flag (FUTEX_WAIT_BITSET | clockbit, >>> private); + >>> + err = INTERNAL_SYSCALL_CALL (futex_time64, futex_word, op, >>> expected, >>> + abstime, NULL /* Unused. */, >>> + FUTEX_BITSET_MATCH_ANY); >>> +#ifndef __ASSUME_TIME64_SYSCALLS >>> + if (err == -ENOSYS) >>> + err = __futex_abstimed_wait32 (futex_word, expected, >>> + clockid, abstime, private); >>> +#endif >>> + switch (err) >>> + { >>> + case 0: >>> + case -EAGAIN: >>> + case -EINTR: >>> + case -ETIMEDOUT: >>> + return -err; >>> + >>> + case -EFAULT: /* Must have been caused by a glibc or >>> application bug. */ >>> + case -EINVAL: /* Either due to wrong alignment, unsupported >>> + clockid or due to the timeout not being >>> + normalized. Must have been caused by a glibc >>> or >>> + application bug. */ >>> + case -ENOSYS: /* Must have been caused by a glibc bug. */ >>> + /* No other errors are documented at this time. */ >>> + default: >>> + futex_fatal_error (); >>> + } >>> +} >> >> Ok. >> >>> diff --git a/sysdeps/nptl/futex-internal.h >>> b/sysdeps/nptl/futex-internal.h index 7f3910ad98..1ba0d61938 100644 >>> --- a/sysdeps/nptl/futex-internal.h >>> +++ b/sysdeps/nptl/futex-internal.h >>> @@ -529,4 +529,10 @@ __futex_abstimed_wait_cancelable64 (unsigned >>> int* futex_word, const struct __timespec64* abstime, >>> int private) attribute_hidden; >>> >>> +int >>> +__futex_abstimed_wait64 (unsigned int* futex_word, unsigned int >>> expected, >>> + clockid_t clockid, >>> + const struct __timespec64* abstime, >>> + int private) attribute_hidden; >>> + >>> #endif /* futex-internal.h */ >> >> Ok. >> >>> diff --git a/sysdeps/unix/sysv/linux/m68k/Makefile >>> b/sysdeps/unix/sysv/linux/m68k/Makefile index >>> be40fae68a..65164c5752 100644 --- >>> a/sysdeps/unix/sysv/linux/m68k/Makefile +++ >>> b/sysdeps/unix/sysv/linux/m68k/Makefile @@ -21,3 +21,5 @@ >>> sysdep-dl-routines += dl-static sysdep-others += lddlibc4 >>> install-bin += lddlibc4 >>> endif >>> + >>> +CFLAGS-futex-internal.c += -fno-inline >>> >> >> Do we still need it? > > Unfortunately, yes. The m68k architecture has the issue with properly > compiling this code (in futex-internal.c) as it has very limited number > of registers (8 x 32 bit IIRC). > > I did some investigation and it looks like static inline > in_time_t_range() function affects the compiler capabilities to > generate correct code. > > It can be easily inlined on any architecture but m68k. > > As m68k has issues with this code compilation - it is IMHO better to > disable inlining (-fno-inline) on this particular port. > > As a result we would have slower execution only on relevant functions, > but 64 bit time support would be provided. I recall this was need on first patch for the cancellable 64-bit futex_abstimed_wait where it embedded the 32-bit fallback in the __futex_abstimed_wait_cancelable64. And my suggestion to move it to an external function seems to avoid the extra compiler flag. This patchset uses the same strategy and I checked both patches and it seems that -fno-inline is not required to build m68k.