linux-kernel - Re: [PATCH v2 3/3] time: clocksource: Add a comment to CLOCK_SOURCE_SUSPEND

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] [day] [month] [year] [list]

Date:	Thu, 29 Jan 2015 00:00:07 +0800
From:	Xunlei Pang <pang.xunlei@...aro.org>
To:	Thomas Gleixner <tglx@...utronix.de>
Cc:	lkml <linux-kernel@...r.kernel.org>,
	"rtc-linux@...glegroups.com" <rtc-linux@...glegroups.com>,
	Alessandro Zummo <a.zummo@...ertech.it>,
	John Stultz <john.stultz@...aro.org>,
	Arnd Bergmann <arnd.bergmann@...aro.org>
Subject: Re: [PATCH v2 3/3] time: clocksource: Add a comment to CLOCK_SOURCE_SUSPEND_NONSTOP

Hi Thomas,

On 25 January 2015 at 01:07, Thomas Gleixner <tglx@...utronix.de> wrote:
> On Sat, 24 Jan 2015, Xunlei Pang wrote:
>
>> Before this, I tried to add some code to catch such problem at the
>> time of registering the clocksource, like using the
>> CLOCKSOURCE_MASK(), for example 64bit counter will never wrap for
>> us. But there may be other values like CLOCKSOURCE_MASK(56), I just
>> can't figure out exactly how to do this judge.
>
> I don't think there is a good way to do so. Registration time is the
> wrong place anyway because the problem depends on:
>
>  - The width of the counter
>  - The frequency of the counter
>
> The frequency of the counter might even change after registration. Now
> add the unknown duration of the suspend to the picture and you're
> completely lost.
>
> All we can do is provide information about the actual wraparound time,
> if the CLOCK_SOURCE_SUSPEND_NONSTOP flag is set and the wraparound
> time is less than some reasonable margin.
>

Yes, we can only deal with it approximately. How about this?

1) Add a new member about reference wraparound time(max system suspend
period allowed) to struct  clocksource. In
__clocksource_updatefreq_scale(), we can use  "sec" which already
applys 12.5% margin as its value.

2) Add a new tuneable sysctl threshold with a default time period
value(for example, 365 days)
    We can also printk its value when booting or changing its value to
notice people about this.

3) then,  in timekeeping_resume(), we can compare the reference
wraparound of the nonstop clocksource with the sysctl threshold to
decide if it is dependable to use.

Thanks,
Xunlei

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