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]
Message-ID: <512A4A19.2090800@redhat.com>
Date:	Sun, 24 Feb 2013 12:12:57 -0500
From:	Prarit Bhargava <prarit@...hat.com>
To:	John Stultz <john.stultz@...aro.org>
CC:	linux-kernel@...r.kernel.org, Thomas Gleixner <tglx@...utronix.de>,
	x86@...nel.org, Matt Fleming <matt.fleming@...el.com>,
	David Vrabel <david.vrabel@...rix.com>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Andi Kleen <ak@...ux.intel.com>, linux-efi@...r.kernel.org,
	Alessandro Zummo <a.zummo@...ertech.it>
Subject: Re: [RFE PATCH 1/2] x86, rtc, ntp, Do full rtc synchronization with
 ntp



On 02/22/2013 03:42 PM, John Stultz wrote:
> 
> 
> This looks reasonable to me.
> 
> Though I want to make sure we get this thoroughly tested by the various distros
> so we don't surprise anyone, since it has to potential to cause problems where
> folks are dualbooting windows (using a localtime RTC) and do not have their OS
> setup to trigger warp_clock to adjust for the localtime rtc (instead getting a
> time correction later via NTP).
> 
> I'll queue it and see about getting it merged to -tip & -next. Then we'll have
> to decide if 3.10 or 3.11 is the right time frame to land it.
> 

cc'ing Alessandro as well.

John, I've been testing this across various systems (including those known to
have some wonkiness with the RTC in BIOS ... see comment below) to see if this
code impacts anything.

I've tested mainly using Fedora 18 (with the latest kernel -tip obviously), but
I also installed Ubuntu on a system to see if there was any noticeable impact
there too.  I have not seen any unusual testing failures on AMD or Intel systems.

On the one system which I know to have "weak" battery such that the RTC doesn't
"stick" on the system shutdown the clock resets itself in BIOS reboot to "Jan 1
1970".  When I tested previously I could not get the RTC written to the current
date; after my changes, the RTC does at least reflect the current date through a
reboot.  It should be noted that if I do replace the battery on this system I
can get the RTC to properly "stick" through a reboot.

Given the test results I think this should go in earlier rather than later;  I'd
like to target 3.10 for the full sync, and possibly 3.11 for the HCTOSYS stuff.

... unless anyone has a strenuous objection ;)

P.
--
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