Messages in this thread | | | Date | Wed, 28 Jan 2009 13:34:13 -0500 (EST) | From | Steven Rostedt <> | Subject | Re: Buggy IPI and MTRR code on low memory |
| |
On Wed, 28 Jan 2009, Arjan van de Ven wrote:
> On Wed, 28 Jan 2009 12:24:48 -0500 (EST) > Steven Rostedt <rostedt@goodmis.org> wrote: > > > > --- > > I'll have skip the NMI test and see if it locks up any place else. > > if you get an NMI during MTRR changing you are more or less screwed. > Really. (the cpu is uncachable etc)
Heh, the NMI is just another place that has the IPI problem. A different issue to the MTRR. Well, same bug, different place.
> > the MTRR code should disable NMIs as much as possible. > > and for sure in -RT, the MTRR change section should not be preemptable > at all.
Yeah, that is why I found this. The current code calls kfree and such from the IPI if it is allocated (not to mention the kmalloc in smp_call_function. Both of which can sleep in RT. I was forcing the data=NULL case in RT to keep it from entering the allocation code paths. But this is where I found the deadlock with MTRR (and NMI).
-- Steve
| |