linux-kernel - Re: [PATCH 1/3] timekeeping: Add 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]

Date:	Fri, 14 Dec 2012 15:23:01 -0800
From:	John Stultz <john.stultz@...aro.org>
To:	Jason Gunthorpe <jgunthorpe@...idianresearch.com>
CC:	Feng Tang <feng.tang@...el.com>,
	Thomas Gleixner <tglx@...utronix.de>,
	Alessandro Zummo <a.zummo@...ertech.it>,
	linux-kernel@...r.kernel.org, alek.du@...el.com
Subject: Re: [PATCH 1/3] timekeeping: Add persistent_clock_exist flag

On 12/14/2012 01:56 PM, Jason Gunthorpe wrote:
> On Fri, Dec 14, 2012 at 01:22:50PM -0800, John Stultz wrote:
>
>> Although from a timekeeping perspective, the read_persistent_clock()
>> interface is actually *much* preferred over the rtc HCTOSYS device.
>>
>> Since read_persistent_clock() has the requirement that its safe to
>> call with IRQs disabled, we can use it in the timekeeping
>> suspend/resume code, which allows for better time accuracy.
> Sure, but my view on this is that it has nothing to do with
> read_persistent_clock. If the RTC driver can run with IRQs off is a
> property of the RTC driver and RTC hardware - it has nothing to do
> with the platform. ARM platforms will vary on a machine by machine
> basis. The rtc-mv driver used on my ARM system is perfectly
> re-entrant, lots of rtc on SOC drivers will be the same.
>
> If this is the only thing keeping you on read_persistent_clock, for
> real RTCs, then how about a RTC_DEV_SAFE_READ flag (or whatever) in
> rtc_device.flags?
>
> Reserve read_persistent_clock for things like that very specialized
> non-RTC ARM counter.
Something like this could work, although I worry it only causes even 
more code paths:
1) read_persistent_clock for non-RTC counters, called from 
timekeeping_suspend/resume
2) IRQ safe RTC called from timekeeping_suspend/resume
3) Non-IRQ safe RTC suspend/resume logic


>> While we're suggesting cleanups, the RTC Kconfig choices probably
>> need a cleanup too, as  the list of all possible drivers can be
>> confusing, when usually each architecture has only a few that they
> That is a general pain with the new 'everything is a driver'..
True, and maybe something I just have to live with.  But I can still 
make holiday wish lists :)

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/