[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <BANLkTi=o0Z=Pc3KGDcZKr+a3OPWgb=iZrg@mail.gmail.com>
Date: Mon, 16 May 2011 20:53:09 +0100
From: Daniel J Blueman <daniel.blueman@...il.com>
To: Suresh Siddha <suresh.b.siddha@...el.com>
Cc: mingo@...e.hu, tglx@...utronix.de, hpa@...or.com,
linux-kernel@...r.kernel.org, stable@...nel.org
Subject: Re: [patch 1/4] x86, ioapic: fix potential resume deadlock
On 16 May 2011 19:56, Suresh Siddha <suresh.b.siddha@...el.com> wrote:
> From: Daniel J Blueman <daniel.blueman@...il.com>
> 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@...il.com>
> Signed-off-by: Suresh Siddha <suresh.b.siddha@...el.com>
> Cc: stable@...nel.org [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@...il.com>
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@...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