[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <alpine.LFD.2.00.0908141025290.1283@localhost.localdomain>
Date: Fri, 14 Aug 2009 10:28:16 +0200 (CEST)
From: Thomas Gleixner <tglx@...utronix.de>
To: Suresh Siddha <suresh.b.siddha@...el.com>
cc: "mingo@...e.hu" <mingo@...e.hu>, "hpa@...or.com" <hpa@...or.com>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"Pallipadi, Venkatesh" <venkatesh.pallipadi@...el.com>,
"Brown, Len" <len.brown@...el.com>
Subject: Re: [patch] clockevents_notify() need to be called with irq's
enabled
On Fri, 14 Aug 2009, Suresh Siddha wrote:
> On Thu, 2009-08-13 at 23:05 -0700, Thomas Gleixner wrote:
> > On Thu, 13 Aug 2009, Suresh Siddha wrote:
> >
> > > From: Suresh Siddha <suresh.b.siddha@...el.com>
> > > Subject: clockevents_notify() need to be called with irq's enabled
> > >
> > > Currently clockevents_notify() is called with interrupts enabled at some
> > > places and interrupts disabled at some other places.
> >
> > The only place I can see which calls clockevents_notify with
> > interrupts enabled is the hrtimer cpu hotplug code.
> >
> > I'm a bit wary to enable interrupts all over the place in sensitive
> > corners like ACPI idle code ...
> >
> > Why don't we just do the obvious and take clockevents_lock irqsave ?
>
> We didn't go that route because of the smp_call_function() in the cpu
> hotplug code. So we can't disable interrupts in that path.
Hmm, that's the tick_broadcast_on_off() stuff, right ?
Thanks,
tglx
--
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/
Powered by blists - more mailing lists