From patchwork Fri Feb 21 21:50:30 2014 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: John Stultz X-Patchwork-Id: 25126 Return-Path: X-Original-To: linaro@patches.linaro.org Delivered-To: linaro@patches.linaro.org Received: from mail-yk0-f200.google.com (mail-yk0-f200.google.com [209.85.160.200]) by ip-10-151-82-157.ec2.internal (Postfix) with ESMTPS id EA5A520143 for ; Fri, 21 Feb 2014 21:50:35 +0000 (UTC) Received: by mail-yk0-f200.google.com with SMTP id q200sf11416340ykb.3 for ; Fri, 21 Feb 2014 13:50:35 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:delivered-to:from:to:cc:subject :date:message-id:x-original-sender:x-original-authentication-results :precedence:mailing-list:list-id:list-post:list-help:list-archive :list-unsubscribe; bh=b2spKL3OhBriGDFP/MoHTqQ6J6gF81xZUk/K7jg46Ks=; b=aLd4/JUiUbGwom5JkBYYWbLqe4CFESmixSbvYE+hKqgnHqI2yudIcz9AGkEsn5k3yu uV/Nbyezjc5Rui3abv19pBIVicSL07qmhxV1rY7yS2qzxrnmU4NUtm/TdqpDDxjGyzhE lD6AQoIUozUMieIIjWoUNiaa7XBKQan+IE7teBr8lDX5OA8PoMpI/U9rHiTOwzSRv+6l ECleWzJo//flncwzZ97yDwVAic5/amzMKgDdQaWWIj0M/wUfYrpsoedtt3HfPfkUkW2j NV1RS0c5dgwJoJAegC6CKwT4r4N5QmmWPnciYe0EcRIWvMZI9QeVdZREgy9eOw18NAZO 0T6A== X-Gm-Message-State: ALoCoQnHMtRJWKZN1BO9IWoIacmUl4OflvuI5WOgvQN5IkzlQgH5nh87ddQJTEudpS15dOeX6wVo X-Received: by 10.236.70.202 with SMTP id p50mr4065397yhd.18.1393019435697; Fri, 21 Feb 2014 13:50:35 -0800 (PST) MIME-Version: 1.0 X-BeenThere: patchwork-forward@linaro.org Received: by 10.140.31.139 with SMTP id f11ls1137043qgf.71.gmail; Fri, 21 Feb 2014 13:50:35 -0800 (PST) X-Received: by 10.52.183.106 with SMTP id el10mr5217625vdc.73.1393019435567; Fri, 21 Feb 2014 13:50:35 -0800 (PST) Received: from mail-ve0-f174.google.com (mail-ve0-f174.google.com [209.85.128.174]) by mx.google.com with ESMTPS id cp10si3583312ved.20.2014.02.21.13.50.35 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 21 Feb 2014 13:50:35 -0800 (PST) Received-SPF: neutral (google.com: 209.85.128.174 is neither permitted nor denied by best guess record for domain of patch+caf_=patchwork-forward=linaro.org@linaro.org) client-ip=209.85.128.174; Received: by mail-ve0-f174.google.com with SMTP id pa12so3891619veb.33 for ; Fri, 21 Feb 2014 13:50:35 -0800 (PST) X-Received: by 10.220.98.204 with SMTP id r12mr6366226vcn.48.1393019435483; Fri, 21 Feb 2014 13:50:35 -0800 (PST) X-Forwarded-To: patchwork-forward@linaro.org X-Forwarded-For: patch@linaro.org patchwork-forward@linaro.org Delivered-To: patches@linaro.org Received: by 10.220.174.196 with SMTP id u4csp65564vcz; Fri, 21 Feb 2014 13:50:35 -0800 (PST) X-Received: by 10.66.221.103 with SMTP id qd7mr11494897pac.44.1393019434665; Fri, 21 Feb 2014 13:50:34 -0800 (PST) Received: from mail-pb0-f51.google.com (mail-pb0-f51.google.com [209.85.160.51]) by mx.google.com with ESMTPS id pj6si2530488pbb.126.2014.02.21.13.50.34 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 21 Feb 2014 13:50:34 -0800 (PST) Received-SPF: neutral (google.com: 209.85.160.51 is neither permitted nor denied by best guess record for domain of john.stultz@linaro.org) client-ip=209.85.160.51; Received: by mail-pb0-f51.google.com with SMTP id un15so3990816pbc.24 for ; Fri, 21 Feb 2014 13:50:34 -0800 (PST) X-Received: by 10.68.215.68 with SMTP id og4mr11472649pbc.112.1393019434188; Fri, 21 Feb 2014 13:50:34 -0800 (PST) Received: from buildbox.hsd1.or.comcast.net (c-67-170-153-23.hsd1.or.comcast.net. [67.170.153.23]) by mx.google.com with ESMTPSA id nv7sm24609574pbc.31.2014.02.21.13.50.32 for (version=TLSv1.1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 21 Feb 2014 13:50:33 -0800 (PST) From: John Stultz To: LKML Cc: John Stultz , Thomas Gleixner , Prarit Bhargava , Richard Cochran Subject: [PATCH] [RFC] time: Improve negative offset handling in timekeeping_inject_offset Date: Fri, 21 Feb 2014 13:50:30 -0800 Message-Id: <1393019430-13200-1-git-send-email-john.stultz@linaro.org> X-Mailer: git-send-email 1.8.3.2 X-Removed-Original-Auth: Dkim didn't pass. X-Original-Sender: john.stultz@linaro.org X-Original-Authentication-Results: mx.google.com; spf=neutral (google.com: 209.85.128.174 is neither permitted nor denied by best guess record for domain of patch+caf_=patchwork-forward=linaro.org@linaro.org) smtp.mail=patch+caf_=patchwork-forward=linaro.org@linaro.org Precedence: list Mailing-list: list patchwork-forward@linaro.org; contact patchwork-forward+owners@linaro.org List-ID: X-Google-Group-Id: 836684582541 List-Post: , List-Help: , List-Archive: List-Unsubscribe: , The adjtimex() ADJ_SETOFFSET feature allows a offset in timespec format to be added to the current time. This value can be positive or negative. However, representing a negative value in a timespec can be confusing, as there may be numerous ways to represent the same amount of time. Positive values are most obviously represented: 1) { 0, 500000000} 2) { 3, 0} 3) { 3, 500000000} While negative values are more complex and confusing: 4) {-5, 0} 5) { 0, -500000000} 6) {-5, -500000000} 7) {-6, 500000000} Note that the last two values (#6 and #7) actually represent the same amount of time. In timekeeping_inject_offset, a likely naieve validation check (implemented by me) on the timespec value resulted in -EINVAL being returned if the nsec portion of the timespec was negative. This resulted in the ADJ_SETOFFSET interface to consider examples representations of {sec - 1, NSEC_PER_SEC + nsec} for negative values (like example #7 above). Initially I suspected the extra logic for underflow handling was the reason this was done, but in looking at it, set_normalized_timespec() handles both overflows and underflows properly. Thus this patch would allows for all of the representations above to be considered valid. There is of course, one missing example from the list above: 8) { 4, -500000000} One could reasonably argue that examples #8 and #7 are simply invalid timespecs, and we should have a rule: * If tv_sec is nonzero, then the signs must agree. I fully agree with this, but since the existing interface only accepts #7 style negative timespecs, we have to continue to support that style for this interface. Another possible view is that the rule that the tv_nsec value always be [0,1e9). And that while maybe non-intuitive, the #7 style representations are valid and the existing interface is correct, thus no further change is needed. Thoughts? Comments? I still need to do some further validation on this patch to make sure it doesn't have any corner cases that breaks normal time handling. But I wanted to get it out for wider discussion. Cc: Thomas Gleixner Cc: Prarit Bhargava Cc: Richard Cochran Reported-by: Kay Sievers Signed-off-by: John Stultz --- kernel/time/timekeeping.c | 6 +++++- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/kernel/time/timekeeping.c b/kernel/time/timekeeping.c index 0aa4ce8..0b5ef8c 100644 --- a/kernel/time/timekeeping.c +++ b/kernel/time/timekeeping.c @@ -539,7 +539,11 @@ int timekeeping_inject_offset(struct timespec *ts) struct timespec tmp; int ret = 0; - if ((unsigned long)ts->tv_nsec >= NSEC_PER_SEC) + /* Disallow any {1,-500} style timespecs */ + if ((ts->tv_sec > 0) && ((unsigned long)ts->tv_nsec >= NSEC_PER_SEC)) + return -EINVAL; + /* While interval may be negative, should still be sane */ + if (abs(ts->tv_nsec) >= NSEC_PER_SEC) return -EINVAL; raw_spin_lock_irqsave(&timekeeper_lock, flags);