From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-qk1-x743.google.com (mail-qk1-x743.google.com [IPv6:2607:f8b0:4864:20::743]) by sourceware.org (Postfix) with ESMTPS id BCAF3385141E for ; Wed, 25 Nov 2020 17:56:57 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org BCAF3385141E Received: by mail-qk1-x743.google.com with SMTP id y18so5441582qki.11 for ; Wed, 25 Nov 2020 09:56:57 -0800 (PST) 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=y57krgt4oxhkvhmias0HhuT7nVBbPhOZtm9AX+VerOI=; b=W+jN0IqsiZE1cB6QH6SX7GHo7srOgRtiwE8RF/GJpjslyy2XxVMxu1300I5pSDqvFw rfQAAeR93MEAfkrkLdq950j7rs4z7kim65jymZRIpgzz0ICup9ROfaZ2iZy7KrUJVB8t nuYus3PImdgW/amClSHlSuCBxnFHPlfEkOujv30UVYmDxHjHeGpu1vb1P7c1LgqzjVGx gctDnfX2WENr94QHFSCBhGp18jvkV45LNC3XoFwPlnxivOef2HiSZtDLeM3TATuINawD tzVtz1bAAgpokzGDlQ7nwuiC9BTLRSbAm7s+71tvLznrSGGEMW3pig+RaXQcjYBUXcZh CiWw== X-Gm-Message-State: AOAM531nHW4Fp+7aiFTfD6HjzaSTXuTPZZnnBaX2cJM1aFr6EPfZT6ux iitFGJxQjezn1a1Z41wgKXP3Lg== X-Google-Smtp-Source: ABdhPJwVaPcDEiz41pAlFWn9D8KimB8ASmvsXb2tO7mxC5CgcBE9Xe8v3Te7LUfFJVSR0T2JLKzvZQ== X-Received: by 2002:a37:9b01:: with SMTP id d1mr17286qke.89.1606327017254; Wed, 25 Nov 2020 09:56:57 -0800 (PST) Received: from [192.168.1.4] ([177.194.48.209]) by smtp.googlemail.com with ESMTPSA id r125sm3235738qke.129.2020.11.25.09.56.55 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 25 Nov 2020 09:56:56 -0800 (PST) Subject: Re: [PATCH 09/13] linux: nptl: Replace lll_futex_{timed_}wait by futex-internal.h To: Mike Crowe Cc: libc-alpha@sourceware.org, Michael Kerrisk References: <20201123195256.3336217-1-adhemerval.zanella@linaro.org> <20201123195256.3336217-9-adhemerval.zanella@linaro.org> <20201125153231.GA1391@mcrowe.com> <20201125154650.GA10858@mcrowe.com> <7faa000d-fd45-41f2-a0db-1dfa6da9ed96@linaro.org> <20201125173748.GA27363@mcrowe.com> 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: <5eced920-6c82-a5f7-3fcd-99ded607b978@linaro.org> Date: Wed, 25 Nov 2020 14:56:53 -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: <20201125173748.GA27363@mcrowe.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-14.0 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, 25 Nov 2020 17:56:59 -0000 On 25/11/2020 14:37, Mike Crowe wrote: > On Wednesday 25 November 2020 at 14:19:37 -0300, Adhemerval Zanella wrote: >> On 25/11/2020 12:46, Mike Crowe wrote: >>> On Wednesday 25 November 2020 at 12:40:46 -0300, Adhemerval Zanella wrote: >>>> >>>> >>>> On 25/11/2020 12:32, Mike Crowe wrote: >>>>> On Monday 23 November 2020 at 16:52:52 -0300, Adhemerval Zanella wrote: >>>>>> The idea is to make NPTL implementation to use on the functions >>>>>> provided by futex-internal.h. >>>>>> >>>>>> Checked on x86_64-linux-gnu and i686-linux-gnu. >>>>>> --- >>>>>> nptl/lowlevellock.c | 6 +++--- >>>>>> nptl/pthread_mutex_lock.c | 9 +++++---- >>>>>> nptl/pthread_mutex_setprioceiling.c | 5 +++-- >>>>>> nptl/pthread_mutex_timedlock.c | 6 +++--- >>>>>> 4 files changed, 14 insertions(+), 12 deletions(-) >>>>> >>>>> [snip] >>>>> >>>>>> diff --git a/nptl/pthread_mutex_timedlock.c b/nptl/pthread_mutex_timedlock.c >>>>>> index e643eab258..343acf6107 100644 >>>>>> --- a/nptl/pthread_mutex_timedlock.c >>>>>> +++ b/nptl/pthread_mutex_timedlock.c >>>>>> @@ -561,9 +561,9 @@ __pthread_mutex_clocklock_common (pthread_mutex_t *mutex, >>>>>> goto failpp; >>>>>> } >>>>>> >>>>>> - lll_futex_timed_wait (&mutex->__data.__lock, >>>>>> - ceilval | 2, &rt, >>>>>> - PTHREAD_MUTEX_PSHARED (mutex)); >>>>>> + __futex_abstimed_wait64 ( >>>>>> + (unsigned int *) &mutex->__data.__lock, clockid, >>>>>> + ceilval | 2, &rt, PTHREAD_MUTEX_PSHARED (mutex)); >>>>> >>>>> I think you've replaced the lll_futex_timed_wait call that expects a >>>>> relative timeout with a __futex_abstimed_wait64 call that expects an >>>>> absolute timeout, yet you still appear to be passing the relative timeout. >>>>> >>>>> However, it turns out that the implementation for the >>>>> PTHREAD_MUTEX_PP_RECURSIVE_NP and friends case appears to be have been >>>>> completely broken with clockid != CLOCK_REALTIME ever since I added it in >>>>> 9d20e22e46d891b929a72b0f35586e079eb083fd anyway since the relative timeout >>>>> is calculated by calling __clock_gettime64(CLOCK_REALTIME) (although at the >>>>> time this was a less obvious __gettimeofday call.) >>>>> >>>>> I'll work on writing some test cases for the those types of mutex in the >>>>> hope of catching both flaws before fixing them. >>>> >>>> Indeed, there is no need to calculate the relative timeout anymore. I think >>>> the fix below should pass the absolute timeout directly. I will check >>>> a possible regression tests as well. >>> >>> OK. I won't then. Thanks. >>> >>>> diff --git a/nptl/pthread_mutex_timedlock.c b/nptl/pthread_mutex_timedlock.c >>>> index aaaafa21ce..86c5f4446e 100644 >>>> --- a/nptl/pthread_mutex_timedlock.c >>>> +++ b/nptl/pthread_mutex_timedlock.c >>>> @@ -508,7 +508,6 @@ __pthread_mutex_clocklock_common (pthread_mutex_t *mutex, >>>> if (__pthread_current_priority () > ceiling) >>>> { >>>> result = EINVAL; >>>> - failpp: >>>> if (oldprio != -1) >>>> __pthread_tpp_change_priority (oldprio, -1); >>>> return result; >>>> @@ -540,37 +539,9 @@ __pthread_mutex_clocklock_common (pthread_mutex_t *mutex, >>>> >>>> if (oldval != ceilval) >>>> { >>>> - /* Reject invalid timeouts. */ >>>> - if (! valid_nanoseconds (abstime->tv_nsec)) >>>> - { >>>> - result = EINVAL; >>>> - goto failpp; >>>> - } >>> >>> If this is removed then is there a risk of getting into a busy loop if >>> someone passes a bogus timespec? (Regardless of the answer, it makes sense >>> to ensure that is tested somehow.) >> >> The minimum supported kernel already does the same check on the futex call >> (source for Linux 3.2): >> >> 2690 SYSCALL_DEFINE6(futex, u32 __user *, uaddr, int, op, u32, val, >> 2691 struct timespec __user *, utime, u32 __user *, uaddr2, >> 2692 u32, val3) >> 2693 { >> 2694 struct timespec ts; >> 2695 ktime_t t, *tp = NULL; >> 2696 u32 val2 = 0; >> 2697 int cmd = op & FUTEX_CMD_MASK; >> 2698 >> 2699 if (utime && (cmd == FUTEX_WAIT || cmd == FUTEX_LOCK_PI || >> 2700 cmd == FUTEX_WAIT_BITSET || >> 2701 cmd == FUTEX_WAIT_REQUEUE_PI)) { >> 2702 if (copy_from_user(&ts, utime, sizeof(ts)) != 0) >> 2703 return -EFAULT; >> 2704 if (!timespec_valid(&ts)) >> 2705 return -EINVAL; >> 2706 >> 2707 t = timespec_to_ktime(ts); >> 2708 if (cmd == FUTEX_WAIT) >> 2709 t = ktime_add_safe(ktime_get(), t); >> 2710 tp = &t; >> 2711 } >> >> 113 #define timespec_valid(ts) \ >> 114 (((ts)->tv_sec >= 0) && (((unsigned long) (ts)->tv_nsec) < NSEC_PER_SEC)) >> >> So it will return EINVAL for bogus timespec. > > Yes, but here: > >> __futex_abstimed_wait64 ( >> (unsigned int *) &mutex->__data.__lock, clockid, >> - ceilval | 2, &rt, PTHREAD_MUTEX_PSHARED (mutex)); >> + ceilval | 2, abstime, PTHREAD_MUTEX_PSHARED (mutex)); > > the return value of __futex_abstimed_wait64 is not checked, so the loop > might just spin around busily until the timeout expires. Perhaps the return > value needs checking too? Indeed, we need to check for ETIMEDOUT/EOVERFLOW.