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/