linux-kernel - Re: [rtc-linux] Re: [PATCH 4/9 RESEND] RFC: timekeeping: introduce flag systime_was

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: <51C38BFE.9000405@ahsoftware.de>
Date:	Fri, 21 Jun 2013 01:10:54 +0200
From:	Alexander Holler <holler@...oftware.de>
To:	John Stultz <john.stultz@...aro.org>
CC:	rtc-linux@...glegroups.com, linux-kernel@...r.kernel.org,
	Andrew Morton <akpm@...ux-foundation.org>,
	Thomas Gleixner <tglx@...utronix.de>,
	Alessandro Zummo <a.zummo@...ertech.it>
Subject: Re: [rtc-linux] Re: [PATCH 4/9 RESEND] RFC: timekeeping: introduce
 flag systime_was_set

Am 20.06.2013 21:28, schrieb John Stultz:

>>>
>>> But ntpd can be installed afterwards, and it would be silly to require
>>> users edit their boot arguments when installing the ntp package.
>>>
>
> This point you left un-addressed, and is the key problem I see with
> requiring boot arguments.

There is no requirement for an additional boot argument.

That would only be necessary if you start ntpdate without using a 
persistent clock and before loading of (working) rtc-modules would have 
finished. And even then it would only be necessary if you use ntpdate 
(once) while a driver for the rtc is in it's registration phase and 
wants to set the clock or if you use ntp and the rtc which registers 
while ntp sets the time, has a time which would force ntp to refuse 
further adjustments. And in both cases only, if you don't have disabled 
the proposed hctosys with using a boot argument. Just because a boot 
argument makes it possible to disable hctosys by RTC doesn't mean it's 
necessary.

Sorry for beeing pedantic, but I have to defend my decision to avoid 
locking just because of that possibility. I was fully aware of that 
unlikely race condition.

Anyway, I've already accomplished to add locking to prevent that case.

Regards,

Alexander Holler
--
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/