lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Fri, 29 Apr 2011 17:24:21 -0700
From:	John Stultz <john.stultz@...aro.org>
To:	Arve Hjønnevåg <arve@...roid.com>
Cc:	linux-kernel@...r.kernel.org, mingo@...hat.com, hpa@...or.com,
	arnd@...db.de, tglx@...utronix.de,
	linux-tip-commits@...r.kernel.org
Subject: Re: [tip:timers/core] time: Add timekeeping_inject_sleeptime

On Fri, 2011-04-29 at 16:28 -0700, Arve Hjønnevåg wrote:
> On Fri, Apr 29, 2011 at 10:31 AM, tip-bot for John Stultz
> > @@ -85,15 +82,13 @@ static int rtc_resume(struct device *dev)
> >                        pr_debug("%s:  time travel!\n", dev_name(&rtc->dev));
> >                return 0;
> >        }
> > +       /* calculate the RTC time delta */
> > +       set_normalized_timespec(&time, newtime - oldtime, 0);
> >
> > -       /* restore wall clock using delta against this RTC;
> > -        * adjust again for avg 1/2 second RTC sampling error
> > -        */
> > -       set_normalized_timespec(&time,
> > -                               newtime + delta.tv_sec,
> > -                               (NSEC_PER_SEC >> 1) + delta.tv_nsec);
> > -       do_settimeofday(&time);
> > +       /* subtract kernel time between rtc_suspend to rtc_resume */
> > +       time = timespec_sub(time, timespec_sub(newts, oldts));
> 
> The delta you got from the rtc can be almost a second to long or
> short. Do you do anything to prevent these errors from accumulating?

Indeed. Right now we don't do anything.

I'm hoping to extend the RTC interface to provide finer resolution where
possible, but that won't help on hardware that really only gives us
seconds.

We could maybe not only track the suspend time but the RTC time deltas
for when the system is running as well and utilize those values to avoid
accumulating the error long term. But then there can be other
complications between the NTP corrected system time and the uncorrected
RTC time.

Other ideas? I know you've got a patch in the Android tree to try to
address this, should I try to adapt it for use here?

thanks
-john

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ