Shaohua Li <[email protected]> wrote:
>
> The patch seems missed.
> GFP_KERNEL isn't ok for runtime (cpu hotplug).
>
> Signed-off-by: Shaohua Li<[email protected]>
> ---
>
> linux-2.6.15-root/arch/i386/kernel/cpu/common.c | 2 +-
> 1 files changed, 1 insertion(+), 1 deletion(-)
>
> diff -puN arch/i386/kernel/cpu/common.c~cpuhp arch/i386/kernel/cpu/common.c
> --- linux-2.6.15/arch/i386/kernel/cpu/common.c~cpuhp 2006-03-14 12:13:43.000000000 +0800
> +++ linux-2.6.15-root/arch/i386/kernel/cpu/common.c 2006-03-14 12:14:12.000000000 +0800
> @@ -605,7 +605,7 @@ void __devinit cpu_init(void)
> /* alloc_bootmem_pages panics on failure, so no check */
> memset(gdt, 0, PAGE_SIZE);
> } else {
> - gdt = (struct desc_struct *)get_zeroed_page(GFP_KERNEL);
> + gdt = (struct desc_struct *)get_zeroed_page(GFP_ATOMIC);
> if (unlikely(!gdt)) {
> printk(KERN_CRIT "CPU%d failed to allocate GDT\n", cpu);
> for (;;)
This isn't good. GFP_ATOMIC can fail, and if it does, we'll lose this CPU
and probably the entire machine. It's OK to do this during initial boot,
but not so OK to do it during CPU hotplug.
So can we please fix it better?
You don't describe _why_ the CPU is running atomically here - I wish you had.
One approach would be to allocate the page earlier, before we enter the
atomic region, and to pass that page down to cpu_init(), or to save a
pointer to it in an array of page*'s somewhere.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
