linux-kernel - Re: [stable] [patch 3/3] rtc: Limit frequency

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, 05 Aug 2011 02:04:19 -0700
From:	John Stultz <john.stultz@...aro.org>
To:	Joshua Kinard <kumba@...too.org>
Cc:	Willy Tarreau <w@....eu>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Thomas Gleixner <tglx@...utronix.de>,
	Ben Greear <greearb@...delatech.com>,
	Ingo Molnar <mingo@...e.hu>,
	LKML <linux-kernel@...r.kernel.org>, stable@...nel.org
Subject: Re: [stable] [patch 3/3] rtc: Limit frequency

On Thu, 2011-08-04 at 23:39 -0400, Joshua Kinard wrote:
> On 07/22/2011 18:39, Willy Tarreau wrote:
> > On Fri, Jul 22, 2011 at 03:05:50PM -0700, Andrew Morton wrote:
> >> On Fri, 22 Jul 2011 09:12:51 -0000
> >> Thomas Gleixner <tglx@...utronix.de> wrote:
> >>
> >>> The RTC hrtimer is self rearming. We really need to limit the
> >>> frequency to something sensible.
> >>
> >>> Cc: stable@...nel.org
> >>
> >> Why?  What failures does the current code cause?  What effect do these
> >> failures have upon users?
> > 
> > I would add that if we go that route, we should at least accept values
> > that were documented as possible till now. Man rtc says 2 Hz to 8192 Hz,
> > but Thomas' proposed patch limits it to 5000 Hz, so some breakage is to
> > be expected.
> > 
> > Regards,
> > Willy
> 
> To me, it would make sense to lock it at 8192Hz.  I re-wrote a driver for the DS1685 family of Dallas chips that I need
> to cleanup and re-submit, but in researching that specific RTC, I really could not find an RTC out there that went above
> 8192.
> 
> Arguably, 32768Hz might also work.  The DS1685 runs at this mode normally, but it disables PIE when it does.
> 
> My vote is 8192Hz.

Yea, I submitted a slightly different version of Thomas' patch which set
it to 8192Hz via the tip tree, but the original one went upstream first.
I'm away from home right now, so I'll be re-submitting just that change
probably next week.

> Also, can we get a wrapper of some kind in the RTC core to allow an
> RTC driver to override the hrtimer /PIE emulation if
> needed?  I have in the DS1685 driver full support for its PIE mode and
> really do not want to gut it as part of the
> cleanup.  Some kind of override API would be nice in case anyone ever
> runs into this chip (or its family members).

I'm torn here. It would be good to have the functionality listed in some
way so it is documented. However as we abstract the RTC to be more of an
internal tool for the kernel, rather then hardware directly addressed
from userland, the PIE mode is really not as useful (and quite messier
to multiplex).  I'd much rather try to extend the alarm interfaces to
allow for higher resolution, so it could be used as a alarmed highres
oneshot timer if the hardware supports it.

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/