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=-10.8 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_CR_TRAILER, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED autolearn=ham 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 B7F7CC4338F for ; Thu, 29 Jul 2021 08:18:32 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 9A7A760EBB for ; Thu, 29 Jul 2021 08:18:32 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S234795AbhG2ISe (ORCPT ); Thu, 29 Jul 2021 04:18:34 -0400 Received: from Galois.linutronix.de ([193.142.43.55]:42628 "EHLO galois.linutronix.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S234673AbhG2ISe (ORCPT ); Thu, 29 Jul 2021 04:18:34 -0400 From: Thomas Gleixner DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linutronix.de; s=2020; t=1627546710; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=rLbTCSoY6hKgbo05q/HPzOu0Zybc2k9R8hiuYXVYw/w=; b=tNIkIPekNl5xoAuuPdUlNBMAi7QOFdkmaq9TAWkYiyflzEhlFJyUEZKq+f/bF8sRK0DKV7 sf/BUteqSuJFrNSnK5BXB/YeQtF2GqH/WoV+jbjqYVXwISv5SwaaKfqyRk5EM8rnmmTDeI wwiLS4MscfNprUk9BPpywdLmmeh6flEjlXZnCzyhX8EciqsaKoISLHIqtzxCMQ1QFcQLkH hQJ1KWlbVvBKLSiT3/FWp7/UrAUuFryXeRqJvd5VHNV1BY3JAp+L7Es3GxkAkCd/uzEXsF +h+Th2q6JXqIEuzxly3W0mzmEZLj8FRXtHW7nNEMfUJalLA2LqeAunI+on9a0A== DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=linutronix.de; s=2020e; t=1627546710; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=rLbTCSoY6hKgbo05q/HPzOu0Zybc2k9R8hiuYXVYw/w=; b=e7+yNNeRy+DgLCwtRHMVBZ+T5CyX7NYAl4TSQbJZ1Ozqc5MIds/Vn2IGkNdJwUDT+7ExGw a/+/qLTSUUznngCQ== To: Kurt Kanzenbach , Michael Kerrisk , Alejandro Colomar Cc: linux-man@vger.kernel.org, Peter Zijlstra , Sebastian Andrzej Siewior , Kurt Kanzenbach Subject: Re: [PATCH v1] futex.2: Document FUTEX_LOCK_PI2 In-Reply-To: <20210625101051.1206558-1-kurt@linutronix.de> References: <20210625101051.1206558-1-kurt@linutronix.de> Date: Thu, 29 Jul 2021 10:18:29 +0200 Message-ID: <8735rxjzxm.ffs@tglx> MIME-Version: 1.0 Content-Type: text/plain Precedence: bulk List-ID: X-Mailing-List: linux-man@vger.kernel.org On Fri, Jun 25 2021 at 12:10, Kurt Kanzenbach wrote: > FUTEX_LOCK_PI2 is a new futex operation which was recently introduced into the > Linux kernel. It works exactly like FUTEX_LOCK_PI. However, it has support for > selectable clocks for timeouts. By default CLOCK_MONOTONIC is used. If > FUTEX_CLOCK_REALTIME is specified then the timeout is measured against > CLOCK_REALTIME. > > This new operation addresses an inconsistency in the futex interface: > FUTEX_LOCK_PI only works with timeouts based on CLOCK_REALTIME in contrast to > all the other PI operations. > > Document the FUTEX_LOCK_PI2 command. > > Signed-off-by: Kurt Kanzenbach Reviewed-by: Thomas Gleixner