Re: [PATCH] x86, vdso32: fix out of memory handling setup vDSO

[Thomas Gleixner]

On Thu, 20 Mar 2014, Stefani Seibold wrote:
> Am Donnerstag, den 20.03.2014, 10:53 +0100 schrieb Thomas Gleixner:
> > 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 <stefani@xxxxxxxxxxx>
> > > ---
> > >  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.
> > 
> 
> All complains are design decisions not made by me. I will send a patch
> for the GFP_ATOMIC thing. For the other one it would be the best to ask
> Andy for the reason.

I'm not saying it's your fault, but if we rework code, then we really
should question such things. What happens if you remove the x32 call
and make the x64 subsys thing valid for both cases?

Thanks,

	tglx
--
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/