From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-12.3 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, MENTIONS_GIT_HOSTING,NICE_REPLY_A,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED, USER_AGENT_SANE_1 autolearn=unavailable autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id D071DC4743D for ; Tue, 8 Jun 2021 18:10:10 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id BA1C1613AE for ; Tue, 8 Jun 2021 18:10:10 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231935AbhFHSMC (ORCPT ); Tue, 8 Jun 2021 14:12:02 -0400 Received: from mail-qv1-f41.google.com ([209.85.219.41]:41975 "EHLO mail-qv1-f41.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232753AbhFHSMC (ORCPT ); Tue, 8 Jun 2021 14:12:02 -0400 Received: by mail-qv1-f41.google.com with SMTP id x2so10645753qvo.8 for ; Tue, 08 Jun 2021 11:09:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=SzY5mAzb8iAAncNXCHh5zNAEVzbO39nRlIsEjy7/kj4=; b=yP1M9TwVufAhZhzjKMz4aXj5vc2/bthnQJnbC+4WdSfV+iBjkqH4wKJpiecqQ/eP8g hBDLDWr0z6h+d218Lmsm1mjnb8XAh/r5jZhaHZYTv447YW5yFi8n0fl/p8XWGpr4U6tb ym/nrKyOaJQcyxf1gk8nwJBCsTm8hr4GauoWtyKAVkx/pJGSe1P1h966OMxnD+OJp1V0 7nG9F97aKotXZ+nrrp4yfZ6Trq/o0rJwmlZs+WtiRFHjDu3kxnLxw9A3XxG3/IKQc/xO 1ctEGT0Yjl99/hnPpVyeM3+yfa9oQMUgpW3Cb8elFblEIYuU7fw6dO9OQwr5dhYA+M3R Hz8g== 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:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=SzY5mAzb8iAAncNXCHh5zNAEVzbO39nRlIsEjy7/kj4=; b=eOxuFxatZiOtjX94KKO15vEkLU7GJqLIC4snH6e/QNKJ70HC42rmGAxrNcqiLuuEJ5 9AU+xqS8lE2j7NNvsI7h63ZVvBaoPAwiGC8g12Rj17jsmBi351FaLesvpq+n6kp3b28B lI5lzbWbm6hd4guMeCyQ2bRwwGvQUa5VNOh7tCEyl9JFKF6L78pRtFfhNq5XvF6rAR7n ESPUO6RITcl8mb8dwodUsHNxGvAuV+9lmI58KvMZmx5o9MRP9nqqv0VLhkTB44c46KZq tzd1OhP8TKldPDW9vUAK51LT19uuqhxzo4quxVfeoLj3UbCoRkLL0IBrdeEAq0q3IAZb hBBw== X-Gm-Message-State: AOAM530fyLj3ZXnwBJsbrQ3fX5kPET9IWkmRsbPYX1oFkZ5SVmISv/XQ 7ClSlE0t4uQKUizZNY1dlNnFyw== X-Google-Smtp-Source: ABdhPJzq29VJTnN5Q6aeV8Pg0HAuE5CchMgl31X1oKLF8UNjqTft6fNXk8EmKW6Qk8X9KRpEuN1lFQ== X-Received: by 2002:a05:6214:d41:: with SMTP id 1mr1468950qvr.6.1623175732347; Tue, 08 Jun 2021 11:08:52 -0700 (PDT) Received: from [192.168.1.4] ([177.194.59.218]) by smtp.gmail.com with ESMTPSA id h12sm11987725qkj.52.2021.06.08.11.08.46 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 08 Jun 2021 11:08:52 -0700 (PDT) Subject: Re: [PATCH v4 00/15] Add futex2 syscalls To: Peter Zijlstra , Sebastian Andrzej Siewior Cc: linux-kselftest@vger.kernel.org, joel@joelfernandes.org, Andrey Semashev , kernel@collabora.com, shuah@kernel.org, Davidlohr Bueso , Peter Oskolkov , corbet@lwn.net, krisman@collabora.com, malteskarupke@fastmail.fm, Ingo Molnar , Darren Hart , acme@kernel.org, Steven Rostedt , =?UTF-8?Q?Andr=c3=a9_Almeida?= , Thomas Gleixner , fweimer@redhat.com, libc-alpha@sourceware.org, linux-api@vger.kernel.org, z.figura12@gmail.com, Nicholas Piggin , linux-kernel@vger.kernel.org, pgriffais@valvesoftware.com References: <20210603195924.361327-1-andrealmeid@collabora.com> <1622799088.hsuspipe84.astroid@bobo.none> <1622853816.mokf23xgnt.astroid@bobo.none> <22137ccd-c5e6-9fcc-a176-789558e9ab1e@collabora.com> <20210608122622.oxf662ruaawrtyrd@linutronix.de> From: Adhemerval Zanella Message-ID: <74c7f1c1-ca15-1e86-a988-a4d349ad16ef@linaro.org> Date: Tue, 8 Jun 2021 15:08:44 -0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.8.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Precedence: bulk List-ID: X-Mailing-List: linux-api@vger.kernel.org > All the attempts with API extensions didn't go well because glibc did > not want to change a bit. This starts with a mutex that has a static > initializer which has to work (I don't remember why the first > pthread_mutex_lock() could not fail with -ENOMEM but there was > something) and ends with glibc's struct mutex which is full and has no > room for additional data storage. Yes, we have binary compatibility constraints that prevents us to simply broken old binaries. This is quite true for static initialization, which imposes even harder constraints, different than the pthread_mutex_t size where we can workaround with symbols versioning. But even then we hear from users that out pthread_mutex_t is still way larger, specially for fine grained locking so I am not sure if we do want to extend it. > That said; if we're going to do the whole futex-vector thing, we really > do need a new interface, because the futex multiplex monster is about to > crumble (see the fun wrt timeouts for example). > > And if we're going to do a new interface, we ought to make one that can > solve all these problems. Now, ideally glibc will bring forth some > opinions, but if they don't want to play, we'll go back to the good old > days of non-standard locking libraries.. we're halfway there already due > to glibc not wanting to break with POSIX were we know POSIX was just > dead wrong broken. > > See: https://github.com/dvhart/librtpi You are right, we don't really want to break POSIX requirements in this regard because users constantly come with scenarios where they do expect our implementation to be conformant [1]. And even now, there are case we don't get it fully right [2] and it is really hard to fix such issues. If I recall correctly from a recent plumber couple of years ago about the librtpi, the presents stated their implement do not follow POSIX standard by design. It suits then for their required work, but it is not what we really aim for glibc. We *might* try to provide as an extension, but even then I am not if it would be fully possible due API constraints. So, regarding the futex2 we might try to support it eventually; but if this newer interface is not a really a superset of futex1 we won't put much effort. Supporting newer syscall requires an extra effort from glibc, we need to keep fallback for older ones in case the kernel is too old and it also imposes runtime costs. Also currently we don't have a specific usage. The proposed patch to add the 'pthread_mutex_lock_any' and 'pthreada_timedlock_any' [3] also did not gave much detail in realword usages or how it can be leveraged. [1] https://sourceware.org/bugzilla/show_bug.cgi?id=13165 [2] https://sourceware.org/bugzilla/show_bug.cgi?id=25847 [3] https://sourceware.org/pipermail/libc-alpha/2019-July/105422.html