From owner-svn-src-head@freebsd.org Tue Mar 14 22:16:13 2017 Return-Path: Delivered-To: svn-src-head@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 4F19BD0D4A9; Tue, 14 Mar 2017 22:16:13 +0000 (UTC) (envelope-from yaneurabeya@gmail.com) Received: from mail-qk0-x234.google.com (mail-qk0-x234.google.com [IPv6:2607:f8b0:400d:c09::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id F28F21DB7; Tue, 14 Mar 2017 22:16:12 +0000 (UTC) (envelope-from yaneurabeya@gmail.com) Received: by mail-qk0-x234.google.com with SMTP id v127so3443690qkb.2; Tue, 14 Mar 2017 15:16:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=tATd1UjWt7xbeI6kcZsBObh5JYPSOk1VT9LFSz2o51g=; b=FFNTVUtZcrs5DT1b4d5qFkFSFfigT6dOMcw5hwy4AN7WWvEuFJtGIvEA9sxFdkcwhE r0CKfU81/a/qxmqorPKc8C3tf4NRi5NAdgnfObW9z2XZ9X8qLQjkQUHJwnbztvQX/xKI d5tBjbKOuWzgwiGwC1tJl2IQ7FPKADmiQMIAWaAvZNuJeraniRbfR/XX/p4WqX5ghegT bI+kgGtMU4nKv9HAO4MbU40fm+1GwN/4sc2sAeSN3ug5PBOwNen+S1m6h/ADRVNnHIAw ZrvdACyJRCooTvto8sq1xpmVYUoT3ytJ4iizJr8T5fzfv7RndxsvKBKDQPOs7yoFCCE8 Sb9g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=tATd1UjWt7xbeI6kcZsBObh5JYPSOk1VT9LFSz2o51g=; b=ulcR3oy1/Az1dwVtOKQgJxXBxbps8Q5VYpHEFN18TzF6ncfx4bCEgVt+tReVg80V9B 1fr7ulHVq88zMvqgv8yrNmtblMWavdrRIu8R8eoeGitY2y9Fdn4E636QA+rhTqogNd24 RxFPPRrACAFeJU+rj9rXMs656hANBexhkNpWCyBpYdE68oFF+7A+4tysdC+t1Po+UrAI ka+iYvHB7flUzAhNCoe5XokC0G1CF73iNFLKWe5p0m76f6jd1gYGu915Ah8es0cAlRMZ zdpKsa3FtXxf7Xfo0DVaoPwaF4z1KuwrrkJYO+F4p4pnlibZTgvRIaYfC8M6+cFaJOV9 lbKw== X-Gm-Message-State: AFeK/H3oF2ZXrhaHR/rWd4Q+k8QCXxyRUH5fxyiLgYdhH2KlzOUjoQe5IALADCtIE+S9PCyre9evKmGgMBrREA== X-Received: by 10.55.58.193 with SMTP id h184mr1341qka.40.1489529771950; Tue, 14 Mar 2017 15:16:11 -0700 (PDT) MIME-Version: 1.0 Received: by 10.140.104.200 with HTTP; Tue, 14 Mar 2017 15:16:11 -0700 (PDT) In-Reply-To: <201703141906.v2EJ6i0x096677@repo.freebsd.org> References: <201703141906.v2EJ6i0x096677@repo.freebsd.org> From: Ngie Cooper Date: Tue, 14 Mar 2017 15:16:11 -0700 Message-ID: Subject: Re: svn commit: r315280 - in head/sys: kern sys To: Eric van Gyzen Cc: "src-committers@freebsd.org" , "svn-src-all@freebsd.org" , "svn-src-head@freebsd.org" Content-Type: text/plain; charset=UTF-8 X-BeenThere: svn-src-head@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: SVN commit messages for the src tree for head/-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Mar 2017 22:16:13 -0000 On Tue, Mar 14, 2017 at 12:06 PM, Eric van Gyzen wrote: > Author: vangyzen > Date: Tue Mar 14 19:06:44 2017 > New Revision: 315280 > URL: https://svnweb.freebsd.org/changeset/base/315280 > > Log: > When the RTC is adjusted, reevaluate absolute sleep times based on the RTC > > POSIX 2008 says this about clock_settime(2): > > If the value of the CLOCK_REALTIME clock is set via clock_settime(), > the new value of the clock shall be used to determine the time > of expiration for absolute time services based upon the > CLOCK_REALTIME clock. This applies to the time at which armed > absolute timers expire. If the absolute time requested at the > invocation of such a time service is before the new value of > the clock, the time service shall expire immediately as if the > clock had reached the requested time normally. > > Setting the value of the CLOCK_REALTIME clock via clock_settime() > shall have no effect on threads that are blocked waiting for > a relative time service based upon this clock, including the > nanosleep() function; nor on the expiration of relative timers > based upon this clock. Consequently, these time services shall > expire when the requested relative interval elapses, independently > of the new or old value of the clock. > > When the real-time clock is adjusted, such as by clock_settime(3), > wake any threads sleeping until an absolute real-clock time. > Such a sleep is indicated by a non-zero td_rtcgen. The sleep functions > will set that field to zero and return zero to tell the caller > to reevaluate its sleep duration based on the new value of the clock. > > At present, this affects the following functions: > > pthread_cond_timedwait(3) > pthread_mutex_timedlock(3) > pthread_rwlock_timedrdlock(3) > pthread_rwlock_timedwrlock(3) > sem_timedwait(3) > sem_clockwait_np(3) > > I'm working on adding clock_nanosleep(2), which will also be affected. > > Reported by: Sebastian Huber > Reviewed by: jhb, kib > MFC after: 2 weeks > Relnotes: yes > Sponsored by: Dell EMC > Differential Revision: https://reviews.freebsd.org/D9791 Thanks for this! I'll take a look at running "open_posix_testsuite" from LTP and (when time/appropriate), I'll help out with integrating in the clock_nanosleep tests from NetBSD (contrib/netbsd-tests/lib/libc/sys/t_clock_nanosleep.c, ). Cheers! -Ngie