Re: [patch 1/4] x86, ioapic: fix potential resume deadlock
From: Daniel J Blueman
Date: Mon May 16 2011 - 15:53:19 EST
On 16 May 2011 19:56, Suresh Siddha <suresh.b.siddha@xxxxxxxxx> wrote:
> From: Daniel J Blueman <daniel.blueman@xxxxxxxxx>
> Subject: x86, ioapic: fix potential resume deadlock
>
> Fix a potential deadlock when resuming; here the calling function
> has disabled interrupts, so we cannot sleep.
>
> Change the memory allocation flag from GFP_KERNEL to GFP_ATOMIC.
>
> TODO: We can do away with this memory allocation during resume by
> reusing the ioapic suspend/resume code that uses boot time allocated
> buffers.
>
> Signed-off-by: Daniel J Blueman <daniel.blueman@xxxxxxxxx>
> Signed-off-by: Suresh Siddha <suresh.b.siddha@xxxxxxxxx>
> Cc: stable@xxxxxxxxxx [v2.6.39]
> ---
> arch/x86/kernel/apic/io_apic.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> Index: linux-2.6-tip/arch/x86/kernel/apic/io_apic.c
> ===================================================================
> --- linux-2.6-tip.orig/arch/x86/kernel/apic/io_apic.c
> +++ linux-2.6-tip/arch/x86/kernel/apic/io_apic.c
> @@ -621,14 +621,14 @@ struct IO_APIC_route_entry **alloc_ioapi
> 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;
> }
I just tested this patch series (1-3) and it does addresses the resume
allocation failures I was consistently seeing (triggering your
warning); it passes nicely with full lock, allocation etc debugging,
so looks all good. Tested-by: Daniel J Blueman
<daniel.blueman@xxxxxxxxx>
Thanks, Suresh!
Daniel
--
Daniel J Blueman
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/