linux-kernel - Re: [RFC][PATCH 1/4] RTC: Class device support for persistent clock

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: <1f1b08da0805071418q365680bexafb1996dcc77ebb0@mail.gmail.com>
Date:	Wed, 7 May 2008 14:18:01 -0700
From:	"john stultz" <johnstul@...ibm.com>
To:	"Maciej W. Rozycki" <macro@...ux-mips.org>
Cc:	"Alessandro Zummo" <a.zummo@...ertech.it>,
	"Jean Delvare" <khali@...ux-fr.org>,
	"Ralf Baechle" <ralf@...ux-mips.org>,
	"Thomas Gleixner" <tglx@...utronix.de>,
	"Andrew Morton" <akpm@...ux-foundation.org>,
	rtc-linux@...glegroups.com, i2c@...sensors.org,
	linux-mips@...ux-mips.org, linux-kernel@...r.kernel.org
Subject: Re: [RFC][PATCH 1/4] RTC: Class device support for persistent clock

On Tue, May 6, 2008 at 5:40 PM, Maciej W. Rozycki <macro@...ux-mips.org> wrote:
>  This is a generic implementation of rtc_read_persistent_clock() and
>  rtc_update_persistent_clock() suitable for platforms to be used for
>  read_persistent_clock() and update_persistent_clock() calls.  An RTC
>  device selected by the user with the RTC_HCTOSYS_DEVICE option is used.
>
>   As rtc_read_persistent_clock() is not available at the time
>  timekeeping_init() is called, it will now be disabled if the class device
>  is to be used as a reference.  In this case rtc_hctosys(), already
>  present, will be used to set up the system time at the late initcall time.
>  This call has now been rewritten to make use of
>  rtc_read_persistent_clock().

Hrmm. So how is this going to work with suspend and resume?

Ideally, on resume we want to update the clock before interrupts are
reenabled so we don't get stale time values post-resume.  For systems
that sleep on reading the persistent clock, I'm open to having them
fix it up as best they can later (partly why the code can handle
read_persistent_clock() not returning anything), but unless I'm
misreading this, it seems you're proposing to make systems that do
have a safe persistent clock have to have the window where code may
see the pre-suspend time after resume.

Am I missing something here?

thanks
-john

Maciej: Sorry for the dup, I forgot to reply to all on my first mail.
--
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/