RTC revert request

RTC revert request

[john stultz]

Hey Linus,
	Over the holiday break, its been found that a couple of the RTC fixes I
pushed out have been causing worse problems on some hardware then they
fix.

Thus, would you please revert:

93b2ec0128c431148b216b8f7337c1a52131ef03
rtc: Expire alarms after the time is set.

and 

c0afabd3d553c521e003779c127143ffde55a16f
rtc: Disable the alarm in the hardware


I'll work with the Neil and Rabin to make sure the issues these patches
try to address get properly fixed for 3.3.

Sorry again for these late regressions.


Greg: I think you've already picked up "rtc: Disable the alarm in the
hardware" and will need to revert that too.  Again, my apologies.

thanks
-john

Re: RTC revert request

[Linus Torvalds]

On Tue, Jan 3, 2012 at 7:36 PM, john stultz <johnstul@us.ibm.com> wrote:
>
> Thus, would you please revert:
>
> 93b2ec0128c431148b216b8f7337c1a52131ef03
> rtc: Expire alarms after the time is set.
>
> and
>
> c0afabd3d553c521e003779c127143ffde55a16f
> rtc: Disable the alarm in the hardware

Ok, I picked up on the second revert already because of being cc'd on
the discussion about the stable tree.

Can you point me at the background for that first one, or write a
changelog for the revert for me? I don't want to have reverts without
background and explanation of them..

                     Linus

Re: RTC revert request

[john stultz]

On Tue, 2012-01-03 at 19:49 -0800, Linus Torvalds wrote:
> On Tue, Jan 3, 2012 at 7:36 PM, john stultz <johnstul@us.ibm.com> wrote:
> >
> > Thus, would you please revert:
> >
> > 93b2ec0128c431148b216b8f7337c1a52131ef03
> > rtc: Expire alarms after the time is set.
> >
> > and
> >
> > c0afabd3d553c521e003779c127143ffde55a16f
> > rtc: Disable the alarm in the hardware
> 
> Ok, I picked up on the second revert already because of being cc'd on
> the discussion about the stable tree.

Thanks. Sorry for being repetitive, I just wanted to make sure you saw
both.

> Can you point me at the background for that first one, or write a
> changelog for the revert for me? I don't want to have reverts without
> background and explanation of them..

Sure. Here's my assessment of the problem:
	https://lkml.org/lkml/2012/1/3/425

Here's Neil's comments, filling in more on the original issue, as well
as his agreement that we should revert for now:
	https://lkml.org/lkml/2012/1/3/454


The basic summary is that we need to ensure that RTC alarms in the past
are not added to the timerqueue, or if time is set forward, we properly
expire any alarms that are set to the past. Neil's patch does this by
scheduling the timer expiry function when we set the RTC time and at
initialization, when the hardware alarm could return a value in the
past. 

Unfortunately, the second case can cause a null pointer dereference if
the scheduled work runs prior to us completing the registration
function. Since the registration function isn't complete, the we haven't
yet returned a valid rtc structure pointer. And the scheduled work may
require that pointer.

This issue so far has only cropped up on Xen SMP guests, where
registration function takes longer and the scheduled work can quickly
run on another cpu before the registration function returns. Regardless
its a clear bug.

The right fix is likely to fix the initialization so that we don't use
any hardware alarm values that are in the past at registration time.
However, such a change will require more testing and this close to a
release I'd be more comfortable just reverting the problematic change.

Is that ok for a log?

thanks
-john