On Thu, 20 Mar 2014, Thomas Gleixner wrote:
> 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 ? Should be: Why is this GFP_ATOMIC and not GFP_KERNEL ? > 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/
