Received: by 2002:a05:6a10:8395:0:0:0:0 with SMTP id n21csp591130pxh; Tue, 9 Nov 2021 15:48:52 -0800 (PST) X-Google-Smtp-Source: ABdhPJw+YvIAdfXAu76kM0yl4yJpTYtIUx/xSMbGZBfspA85tzu0esecBlbmMDgPYENsLAbej0IY X-Received: by 2002:a05:6638:32a2:: with SMTP id f34mr8706986jav.63.1636501732808; Tue, 09 Nov 2021 15:48:52 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1636501732; cv=none; d=google.com; s=arc-20160816; b=W3qQO9MQI+I6CI4UhUapIOafoB6H+FSvvpIM+NqAi6lAhoQOg3TABnsKdp6OpLbEhQ IWQ7QGI76r1yxpmDE49jHcgsJPRswQJ3+fQnpGwsbUl8T54S6hkeeQxgNO7erR2JCSRS 69pzJiXzbNU84z5LV2gDwGrPM+5tIew36lGRdF/6g934pu9/MSn3o4OR1cLT9Dz32ZPF PuTTlmADBoAsBaxv0eB3CXWz9FN2APf3GWZKZozM8EAxvgzKIFMYij3hcSGFjNt6RwpS QPlc6CLxW1X7ZdWS7vyD0GB6w81jvwCga6hfQCtmXDZgneU+SEBo6lhf5bo6oXAVspwb cIrg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:in-reply-to:from :references:cc:to:content-language:subject:user-agent:mime-version :date:message-id:dkim-signature; bh=AVhXRNXWoG4nz7o/lke7pJRtR8Em/wWLZScBAGeMu9g=; b=VXOc+5Tq01zESiVlBcWIbJk9NLZdhqxERRTt9zaqAX3aFcPzsNXqRzhoBtvHd+BNTH weKb7wKzHKC1wH4eyRfN5YRn/f2plXerjatYW/3wP/Lv4wmEUTRxmAjw17Jir1R2xqJv ZqapOo+EigTKbhCR2VF5ih2xzWSbbfN2isFpAZN4jtEtrf6lWX3GnjWwfb6xL8Cd7o0F rikIEHssQl6+UuEAP1vcNPS4Q4QYoVaZ/dATKiau5gQsPctt3RQgbLEL8uAlv854ly0f 3HI+c4XxoSdyi7Yxcdav0yVkR9gTFtz/g3ZsUthYFu1GjeHdmlzAoxuToWbXehciycv+ gexA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linaro.org header.s=google header.b=DHB7jYMF; 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; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linaro.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id o20si24420249iow.107.2021.11.09.15.48.40; Tue, 09 Nov 2021 15:48:52 -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; dkim=pass header.i=@linaro.org header.s=google header.b=DHB7jYMF; 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; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linaro.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230114AbhKINDw (ORCPT + 97 others); Tue, 9 Nov 2021 08:03:52 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:37048 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229990AbhKINDv (ORCPT ); Tue, 9 Nov 2021 08:03:51 -0500 Received: from mail-ot1-x32f.google.com (mail-ot1-x32f.google.com [IPv6:2607:f8b0:4864:20::32f]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 22C06C061764 for ; Tue, 9 Nov 2021 05:01:05 -0800 (PST) Received: by mail-ot1-x32f.google.com with SMTP id b5-20020a9d60c5000000b0055c6349ff22so19954620otk.13 for ; Tue, 09 Nov 2021 05:01:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=message-id:date:mime-version:user-agent:subject:content-language:to :cc:references:from:in-reply-to:content-transfer-encoding; bh=AVhXRNXWoG4nz7o/lke7pJRtR8Em/wWLZScBAGeMu9g=; b=DHB7jYMFAcf8uxuqEmaiXy/5GRLxtMMekfIqso1iCTmp49IW45L24FBjFGGyKSePCZ qY6TQM+giMtQYL0ICAQKCYzLN4kuPSiXtj1WSea1exnmC90E++Md7V0pTVfE0DSR30Fe 8fKImM9RXY0OtuOzlSR/p3uS1EPkkQbduaj1mm5X49vUJZ6X/ONFsD2PAjwtTSt6FdwD RhoXS+mKWoSldUI1y+1oGRVnSuEyMBjfuI0vEy5jXkMyF9H6n9Ckm4GIq2DHgmXdalCU kElObxXXD2ZibSav2qWgG2MVwoQ1v0ddtNFrhBJSrSua+HFjdIX98ozfHy96fMopSvCT 1i4Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:message-id:date:mime-version:user-agent:subject :content-language:to:cc:references:from:in-reply-to :content-transfer-encoding; bh=AVhXRNXWoG4nz7o/lke7pJRtR8Em/wWLZScBAGeMu9g=; b=6f6v45Nm5vcP8sCqIGPkfnPC0oCQO+QHZ6wkI7I++EvMKIswj8TRBxZgfG2gdEymbR mC6wocWCI+8lOkhHBEJ1Y7QjoLTUVtB0jg77Np+HJa0ZYu+dds02jM3+aq5tSkRptZOE 0N5lCdVG7LzQlmDQpdTmTABMDzbEEnAgr3IXbQpYLqe3L0QYUB4NkpeLb8tACS7MfvBz 1EAL+iPyQSjft3QssnzSCeOxkcRRCzmBFlpZKpxybkPAFXKPeBU+W4hlpzCKOfs38TSh LBB3RnzdFIuINU7+zfC2Yy77XpPrFEO7qhdK9o5n6gXfq3bRTSfnXmq96DgZ0i3JIWLZ KZ/g== X-Gm-Message-State: AOAM532xUqhEEEr+uBrHlAn/sTE4dNEj0reYcz4yF6AgznseN1SdZhz7 whshPK3/c1VRuedYVHR5ZJ+ryw== X-Received: by 2002:a9d:f4a:: with SMTP id 68mr215156ott.327.1636462864405; Tue, 09 Nov 2021 05:01:04 -0800 (PST) Received: from ?IPV6:2804:431:c7cb:55a:94d0:2630:9b29:e621? ([2804:431:c7cb:55a:94d0:2630:9b29:e621]) by smtp.gmail.com with ESMTPSA id k4sm7088764oic.48.2021.11.09.05.01.00 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 09 Nov 2021 05:01:04 -0800 (PST) Message-ID: Date: Tue, 9 Nov 2021 10:00:59 -0300 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.2.1 Subject: Re: [PATCH v2 20/22] selftests: futex: Test sys_futex_waitv() timeout Content-Language: en-US To: =?UTF-8?Q?Andr=c3=a9_Almeida?= , Vasily Gorbik Cc: Davidlohr Bueso , libc-alpha@sourceware.org, Peter Zijlstra , linux-api@vger.kernel.org, Sebastian Andrzej Siewior , linux-kernel@vger.kernel.org, Steven Rostedt , Ingo Molnar , mtk.manpages@gmail.com, Darren Hart , Thomas Gleixner , kernel@collabora.com, krisman@collabora.com References: <20210923171111.300673-1-andrealmeid@collabora.com> <20210923171111.300673-21-andrealmeid@collabora.com> <51bbfe74-33f6-bb92-3ce8-a22e4185820b@collabora.com> From: Adhemerval Zanella In-Reply-To: <51bbfe74-33f6-bb92-3ce8-a22e4185820b@collabora.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 09/11/2021 09:52, André Almeida via Libc-alpha wrote: > Hi Vasily, > > À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. We do since glibc 2.34, but you need to opt-in by defining -D_TIME_SIZE=64. The default might change in a future release, so hopefully we will have both LFS and 64-bit as the default ABI. > > In previous submissions I added a workaround for that in the > selftest[0]. Search for "Y2038 section for 32-bit applications" in that > link. I'll submit something like that for futex_waitv() timeout test. > > [0] > https://lore.kernel.org/lkml/20210709001328.329716-6-andrealmeid@collabora.com/ >