On Thu, 20 Mar 2014, Stefani Seibold wrote: > This patch add a correct out of memory handling for setup a 32 bit vDSO. > > The patch is against tip commit 4e40112c4ff6a577dd06d92b2a54cdf06265bf74 > > Signed-off-by: Stefani Seibold <stef...@seibold.net> > --- > arch/x86/vdso/vdso32-setup.c | 17 ++++++++++++++++- > 1 file changed, 16 insertions(+), 1 deletion(-) > > diff --git a/arch/x86/vdso/vdso32-setup.c b/arch/x86/vdso/vdso32-setup.c > index 0bc363a..e1171c2 100644 > --- a/arch/x86/vdso/vdso32-setup.c > +++ b/arch/x86/vdso/vdso32-setup.c > @@ -134,8 +134,14 @@ int __init sysenter_setup(void) > } > > vdso32_size = (vdso_len + PAGE_SIZE - 1) / PAGE_SIZE; > - vdso32_pages = kmalloc(sizeof(*vdso32_pages) * vdso32_size, > GFP_ATOMIC); > + > + vdso32_pages = kmalloc(sizeof(*vdso32_pages) * vdso32_size, GFP_ATOMIC);
Why is this GFP_ATOMIC and not GFP_ATOMIC ? That code is called either from identify_boot_cpu(), where GFP_KERNEL is perfectly valid and from subsys_initcall(sysenter_setup) which is way late in the boot process where GFP_KERNEL is the RightThing. Aside of that, why do we need to call it early for X86_32 and late for X86_64? We need the vdso before we head off to user space, but not in the early boot process. Thanks, tglx -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/