From patchwork Wed Feb 19 22:07:50 2014 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: John Stultz X-Patchwork-Id: 24966 Return-Path: X-Original-To: linaro@patches.linaro.org Delivered-To: linaro@patches.linaro.org Received: from mail-pd0-f199.google.com (mail-pd0-f199.google.com [209.85.192.199]) by ip-10-151-82-157.ec2.internal (Postfix) with ESMTPS id B788420143 for ; Wed, 19 Feb 2014 22:08:03 +0000 (UTC) Received: by mail-pd0-f199.google.com with SMTP id fp1sf2285751pdb.6 for ; Wed, 19 Feb 2014 14:08:02 -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=R286n5V6sGZKKqXxHepPE/D9Ep9BWqyktROi613cVoo=; b=CMRe7fxNE6HpM3mzs8Yeci+xZbbFMCc1My84HPXeWOV7/gJglwxRBUs6zmQQQ7Uoxf 5CwMsIgeceJMgIvhNhtdefcEplViwSLOTpwOmRGBOBAtdsmhW4l3aePBemXOoRyNEBJc iuPDS1FwTDR7I95seOK9xwF1Xs4H8bYuhN6wcMMaUyBdCpTXYaxzZMXgHgtDgoG4rRbU vJA/IqQQXuMPFlbcKiCBMnNYecwQDVcWptyAI3x76TEBnyIb8UUBeRHdLnu8D2GpDPGb HFPAARnGGrbnRf9EQ5fOk2beOg2Dao5r2utEH/fXkByV0nulNRVcbUZvblD3ZHwckB5d YE8w== X-Gm-Message-State: ALoCoQl6pOGLvjo4Iwmasxwh/PBE6avFOqnG6qES07TmqS9JVbYHE5Po/Ip1FmH729YV+U/I9Mop X-Received: by 10.66.65.202 with SMTP id z10mr1968480pas.45.1392847682539; Wed, 19 Feb 2014 14:08:02 -0800 (PST) MIME-Version: 1.0 X-BeenThere: patchwork-forward@linaro.org Received: by 10.140.26.195 with SMTP id 61ls310455qgv.19.gmail; Wed, 19 Feb 2014 14:08:02 -0800 (PST) X-Received: by 10.52.65.207 with SMTP id z15mr1684612vds.61.1392847682383; Wed, 19 Feb 2014 14:08:02 -0800 (PST) Received: from mail-ve0-f172.google.com (mail-ve0-f172.google.com [209.85.128.172]) by mx.google.com with ESMTPS id ja16si704607vec.88.2014.02.19.14.08.02 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 19 Feb 2014 14:08:02 -0800 (PST) Received-SPF: neutral (google.com: 209.85.128.172 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.172; Received: by mail-ve0-f172.google.com with SMTP id c14so1063487vea.31 for ; Wed, 19 Feb 2014 14:08:02 -0800 (PST) X-Received: by 10.52.23.68 with SMTP id k4mr19316842vdf.24.1392847682276; Wed, 19 Feb 2014 14:08:02 -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 u4csp9448vcz; Wed, 19 Feb 2014 14:08:01 -0800 (PST) X-Received: by 10.66.216.129 with SMTP id oq1mr4904114pac.75.1392847681492; Wed, 19 Feb 2014 14:08:01 -0800 (PST) Received: from mail-pb0-f50.google.com (mail-pb0-f50.google.com [209.85.160.50]) by mx.google.com with ESMTPS id f1si1404521pbn.166.2014.02.19.14.08.00 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 19 Feb 2014 14:08:01 -0800 (PST) Received-SPF: neutral (google.com: 209.85.160.50 is neither permitted nor denied by best guess record for domain of john.stultz@linaro.org) client-ip=209.85.160.50; Received: by mail-pb0-f50.google.com with SMTP id rq2so983012pbb.37 for ; Wed, 19 Feb 2014 14:08:00 -0800 (PST) X-Received: by 10.66.146.199 with SMTP id te7mr4918052pab.106.1392847680830; Wed, 19 Feb 2014 14:08:00 -0800 (PST) Received: from localhost.localdomain (c-67-170-153-23.hsd1.or.comcast.net. [67.170.153.23]) by mx.google.com with ESMTPSA id e3sm3978114pbc.17.2014.02.19.14.07.59 for (version=TLSv1.1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 19 Feb 2014 14:08:00 -0800 (PST) From: John Stultz To: Kay Sievers Cc: John Stultz , Richard Cochran Subject: [PATCH][RFC] time: Fix negative offset handling in timekeeping_inject_offset Date: Wed, 19 Feb 2014 14:07:50 -0800 Message-Id: <1392847670-7053-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.172 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: , Kay, Richard, Scratched out a fix for this below and it seems to pass my trivial test, which you can find here: https://raw2.github.com/johnstultz-work/timetests/master/adj-setoffset.c I need to validate that it doesn't cause other problems in the time accounting code, but wanted to send it out for your initial thoughts and any further testing you might have before I send it to a wider audience. thanks -john 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 naieve validation check 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 #5 and #6 above as invalid, forcing users to use the more awkward 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 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} But I consider this is too ackward and misformed to be reasonably supported, so it will still trigger EINVAL errors. Cc: Richard Cochran Cc: Kay Sievers 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);