Messages in this thread | | | Date | Tue, 10 May 2011 09:35:51 +0200 | From | Ingo Molnar <> | Subject | Re: [PATCH] ioapic: fix potential resume deadlock |
| |
* Daniel J Blueman <daniel.blueman@gmail.com> wrote:
> Fix a potential deadlock when resuming; here the calling function > has disabled interrupts, so we cannot sleep. > > Signed-off-by: Daniel J Blueman <daniel.blueman@gmail.com> > > --- > arch/x86/kernel/apic/io_apic.c | 4 ++-- > 1 files changed, 2 insertions(+), 2 deletions(-) > > diff --git a/arch/x86/kernel/apic/io_apic.c b/arch/x86/kernel/apic/io_apic.c > index 45fd33d..df63620 100644 > --- a/arch/x86/kernel/apic/io_apic.c > +++ b/arch/x86/kernel/apic/io_apic.c > @@ -621,14 +621,14 @@ struct IO_APIC_route_entry **alloc_ioapic_entries(void) > struct IO_APIC_route_entry **ioapic_entries; > > ioapic_entries = kzalloc(sizeof(*ioapic_entries) * nr_ioapics, > - GFP_KERNEL); > + GFP_ATOMIC); > if (!ioapic_entries) > return 0; > > for (apic = 0; apic < nr_ioapics; apic++) { > ioapic_entries[apic] = > kzalloc(sizeof(struct IO_APIC_route_entry) * > - nr_ioapic_registers[apic], GFP_KERNEL); > + nr_ioapic_registers[apic], GFP_ATOMIC); > if (!ioapic_entries[apic]) > goto nomem; > }
Hm, there must be some other bug here.
ioapic entries should be allocated on system bootup and should never really be deallocated.
The bug might be in the idea to call to enable_IR_x2apic() on resume - why are ioapic entries reallocated there? That call in default_setup_apic_routing() was introduced some time ago in:
fa47f7e52874: x86, x2apic: Simplify apic init in SMP and UP builds
and that it results in reallocation in the suspend patch is distinctly wrong.
I suspect the reason why this has not triggered for others is the relative rarity of affected systems?
Suresh?
Thanks,
Ingo
| |