From patchwork Mon Jun 5 15:08:29 2023 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: tip-bot2 for Thomas Gleixner X-Patchwork-Id: 103345 Return-Path: Delivered-To: ouuuleilei@gmail.com Received: by 2002:a59:994d:0:b0:3d9:f83d:47d9 with SMTP id k13csp2763191vqr; Mon, 5 Jun 2023 08:24:02 -0700 (PDT) X-Google-Smtp-Source: ACHHUZ4MBoew75n0n+vm2M9GapwFulNo1+qWkYUWkv8766PceYKzXzuez1EoEnLR9LdwAEdgS8X5 X-Received: by 2002:a05:6a00:a24:b0:645:8a69:faad with SMTP id p36-20020a056a000a2400b006458a69faadmr14939339pfh.14.1685978642724; Mon, 05 Jun 2023 08:24:02 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1685978642; cv=none; d=google.com; s=arc-20160816; b=mgCf2xUIoAhzq4wOmsroo6gHDX04rPP3u2a1bVdtOFutPo+IABeZ0pT3mAcfin44h0 QQ6ohGu8dBw0i9cejFsVFcyfejyQV2/nAcsWmV7i8fA+PpB1HXkQCafPD3SqI9xLoWHE EOunXnJE0r4Djok4mQbYM0USHIhJTM+jeUriuslWKJpmKM6QLgrrFc+4wyyl4S+LxFj4 1uIRFUMmWZOaHT8+SMA5H26Wm3cnwxSDRsqjMFu8FP87MIGg1k0zkl1J07taX2IufQeO st7QjEhnZUA5lmYvgTyYzGFGiv2pnbGfR0BnQSUgB98pKV2i8eoOjSRExU/BxDlxC/jQ CKJQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:robot-unsubscribe :robot-id:message-id:mime-version:references:in-reply-to:cc:subject :to:reply-to:sender:from:dkim-signature:dkim-signature:date; bh=s6w8b+H38nB35U6zyxY6nQhPl5ZOw2Hhn62YucR+QBU=; b=pS6hmVI8Ok0HXvoFvA4nkoUm6Rs7/m1gcyYfBsfQDSsOSfKaHxNUSSRhLILrF5jDii DrMRhmyI8/pI7gHrcOtPPavU64SePKvwZnAIlkvGOHlsu4tokzrokosW3uWLCPy6Aj1d xQZVnerPaXXl8OVpEqFdZ+8MlIpncNoyqPqnv+wHaUn19UEzYdm267H4ttKvfuQM1wLv QrSFp2chwirqmv8s45EXbqBD/CxPI3VQ/AIy0t3CEj/Pi/W8Pihza0JWsL7DdHwnMjov AX3G4rFITO0gshv+W8vEj+Uxg6qrS0FhGxd6MHoumcKIMgLQWHLLRnLiPv9UJ1ElILn2 lysw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linutronix.de header.s=2020 header.b=IqO7TKvN; dkim=neutral (no key) header.i=@linutronix.de header.s=2020e header.b=jsWaV6pL; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=linutronix.de Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id p18-20020a639512000000b005349286fcc0si5614117pgd.302.2023.06.05.08.23.50; Mon, 05 Jun 2023 08:24:02 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@linutronix.de header.s=2020 header.b=IqO7TKvN; dkim=neutral (no key) header.i=@linutronix.de header.s=2020e header.b=jsWaV6pL; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=linutronix.de Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S234088AbjFEPJV (ORCPT + 99 others); Mon, 5 Jun 2023 11:09:21 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:47966 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S234130AbjFEPIc (ORCPT ); Mon, 5 Jun 2023 11:08:32 -0400 Received: from galois.linutronix.de (Galois.linutronix.de [193.142.43.55]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 0757CF1; Mon, 5 Jun 2023 08:08:31 -0700 (PDT) Date: Mon, 05 Jun 2023 15:08:29 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linutronix.de; s=2020; t=1685977709; h=from:from:sender:sender:reply-to:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=s6w8b+H38nB35U6zyxY6nQhPl5ZOw2Hhn62YucR+QBU=; b=IqO7TKvNrN2T+F4MZu7H4XdvBACYaD6PyTYYcClr2MxkPFDHqhmbSfLkjkKMe3t3T3bRSE DLbG0ID8a4v3YCzbApSUg7upRnHMwx1HdxiaAIDOiU1aux/Gc6MwLGFnD1IrO7Lpn/q8m3 rX6Gjg52bt3MN69cpeXLJhw/PIoJdLnRRrtxasqZDWBJlwolrT2N/1uOp5SxJxd2y5dlee 0vOZIK+BNIfQ8jtg/TpGqiRGtnX/L3Q8xOI6+3iJBvGl4ZPGLv9BQBT6Qn8Pn8cvCWGkzh kPi7ZP/RSjuIXFcpt+YMS4I2KEBcBUlxfe+ZIEC2zfaqcj/7169XE620jNbTXw== DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=linutronix.de; s=2020e; t=1685977709; h=from:from:sender:sender:reply-to:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=s6w8b+H38nB35U6zyxY6nQhPl5ZOw2Hhn62YucR+QBU=; b=jsWaV6pLG6gMZNE1SeZm3/H3piue8qdy+iUqI8FdoLCBkdPoao00sdGq302lcr2TTXjssG sTrCKZOBEppxPFCw== From: "tip-bot2 for Thomas Gleixner" Sender: tip-bot2@linutronix.de Reply-to: linux-kernel@vger.kernel.org To: linux-tip-commits@vger.kernel.org Subject: [tip: timers/core] posix-timers: Document sys_clock_getres() correctly Cc: Thomas Gleixner , Frederic Weisbecker , x86@kernel.org, linux-kernel@vger.kernel.org In-Reply-To: <20230425183313.356427330@linutronix.de> References: <20230425183313.356427330@linutronix.de> MIME-Version: 1.0 Message-ID: <168597770919.404.14552512930116138988.tip-bot2@tip-bot2> Robot-ID: Robot-Unsubscribe: Contact to get blacklisted from these emails X-Spam-Status: No, score=-4.4 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_MED,SPF_HELO_NONE, SPF_PASS,T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org X-getmail-retrieved-from-mailbox: =?utf-8?q?INBOX?= X-GMAIL-THRID: =?utf-8?q?1764175977528435525?= X-GMAIL-MSGID: =?utf-8?q?1767876741241991006?= The following commit has been merged into the timers/core branch of tip: Commit-ID: 4898e5d912108c8a865ffb3fc0230559b40ca361 Gitweb: https://git.kernel.org/tip/4898e5d912108c8a865ffb3fc0230559b40ca361 Author: Thomas Gleixner AuthorDate: Tue, 25 Apr 2023 20:49:11 +02:00 Committer: Thomas Gleixner CommitterDate: Mon, 05 Jun 2023 17:03:37 +02:00 posix-timers: Document sys_clock_getres() correctly The decades old comment about Posix clock resolution is confusing at best. Remove it and add a proper explanation to sys_clock_getres(). Signed-off-by: Thomas Gleixner Reviewed-by: Frederic Weisbecker Link: https://lore.kernel.org/r/20230425183313.356427330@linutronix.de --- kernel/time/posix-timers.c | 81 +++++++++++++++++++++++++++++++++---- 1 file changed, 73 insertions(+), 8 deletions(-) diff --git a/kernel/time/posix-timers.c b/kernel/time/posix-timers.c index 8153374..c9896ff 100644 --- a/kernel/time/posix-timers.c +++ b/kernel/time/posix-timers.c @@ -67,14 +67,6 @@ static const struct k_clock clock_realtime, clock_monotonic; * to implement others. This structure defines the various * clocks. * - * RESOLUTION: Clock resolution is used to round up timer and interval - * times, NOT to report clock times, which are reported with as - * much resolution as the system can muster. In some cases this - * resolution may depend on the underlying clock hardware and - * may not be quantifiable until run time, and only then is the - * necessary code is written. The standard says we should say - * something about this issue in the documentation... - * * FUNCTIONS: The CLOCKs structure defines possible functions to * handle various clock functions. * @@ -1198,6 +1190,79 @@ SYSCALL_DEFINE2(clock_adjtime, const clockid_t, which_clock, return err; } +/** + * sys_clock_getres - Get the resolution of a clock + * @which_clock: The clock to get the resolution for + * @tp: Pointer to a a user space timespec64 for storage + * + * POSIX defines: + * + * "The clock_getres() function shall return the resolution of any + * clock. Clock resolutions are implementation-defined and cannot be set by + * a process. If the argument res is not NULL, the resolution of the + * specified clock shall be stored in the location pointed to by res. If + * res is NULL, the clock resolution is not returned. If the time argument + * of clock_settime() is not a multiple of res, then the value is truncated + * to a multiple of res." + * + * Due to the various hardware constraints the real resolution can vary + * wildly and even change during runtime when the underlying devices are + * replaced. The kernel also can use hardware devices with different + * resolutions for reading the time and for arming timers. + * + * The kernel therefore deviates from the POSIX spec in various aspects: + * + * 1) The resolution returned to user space + * + * For CLOCK_REALTIME, CLOCK_MONOTONIC, CLOCK_BOOTTIME, CLOCK_TAI, + * CLOCK_REALTIME_ALARM, CLOCK_BOOTTIME_ALAREM and CLOCK_MONOTONIC_RAW + * the kernel differentiates only two cases: + * + * I) Low resolution mode: + * + * When high resolution timers are disabled at compile or runtime + * the resolution returned is nanoseconds per tick, which represents + * the precision at which timers expire. + * + * II) High resolution mode: + * + * When high resolution timers are enabled the resolution returned + * is always one nanosecond independent of the actual resolution of + * the underlying hardware devices. + * + * For CLOCK_*_ALARM the actual resolution depends on system + * state. When system is running the resolution is the same as the + * resolution of the other clocks. During suspend the actual + * resolution is the resolution of the underlying RTC device which + * might be way less precise than the clockevent device used during + * running state. + * + * For CLOCK_REALTIME_COARSE and CLOCK_MONOTONIC_COARSE the resolution + * returned is always nanoseconds per tick. + * + * For CLOCK_PROCESS_CPUTIME and CLOCK_THREAD_CPUTIME the resolution + * returned is always one nanosecond under the assumption that the + * underlying scheduler clock has a better resolution than nanoseconds + * per tick. + * + * For dynamic POSIX clocks (PTP devices) the resolution returned is + * always one nanosecond. + * + * 2) Affect on sys_clock_settime() + * + * The kernel does not truncate the time which is handed in to + * sys_clock_settime(). The kernel internal timekeeping is always using + * nanoseconds precision independent of the clocksource device which is + * used to read the time from. The resolution of that device only + * affects the presicion of the time returned by sys_clock_gettime(). + * + * Returns: + * 0 Success. @tp contains the resolution + * -EINVAL @which_clock is not a valid clock ID + * -EFAULT Copying the resolution to @tp faulted + * -ENODEV Dynamic POSIX clock is not backed by a device + * -EOPNOTSUPP Dynamic POSIX clock does not support getres() + */ SYSCALL_DEFINE2(clock_getres, const clockid_t, which_clock, struct __kernel_timespec __user *, tp) {