Received: by 2002:a05:6a10:8395:0:0:0:0 with SMTP id n21csp591404pxh; Tue, 9 Nov 2021 15:49:12 -0800 (PST) X-Google-Smtp-Source: ABdhPJwkuTVdtlV1SRLxJOu0yY4hOOm4v7/8v4PI1O2zru7BVWIyaJxxtVkIIsUHM8wQ70s4Ji5Y X-Received: by 2002:a05:6e02:160e:: with SMTP id t14mr8492589ilu.15.1636501752585; Tue, 09 Nov 2021 15:49:12 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1636501752; cv=none; d=google.com; s=arc-20160816; b=B1kovKysrEeszIhhLKUZnN1Gi3k5DBqfmVEEUNZrOon5HY+YS1f8w0+RZcVrUgSqrY UwAjr2dMKcLGZZBPrwWc7YpUtyrac2jVJWA9cu9VvdXeAlmeOQEAdS5mQnnzklQCsAUA EmpWE3UGsYDb2xGm7gTkKLjmuhzZLcZrhv1v1g2jYEb76J8YmdztHqs4RrKnsQ88vs5W Z96eIrt760Y+sAvMlAKTdFgG1YIIgjfsmcDSVlAGeC08t8p0T/nXS5EHsEgDvsS8rVDZ 1pTYelkuh6DIlV0RW19V8LhuZHU0IKYRHgulW5+5Kr6fmedzZ56H86y6TOj2RS2HxVr8 ojog== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:cc:to:subject :message-id:date:from:in-reply-to:references:mime-version; bh=E8TYRciXVxCz8vZOP2bMC+SYD30cNVf2ngNfJhXKkIQ=; b=O2jFUsGw+mB+dvfWz6UHa38L0qn84AC8VzmeENvM6fFYhj7m2hq+CcBO0a4e6yab1I iLz5FRmtJiiStGJDUSfDLkHzCJNtOj2RKv0qHbxTMlvckDOQr5yei0+HgPspHwIP9VWx JRJTrgCc7gRxwrNlW84sj8x4y+NT/smvVB9jjlj+WUTXjL3XWnsFLk1/Ev6iDutgl5S0 LOD9jwhvCTeuOyoQZps9spH8mLXHoDICzoVDdl5P41ECTPSq4oB44iYndDl5Y+Rclvld FXOIGiw++GoVIOJKVacWtHpWZSPebUx54vVEKXaZ3gCw7fI5N7wNW9ZfRG5UzUP0pXnO OdFw== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id h25si28418236iob.58.2021.11.09.15.49.00; Tue, 09 Nov 2021 15:49:12 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S240363AbhKINIZ convert rfc822-to-8bit (ORCPT + 97 others); Tue, 9 Nov 2021 08:08:25 -0500 Received: from mout.kundenserver.de ([212.227.126.135]:42413 "EHLO mout.kundenserver.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S240104AbhKINIQ (ORCPT ); Tue, 9 Nov 2021 08:08:16 -0500 Received: from mail-wr1-f53.google.com ([209.85.221.53]) by mrelayeu.kundenserver.de (mreue012 [213.165.67.97]) with ESMTPSA (Nemesis) id 1MYcy3-1nEpjv0UKZ-00VgZ9; Tue, 09 Nov 2021 14:05:28 +0100 Received: by mail-wr1-f53.google.com with SMTP id s13so32913754wrb.3; Tue, 09 Nov 2021 05:05:27 -0800 (PST) X-Gm-Message-State: AOAM531obU9zQxZLci0HZGouM7eA/pZPEgynIlxejLNVY4k9ZiZC3ZyY B+XkAhvccXZzszj0gQGHtZNUEBxE73dF2XLXxJw= X-Received: by 2002:adf:df89:: with SMTP id z9mr8974988wrl.336.1636463127622; Tue, 09 Nov 2021 05:05:27 -0800 (PST) MIME-Version: 1.0 References: <20210923171111.300673-1-andrealmeid@collabora.com> <20210923171111.300673-21-andrealmeid@collabora.com> <51bbfe74-33f6-bb92-3ce8-a22e4185820b@collabora.com> In-Reply-To: <51bbfe74-33f6-bb92-3ce8-a22e4185820b@collabora.com> From: Arnd Bergmann Date: Tue, 9 Nov 2021 14:05:11 +0100 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH v2 20/22] selftests: futex: Test sys_futex_waitv() timeout To: =?UTF-8?Q?Andr=C3=A9_Almeida?= Cc: Vasily Gorbik , Thomas Gleixner , Ingo Molnar , Peter Zijlstra , Darren Hart , Linux Kernel Mailing List , Steven Rostedt , Sebastian Andrzej Siewior , Collabora kernel ML , Gabriel Krisman Bertazi , Linux API , GNU C Library , Michael Kerrisk , Davidlohr Bueso , Arnd Bergmann , Alistair Francis Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8BIT X-Provags-ID: V03:K1:j1y24ZLQaCxUnwIlX4UkGzpcQwqR0k9vJ7BzTd4TvS4BhotMlOC dLh9ehv+pKrnceNqMg4UWmtbtGXGXBMlUoXMErYIKABldKOPM08rnx4R7jZufLwY1NaodP3 d1rsCDC0rjd5JmgydQKTeIjOaqPgtcqpqGudAdmwtdfeI03ZZ8ixBoY+eJQWoQa4X3Xds1G kEC9WKv/46/Ow+Xv0fVog== X-Spam-Flag: NO X-UI-Out-Filterresults: notjunk:1;V03:K0:eFU4pS+yBGA=:0DD8DEJVG7L4LNan7gz6Od ZeJFhjshpJTNml5IVCZj1pXCUd2FCWg0i2N7+OszY5zX8aaOfFLLOfgw4PKfD0s84VXtFTWMQ DR8p2yuD+tTVIxGy4YMslHVXE78O81JeuqePSSlYCztLAQLdFmFApRSwJq1yN7AMjqcl8sP7D SG0OwWyqtUtTp1Vz5+BWgGIXsJwsZhKAH8kxh4KGY3plFo0iQb5YmuqM+hzJpqWGu3gsR/io/ g+nsdwbWrZ8dH0D8pLa0hCwJpWdd31H9PmGEqxXt1bxL6kvaa9uWkA8zVzZyYGWNouxAgHG8b MtU8N4khoWL/glgUGJpqdOQaBHy5C/Y/XSayLKtsq/lU8nz6y/ZUYxa6MdKPiInBUJ+99j+sA U/3fZXBpIo4+UGUFy5fL9H6PNwyaTaArUn0Q9X+zGjuz6TdU52mDyGmmxiUB6XjWW0lP3SzJe fovHV/j0ZXR6XBFGOIeioTgNqXcRfR/SRbB/Ko7WU92N8rRwn642876pgwnRIpGveOAW5JOb4 j8yp0v5spJHyd/OGiTM4IaKsatXjTwESOA9tr/y4ukzUQaaxZkdsfFhDXw/jbmu8YIZe8MjJl XXnGdXYv8D1gUWG5NrwJ1qibQnC+cFkKBCLbeVooG94/++1Ktea5sv+RQOPXjm43K8F84qGf4 zxBJmcG1K0AHBHRKZRuCJeEBorcFifDFVxjJHC99fFnHB7nM5uSoWHGqpc/ffRPWqlXRGUeEH HSkSsJSmgNXGhPmXi8BQ3WhKqcPx06bEIcj4u3oTGgPFbaXhR6uupZCEKVHfatIsw0cqx6wjt 7NGBvT5LOxtG1vm72lV4p5c4SA21EtQHveIg/lAwPWkj/OkCYM= Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Nov 9, 2021 at 1:52 PM André Almeida wrote: > Às 08:18 de 09/11/21, Vasily Gorbik escreveu: > > On Thu, Sep 23, 2021 at 02:11:09PM -0300, André Almeida wrote: > >> Test if the futex_waitv timeout is working as expected, using the > >> supported clockid options. > > > >> + /* futex_waitv with CLOCK_MONOTONIC */ > >> + if (futex_get_abs_timeout(CLOCK_MONOTONIC, &to, timeout_ns)) > >> + return RET_FAIL; > >> + res = futex_waitv(&waitv, 1, 0, &to, CLOCK_MONOTONIC); > >> + test_timeout(res, &ret, "futex_waitv monotonic", ETIMEDOUT); > >> + > >> + /* futex_waitv with CLOCK_REALTIME */ > >> + if (futex_get_abs_timeout(CLOCK_REALTIME, &to, timeout_ns)) > >> + return RET_FAIL; > >> + res = futex_waitv(&waitv, 1, 0, &to, CLOCK_REALTIME); > >> + test_timeout(res, &ret, "futex_waitv realtime", ETIMEDOUT); > > > > Hi André, > > > > when built with -m32 and run as compat this two futex_waitv calls hang > > on x86 and s390 (noticed while wiring up futex_waitv). The rest of the > > futex selftests pass. This suggests some common compat issue? Any ideas? > > The issue is that futex_waitv() only accepts struct timespec that uses > 64bit members. When using -m32, glibc will give you a 32bit timespec, > thus the timeout won't wort. Someday glibc will provide 64bit timespec > to 32bit userspace, given that this is affected by y2038 bug. I think in the latest glibc you should be able to pass -D_TIME_BITS=64 to the compiler to get the correct definition. Unfortunately, this only works for simple test cases, but breaks if you call any interfaces from another (non-glibc) library that depend on a particular time_t definition. Alistair Francis also recently posted a set of helpers for the old futex() call to make that easier to use from applications regardless of the libc interface. I think it would be good to have this for futex_waitv() as well. Arnd