* [PATCH] x86, vdso32: fix out of memory handling setup vDSO @ 2014-03-20 7:45 Stefani Seibold 2014-03-20 9:53 ` Thomas Gleixner 0 siblings, 1 reply; 13+ messages in thread From: Stefani Seibold @ 2014-03-20 7:45 UTC (permalink / raw) To: gregkh, linux-kernel, x86, tglx, mingo, hpa, ak, aarcange, john.stultz, luto, xemul, gorcunov, andriy.shevchenko Cc: Martin.Runge, Andreas.Brief, Stefani Seibold 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@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); + if (!vdso32_pages) + goto fail; + vdso_pages = kmalloc(VDSO_OFFSET(vdso32_size), GFP_ATOMIC); + if (!vdso_pages) + goto fail; for(i = 0; i != vdso32_size; ++i) vdso32_pages[i] = virt_to_page(vdso_pages + VDSO_OFFSET(i)); @@ -144,6 +150,12 @@ int __init sysenter_setup(void) patch_vdso32(vdso_pages, vdso_len); return 0; +fail: + kfree(vdso32_pages); + kfree(vdso_pages); + vdso32_size = 0; + + return -ENOMEM; } /* Setup a VMA at program startup for the vsyscall page */ @@ -162,6 +174,9 @@ int arch_setup_additional_pages(struct linux_binprm *bprm, int uses_interp) if (vdso_enabled != 1) /* Other values all mean "disabled" */ return 0; + if (!vdso32_size) + return 0; + down_write(&mm->mmap_sem); addr = get_unmapped_area(NULL, 0, PAGE_SIZE, 0, 0); -- 1.9.0 ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [PATCH] x86, vdso32: fix out of memory handling setup vDSO 2014-03-20 7:45 [PATCH] x86, vdso32: fix out of memory handling setup vDSO Stefani Seibold @ 2014-03-20 9:53 ` Thomas Gleixner 2014-03-20 10:49 ` Thomas Gleixner 2014-03-20 11:38 ` Stefani Seibold 0 siblings, 2 replies; 13+ messages in thread From: Thomas Gleixner @ 2014-03-20 9:53 UTC (permalink / raw) To: Stefani Seibold Cc: gregkh, linux-kernel, x86, mingo, hpa, ak, aarcange, john.stultz, luto, xemul, gorcunov, andriy.shevchenko, Martin.Runge, Andreas.Brief 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@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 ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [PATCH] x86, vdso32: fix out of memory handling setup vDSO 2014-03-20 9:53 ` Thomas Gleixner @ 2014-03-20 10:49 ` Thomas Gleixner 2014-03-20 11:38 ` Stefani Seibold 1 sibling, 0 replies; 13+ messages in thread From: Thomas Gleixner @ 2014-03-20 10:49 UTC (permalink / raw) To: Stefani Seibold Cc: gregkh, linux-kernel, x86, mingo, hpa, ak, aarcange, john.stultz, luto, xemul, gorcunov, andriy.shevchenko, Martin.Runge, Andreas.Brief 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 <stefani@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 > > ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [PATCH] x86, vdso32: fix out of memory handling setup vDSO 2014-03-20 9:53 ` Thomas Gleixner 2014-03-20 10:49 ` Thomas Gleixner @ 2014-03-20 11:38 ` Stefani Seibold 2014-03-20 12:30 ` Thomas Gleixner 1 sibling, 1 reply; 13+ messages in thread From: Stefani Seibold @ 2014-03-20 11:38 UTC (permalink / raw) To: Thomas Gleixner Cc: gregkh, linux-kernel, x86, mingo, hpa, ak, aarcange, john.stultz, luto, xemul, gorcunov, andriy.shevchenko, Martin.Runge, Andreas.Brief 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@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. > 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. - Stefani ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [PATCH] x86, vdso32: fix out of memory handling setup vDSO 2014-03-20 11:38 ` Stefani Seibold @ 2014-03-20 12:30 ` Thomas Gleixner 2014-03-20 15:02 ` Andy Lutomirski 0 siblings, 1 reply; 13+ messages in thread From: Thomas Gleixner @ 2014-03-20 12:30 UTC (permalink / raw) To: Stefani Seibold Cc: gregkh, linux-kernel, x86, mingo, hpa, ak, aarcange, john.stultz, luto, xemul, gorcunov, andriy.shevchenko, Martin.Runge, Andreas.Brief 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@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. > > > > 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 ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [PATCH] x86, vdso32: fix out of memory handling setup vDSO 2014-03-20 12:30 ` Thomas Gleixner @ 2014-03-20 15:02 ` Andy Lutomirski 2014-03-20 15:15 ` Thomas Gleixner 0 siblings, 1 reply; 13+ messages in thread From: Andy Lutomirski @ 2014-03-20 15:02 UTC (permalink / raw) To: Thomas Gleixner Cc: Stefani Seibold, Greg KH, linux-kernel, X86 ML, Ingo Molnar, H. Peter Anvin, Andi Kleen, Andrea Arcangeli, John Stultz, Pavel Emelyanov, Cyrill Gorcunov, andriy.shevchenko, Martin Runge, Andreas Brief On Thu, Mar 20, 2014 at 5:30 AM, Thomas Gleixner <tglx@linutronix.de> wrote: > 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@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. >> > >> >> 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? > It's not just that. The x86_64 and x32 vdso page arrays are *far* cleaner than the 32-bit variant. They manage to do the entire vdso setup dance without any allocation at all. This avoids silly questions about error handling and GFP_KERNEL :) See vdso/vdso.S for the rather small amount of magic needed. --Andy ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [PATCH] x86, vdso32: fix out of memory handling setup vDSO 2014-03-20 15:02 ` Andy Lutomirski @ 2014-03-20 15:15 ` Thomas Gleixner 2014-03-20 15:18 ` Andy Lutomirski 0 siblings, 1 reply; 13+ messages in thread From: Thomas Gleixner @ 2014-03-20 15:15 UTC (permalink / raw) To: Andy Lutomirski Cc: Stefani Seibold, Greg KH, linux-kernel, X86 ML, Ingo Molnar, H. Peter Anvin, Andi Kleen, Andrea Arcangeli, John Stultz, Pavel Emelyanov, Cyrill Gorcunov, andriy.shevchenko, Martin Runge, Andreas Brief On Thu, 20 Mar 2014, Andy Lutomirski wrote: > On Thu, Mar 20, 2014 at 5:30 AM, Thomas Gleixner <tglx@linutronix.de> wrote: > > On Thu, 20 Mar 2014, Stefani Seibold wrote: > >> 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? > > > > It's not just that. The x86_64 and x32 vdso page arrays are *far* > cleaner than the 32-bit variant. They manage to do the entire vdso > setup dance without any allocation at all. This avoids silly > questions about error handling and GFP_KERNEL :) > > See vdso/vdso.S for the rather small amount of magic needed. Is there any reason why we can't use that for x86_32 ? Thanks, tglx ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [PATCH] x86, vdso32: fix out of memory handling setup vDSO 2014-03-20 15:15 ` Thomas Gleixner @ 2014-03-20 15:18 ` Andy Lutomirski 2014-03-20 15:59 ` H. Peter Anvin 0 siblings, 1 reply; 13+ messages in thread From: Andy Lutomirski @ 2014-03-20 15:18 UTC (permalink / raw) To: Thomas Gleixner Cc: Stefani Seibold, Greg KH, linux-kernel, X86 ML, Ingo Molnar, H. Peter Anvin, Andi Kleen, Andrea Arcangeli, John Stultz, Pavel Emelyanov, Cyrill Gorcunov, Andy Shevchenko, Martin Runge, Andreas Brief On Thu, Mar 20, 2014 at 8:15 AM, Thomas Gleixner <tglx@linutronix.de> wrote: > On Thu, 20 Mar 2014, Andy Lutomirski wrote: >> On Thu, Mar 20, 2014 at 5:30 AM, Thomas Gleixner <tglx@linutronix.de> wrote: >> > On Thu, 20 Mar 2014, Stefani Seibold wrote: >> >> 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? >> > >> >> It's not just that. The x86_64 and x32 vdso page arrays are *far* >> cleaner than the 32-bit variant. They manage to do the entire vdso >> setup dance without any allocation at all. This avoids silly >> questions about error handling and GFP_KERNEL :) >> >> See vdso/vdso.S for the rather small amount of magic needed. > > Is there any reason why we can't use that for x86_32 ? > Not really. I'll play with it a bit. > Thanks, > > tglx -- Andy Lutomirski AMA Capital Management, LLC ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [PATCH] x86, vdso32: fix out of memory handling setup vDSO 2014-03-20 15:18 ` Andy Lutomirski @ 2014-03-20 15:59 ` H. Peter Anvin 2014-03-20 16:56 ` Andy Lutomirski 0 siblings, 1 reply; 13+ messages in thread From: H. Peter Anvin @ 2014-03-20 15:59 UTC (permalink / raw) To: Andy Lutomirski, Thomas Gleixner Cc: Stefani Seibold, Greg KH, linux-kernel, X86 ML, Ingo Molnar, Andi Kleen, Andrea Arcangeli, John Stultz, Pavel Emelyanov, Cyrill Gorcunov, Andy Shevchenko, Martin Runge, Andreas Brief On 03/20/2014 08:18 AM, Andy Lutomirski wrote: > > Not really. I'll play with it a bit. > That would be really nice. -hpa ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [PATCH] x86, vdso32: fix out of memory handling setup vDSO 2014-03-20 15:59 ` H. Peter Anvin @ 2014-03-20 16:56 ` Andy Lutomirski 2014-03-20 17:06 ` H. Peter Anvin 2014-03-20 22:01 ` [PATCH] x86: Load the 32-bit vdso in place, just like the 64-bit vdsos Andy Lutomirski 0 siblings, 2 replies; 13+ messages in thread From: Andy Lutomirski @ 2014-03-20 16:56 UTC (permalink / raw) To: H. Peter Anvin Cc: Thomas Gleixner, Stefani Seibold, Greg KH, linux-kernel, X86 ML, Ingo Molnar, Andi Kleen, Andrea Arcangeli, John Stultz, Pavel Emelyanov, Cyrill Gorcunov, Andy Shevchenko, Martin Runge, Andreas Brief On Thu, Mar 20, 2014 at 8:59 AM, H. Peter Anvin <hpa@zytor.com> wrote: > On 03/20/2014 08:18 AM, Andy Lutomirski wrote: >> >> Not really. I'll play with it a bit. >> > > That would be really nice. > Holy cow the 32-bit vdso code is a mess. I have a patch to clean up this bit of it, and I'll send it out once I've tested it a bit. --Andy > -hpa > > -- Andy Lutomirski AMA Capital Management, LLC ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [PATCH] x86, vdso32: fix out of memory handling setup vDSO 2014-03-20 16:56 ` Andy Lutomirski @ 2014-03-20 17:06 ` H. Peter Anvin 2014-03-20 22:01 ` [PATCH] x86: Load the 32-bit vdso in place, just like the 64-bit vdsos Andy Lutomirski 1 sibling, 0 replies; 13+ messages in thread From: H. Peter Anvin @ 2014-03-20 17:06 UTC (permalink / raw) To: Andy Lutomirski Cc: Thomas Gleixner, Stefani Seibold, Greg KH, linux-kernel, X86 ML, Ingo Molnar, Andi Kleen, Andrea Arcangeli, John Stultz, Pavel Emelyanov, Cyrill Gorcunov, Andy Shevchenko, Martin Runge, Andreas Brief On 03/20/2014 09:56 AM, Andy Lutomirski wrote: > > Holy cow the 32-bit vdso code is a mess. I have a patch to clean up > this bit of it, and I'll send it out once I've tested it a bit. > Thanks. -hpa ^ permalink raw reply [flat|nested] 13+ messages in thread
* [PATCH] x86: Load the 32-bit vdso in place, just like the 64-bit vdsos 2014-03-20 16:56 ` Andy Lutomirski 2014-03-20 17:06 ` H. Peter Anvin @ 2014-03-20 22:01 ` Andy Lutomirski 2014-03-20 22:30 ` [tip:x86/vdso] " tip-bot for Andy Lutomirski 1 sibling, 1 reply; 13+ messages in thread From: Andy Lutomirski @ 2014-03-20 22:01 UTC (permalink / raw) To: H. Peter Anvin, X86 ML Cc: Thomas Gleixner, Stefani Seibold, Greg KH, linux-kernel, Ingo Molnar, Andi Kleen, Andrea Arcangeli, John Stultz, Pavel Emelyanov, Cyrill Gorcunov, Andy Shevchenko, Martin Runge, Andreas Brief, Andy Lutomirski This replaces a decent amount of incomprehensible and buggy code with much more straightforward code. It also brings the 32-bit vdso more in line with the 64-bit vdsos, so maybe someday they can share even more code. This wastes a small amount of kernel .data and .text space, but it avoids a couple of allocations on startup, so it should be more or less a wash memory-wise. Signed-off-by: Andy Lutomirski <luto@amacapital.net> --- arch/x86/include/asm/vdso.h | 8 ------- arch/x86/vdso/vdso.S | 22 ++----------------- arch/x86/vdso/vdso32-setup.c | 50 +++++++++++++++++++++++++------------------- arch/x86/vdso/vdso32.S | 21 ++++--------------- arch/x86/vdso/vdso_image.h | 30 ++++++++++++++++++++++++++ arch/x86/vdso/vdsox32.S | 22 ++----------------- arch/x86/vdso/vma.c | 8 +++---- 7 files changed, 70 insertions(+), 91 deletions(-) create mode 100644 arch/x86/vdso/vdso_image.h diff --git a/arch/x86/include/asm/vdso.h b/arch/x86/include/asm/vdso.h index bde4359..0301d78 100644 --- a/arch/x86/include/asm/vdso.h +++ b/arch/x86/include/asm/vdso.h @@ -25,14 +25,6 @@ extern const char VDSO32_PRELINK[]; extern void __user __kernel_sigreturn; extern void __user __kernel_rt_sigreturn; -/* - * These symbols are defined by vdso32.S to mark the bounds - * of the ELF DSO images included therein. - */ -extern const char vdso32_int80_start, vdso32_int80_end; -extern const char vdso32_syscall_start, vdso32_syscall_end; -extern const char vdso32_sysenter_start, vdso32_sysenter_end; - void __init patch_vdso32(void *vdso, size_t len); #endif /* _ASM_X86_VDSO_H */ diff --git a/arch/x86/vdso/vdso.S b/arch/x86/vdso/vdso.S index 1e13eb8..c749d15 100644 --- a/arch/x86/vdso/vdso.S +++ b/arch/x86/vdso/vdso.S @@ -1,21 +1,3 @@ -#include <asm/page_types.h> -#include <linux/linkage.h> +#include "vdso_image.h" -__PAGE_ALIGNED_DATA - - .globl vdso_start, vdso_end - .align PAGE_SIZE -vdso_start: - .incbin "arch/x86/vdso/vdso.so" -vdso_end: - .align PAGE_SIZE /* extra data here leaks to userspace. */ - -.previous - - .globl vdso_pages - .bss - .align 8 - .type vdso_pages, @object -vdso_pages: - .zero (vdso_end - vdso_start + PAGE_SIZE - 1) / PAGE_SIZE * 8 - .size vdso_pages, .-vdso_pages +DEFINE_VDSO_IMAGE(vdso, "arch/x86/vdso/vdso.so") diff --git a/arch/x86/vdso/vdso32-setup.c b/arch/x86/vdso/vdso32-setup.c index 5b4aaef..b45528e 100644 --- a/arch/x86/vdso/vdso32-setup.c +++ b/arch/x86/vdso/vdso32-setup.c @@ -29,6 +29,7 @@ #include <asm/fixmap.h> #include <asm/hpet.h> #include <asm/vvar.h> +#include "vdso_image.h" #ifdef CONFIG_COMPAT_VDSO #define VDSO_DEFAULT 0 @@ -41,6 +42,12 @@ #define arch_setup_additional_pages syscall32_setup_pages #endif +DECLARE_VDSO_IMAGE(vdso32_int80); +#ifdef CONFIG_COMPAT +DECLARE_VDSO_IMAGE(vdso32_syscall); +#endif +DECLARE_VDSO_IMAGE(vdso32_sysenter); + /* * Should the kernel map a VDSO page into processes and pass its * address down to glibc upon exec()? @@ -71,7 +78,7 @@ EXPORT_SYMBOL_GPL(vdso_enabled); #endif static struct page **vdso32_pages; -static unsigned int vdso32_size; +static unsigned vdso32_size; #ifdef CONFIG_X86_64 @@ -117,31 +124,32 @@ void enable_sep_cpu(void) int __init sysenter_setup(void) { - void *vdso_pages; - const void *vdso; - size_t vdso_len; - unsigned int i; + char *vdso32_start, *vdso32_end; + int npages, i; +#ifdef CONFIG_COMPAT if (vdso32_syscall()) { - vdso = &vdso32_syscall_start; - vdso_len = &vdso32_syscall_end - &vdso32_syscall_start; - } else if (vdso32_sysenter()){ - vdso = &vdso32_sysenter_start; - vdso_len = &vdso32_sysenter_end - &vdso32_sysenter_start; + vdso32_start = vdso32_syscall_start; + vdso32_end = vdso32_syscall_end; + vdso32_pages = vdso32_syscall_pages; + } else +#endif + if (vdso32_sysenter()) { + vdso32_start = vdso32_sysenter_start; + vdso32_end = vdso32_sysenter_end; + vdso32_pages = vdso32_sysenter_pages; } else { - vdso = &vdso32_int80_start; - vdso_len = &vdso32_int80_end - &vdso32_int80_start; + vdso32_start = vdso32_int80_start; + vdso32_end = vdso32_int80_end; + vdso32_pages = vdso32_int80_pages; } - vdso32_size = (vdso_len + PAGE_SIZE - 1) / PAGE_SIZE; - vdso32_pages = kmalloc(sizeof(*vdso32_pages) * vdso32_size, GFP_ATOMIC); - vdso_pages = kmalloc(VDSO_OFFSET(vdso32_size), GFP_ATOMIC); - - for(i = 0; i != vdso32_size; ++i) - vdso32_pages[i] = virt_to_page(vdso_pages + VDSO_OFFSET(i)); + npages = ((vdso32_end - vdso32_start) + PAGE_SIZE - 1) / PAGE_SIZE; + vdso32_size = npages << PAGE_SHIFT; + for (i = 0; i < npages; i++) + vdso32_pages[i] = virt_to_page(vdso32_start + i*PAGE_SIZE); - memcpy(vdso_pages, vdso, vdso_len); - patch_vdso32(vdso_pages, vdso_len); + patch_vdso32(vdso32_start, vdso32_size); return 0; } @@ -177,7 +185,7 @@ int arch_setup_additional_pages(struct linux_binprm *bprm, int uses_interp) */ ret = install_special_mapping(mm, addr, - VDSO_OFFSET(vdso32_size), + vdso32_size, VM_READ|VM_EXEC| VM_MAYREAD|VM_MAYWRITE|VM_MAYEXEC, vdso32_pages); diff --git a/arch/x86/vdso/vdso32.S b/arch/x86/vdso/vdso32.S index 2ce5f82..cfa6add 100644 --- a/arch/x86/vdso/vdso32.S +++ b/arch/x86/vdso/vdso32.S @@ -1,22 +1,9 @@ -#include <linux/init.h> +#include "vdso_image.h" -__INITDATA +DEFINE_VDSO_IMAGE(vdso32_int80, "arch/x86/vdso/vdso32-int80.so") - .globl vdso32_int80_start, vdso32_int80_end -vdso32_int80_start: - .incbin "arch/x86/vdso/vdso32-int80.so" -vdso32_int80_end: - - .globl vdso32_syscall_start, vdso32_syscall_end -vdso32_syscall_start: #ifdef CONFIG_COMPAT - .incbin "arch/x86/vdso/vdso32-syscall.so" +DEFINE_VDSO_IMAGE(vdso32_syscall, "arch/x86/vdso/vdso32-syscall.so") #endif -vdso32_syscall_end: - - .globl vdso32_sysenter_start, vdso32_sysenter_end -vdso32_sysenter_start: - .incbin "arch/x86/vdso/vdso32-sysenter.so" -vdso32_sysenter_end: -__FINIT +DEFINE_VDSO_IMAGE(vdso32_sysenter, "arch/x86/vdso/vdso32-sysenter.so") diff --git a/arch/x86/vdso/vdso_image.h b/arch/x86/vdso/vdso_image.h new file mode 100644 index 0000000..1baa6bc --- /dev/null +++ b/arch/x86/vdso/vdso_image.h @@ -0,0 +1,30 @@ +#ifndef _VDSO_IMAGE_H +#define _VDSO_IMAGE_H + +#include <asm/page_types.h> +#include <linux/linkage.h> + +#define DEFINE_VDSO_IMAGE(symname, filename) \ +__PAGE_ALIGNED_DATA ; \ + .globl symname##_start, symname##_end ; \ + .align PAGE_SIZE ; \ + symname##_start: ; \ + .incbin filename ; \ + symname##_end: ; \ + .align PAGE_SIZE /* extra data here leaks to userspace. */ ; \ + \ +.previous ; \ + \ + .globl symname##_pages ; \ + .bss ; \ + .align 8 ; \ + .type symname##_pages, @object ; \ + symname##_pages: ; \ + .zero (symname##_end - symname##_start + PAGE_SIZE - 1) / PAGE_SIZE * (BITS_PER_LONG / 8) ; \ + .size symname##_pages, .-symname##_pages + +#define DECLARE_VDSO_IMAGE(symname) \ + extern char symname##_start[], symname##_end[]; \ + extern struct page *symname##_pages[] + +#endif /* _VDSO_IMAGE_H */ diff --git a/arch/x86/vdso/vdsox32.S b/arch/x86/vdso/vdsox32.S index 295f1c7..19a6927 100644 --- a/arch/x86/vdso/vdsox32.S +++ b/arch/x86/vdso/vdsox32.S @@ -1,21 +1,3 @@ -#include <asm/page_types.h> -#include <linux/linkage.h> +#include "vdso_image.h" -__PAGE_ALIGNED_DATA - - .globl vdsox32_start, vdsox32_end - .align PAGE_SIZE -vdsox32_start: - .incbin "arch/x86/vdso/vdsox32.so" -vdsox32_end: - .align PAGE_SIZE /* extra data here leaks to userspace. */ - -.previous - - .globl vdsox32_pages - .bss - .align 8 - .type vdsox32_pages, @object -vdsox32_pages: - .zero (vdsox32_end - vdsox32_start + PAGE_SIZE - 1) / PAGE_SIZE * 8 - .size vdsox32_pages, .-vdsox32_pages +DEFINE_VDSO_IMAGE(vdsox32, "arch/x86/vdso/vdsox32.so") diff --git a/arch/x86/vdso/vma.c b/arch/x86/vdso/vma.c index 7345bc9..6db0bbd 100644 --- a/arch/x86/vdso/vma.c +++ b/arch/x86/vdso/vma.c @@ -15,19 +15,17 @@ #include <asm/proto.h> #include <asm/vdso.h> #include <asm/page.h> +#include "vdso_image.h" #if defined(CONFIG_X86_64) unsigned int __read_mostly vdso_enabled = 1; -extern char vdso_start[], vdso_end[]; +DECLARE_VDSO_IMAGE(vdso); extern unsigned short vdso_sync_cpuid; - -extern struct page *vdso_pages[]; static unsigned vdso_size; #ifdef CONFIG_X86_X32_ABI -extern char vdsox32_start[], vdsox32_end[]; -extern struct page *vdsox32_pages[]; +DECLARE_VDSO_IMAGE(vdsox32); static unsigned vdsox32_size; #endif #endif -- 1.8.5.3 ^ permalink raw reply [flat|nested] 13+ messages in thread
* [tip:x86/vdso] x86: Load the 32-bit vdso in place, just like the 64-bit vdsos 2014-03-20 22:01 ` [PATCH] x86: Load the 32-bit vdso in place, just like the 64-bit vdsos Andy Lutomirski @ 2014-03-20 22:30 ` tip-bot for Andy Lutomirski 0 siblings, 0 replies; 13+ messages in thread From: tip-bot for Andy Lutomirski @ 2014-03-20 22:30 UTC (permalink / raw) To: linux-tip-commits; +Cc: linux-kernel, luto, hpa, mingo, stefani, tglx, hpa Commit-ID: b67e612cef1e5964efc6fa99fb7ad3d31c4db01a Gitweb: http://git.kernel.org/tip/b67e612cef1e5964efc6fa99fb7ad3d31c4db01a Author: Andy Lutomirski <luto@amacapital.net> AuthorDate: Thu, 20 Mar 2014 15:01:21 -0700 Committer: H. Peter Anvin <hpa@linux.intel.com> CommitDate: Thu, 20 Mar 2014 15:19:14 -0700 x86: Load the 32-bit vdso in place, just like the 64-bit vdsos This replaces a decent amount of incomprehensible and buggy code with much more straightforward code. It also brings the 32-bit vdso more in line with the 64-bit vdsos, so maybe someday they can share even more code. This wastes a small amount of kernel .data and .text space, but it avoids a couple of allocations on startup, so it should be more or less a wash memory-wise. Signed-off-by: Andy Lutomirski <luto@amacapital.net> Cc: Stefani Seibold <stefani@seibold.net> Link: http://lkml.kernel.org/r/b8093933fad09ce181edb08a61dcd5d2592e9814.1395352498.git.luto@amacapital.net Signed-off-by: H. Peter Anvin <hpa@linux.intel.com> --- arch/x86/include/asm/vdso.h | 8 ------- arch/x86/vdso/vdso.S | 22 ++----------------- arch/x86/vdso/vdso32-setup.c | 50 +++++++++++++++++++++++++------------------- arch/x86/vdso/vdso32.S | 21 ++++--------------- arch/x86/vdso/vdso_image.h | 30 ++++++++++++++++++++++++++ arch/x86/vdso/vdsox32.S | 22 ++----------------- arch/x86/vdso/vma.c | 8 +++---- 7 files changed, 70 insertions(+), 91 deletions(-) diff --git a/arch/x86/include/asm/vdso.h b/arch/x86/include/asm/vdso.h index bde4359..0301d78 100644 --- a/arch/x86/include/asm/vdso.h +++ b/arch/x86/include/asm/vdso.h @@ -25,14 +25,6 @@ extern const char VDSO32_PRELINK[]; extern void __user __kernel_sigreturn; extern void __user __kernel_rt_sigreturn; -/* - * These symbols are defined by vdso32.S to mark the bounds - * of the ELF DSO images included therein. - */ -extern const char vdso32_int80_start, vdso32_int80_end; -extern const char vdso32_syscall_start, vdso32_syscall_end; -extern const char vdso32_sysenter_start, vdso32_sysenter_end; - void __init patch_vdso32(void *vdso, size_t len); #endif /* _ASM_X86_VDSO_H */ diff --git a/arch/x86/vdso/vdso.S b/arch/x86/vdso/vdso.S index 1e13eb8..c749d15 100644 --- a/arch/x86/vdso/vdso.S +++ b/arch/x86/vdso/vdso.S @@ -1,21 +1,3 @@ -#include <asm/page_types.h> -#include <linux/linkage.h> +#include "vdso_image.h" -__PAGE_ALIGNED_DATA - - .globl vdso_start, vdso_end - .align PAGE_SIZE -vdso_start: - .incbin "arch/x86/vdso/vdso.so" -vdso_end: - .align PAGE_SIZE /* extra data here leaks to userspace. */ - -.previous - - .globl vdso_pages - .bss - .align 8 - .type vdso_pages, @object -vdso_pages: - .zero (vdso_end - vdso_start + PAGE_SIZE - 1) / PAGE_SIZE * 8 - .size vdso_pages, .-vdso_pages +DEFINE_VDSO_IMAGE(vdso, "arch/x86/vdso/vdso.so") diff --git a/arch/x86/vdso/vdso32-setup.c b/arch/x86/vdso/vdso32-setup.c index 5b4aaef..b45528e 100644 --- a/arch/x86/vdso/vdso32-setup.c +++ b/arch/x86/vdso/vdso32-setup.c @@ -29,6 +29,7 @@ #include <asm/fixmap.h> #include <asm/hpet.h> #include <asm/vvar.h> +#include "vdso_image.h" #ifdef CONFIG_COMPAT_VDSO #define VDSO_DEFAULT 0 @@ -41,6 +42,12 @@ #define arch_setup_additional_pages syscall32_setup_pages #endif +DECLARE_VDSO_IMAGE(vdso32_int80); +#ifdef CONFIG_COMPAT +DECLARE_VDSO_IMAGE(vdso32_syscall); +#endif +DECLARE_VDSO_IMAGE(vdso32_sysenter); + /* * Should the kernel map a VDSO page into processes and pass its * address down to glibc upon exec()? @@ -71,7 +78,7 @@ EXPORT_SYMBOL_GPL(vdso_enabled); #endif static struct page **vdso32_pages; -static unsigned int vdso32_size; +static unsigned vdso32_size; #ifdef CONFIG_X86_64 @@ -117,31 +124,32 @@ void enable_sep_cpu(void) int __init sysenter_setup(void) { - void *vdso_pages; - const void *vdso; - size_t vdso_len; - unsigned int i; + char *vdso32_start, *vdso32_end; + int npages, i; +#ifdef CONFIG_COMPAT if (vdso32_syscall()) { - vdso = &vdso32_syscall_start; - vdso_len = &vdso32_syscall_end - &vdso32_syscall_start; - } else if (vdso32_sysenter()){ - vdso = &vdso32_sysenter_start; - vdso_len = &vdso32_sysenter_end - &vdso32_sysenter_start; + vdso32_start = vdso32_syscall_start; + vdso32_end = vdso32_syscall_end; + vdso32_pages = vdso32_syscall_pages; + } else +#endif + if (vdso32_sysenter()) { + vdso32_start = vdso32_sysenter_start; + vdso32_end = vdso32_sysenter_end; + vdso32_pages = vdso32_sysenter_pages; } else { - vdso = &vdso32_int80_start; - vdso_len = &vdso32_int80_end - &vdso32_int80_start; + vdso32_start = vdso32_int80_start; + vdso32_end = vdso32_int80_end; + vdso32_pages = vdso32_int80_pages; } - vdso32_size = (vdso_len + PAGE_SIZE - 1) / PAGE_SIZE; - vdso32_pages = kmalloc(sizeof(*vdso32_pages) * vdso32_size, GFP_ATOMIC); - vdso_pages = kmalloc(VDSO_OFFSET(vdso32_size), GFP_ATOMIC); - - for(i = 0; i != vdso32_size; ++i) - vdso32_pages[i] = virt_to_page(vdso_pages + VDSO_OFFSET(i)); + npages = ((vdso32_end - vdso32_start) + PAGE_SIZE - 1) / PAGE_SIZE; + vdso32_size = npages << PAGE_SHIFT; + for (i = 0; i < npages; i++) + vdso32_pages[i] = virt_to_page(vdso32_start + i*PAGE_SIZE); - memcpy(vdso_pages, vdso, vdso_len); - patch_vdso32(vdso_pages, vdso_len); + patch_vdso32(vdso32_start, vdso32_size); return 0; } @@ -177,7 +185,7 @@ int arch_setup_additional_pages(struct linux_binprm *bprm, int uses_interp) */ ret = install_special_mapping(mm, addr, - VDSO_OFFSET(vdso32_size), + vdso32_size, VM_READ|VM_EXEC| VM_MAYREAD|VM_MAYWRITE|VM_MAYEXEC, vdso32_pages); diff --git a/arch/x86/vdso/vdso32.S b/arch/x86/vdso/vdso32.S index 2ce5f82..cfa6add 100644 --- a/arch/x86/vdso/vdso32.S +++ b/arch/x86/vdso/vdso32.S @@ -1,22 +1,9 @@ -#include <linux/init.h> +#include "vdso_image.h" -__INITDATA +DEFINE_VDSO_IMAGE(vdso32_int80, "arch/x86/vdso/vdso32-int80.so") - .globl vdso32_int80_start, vdso32_int80_end -vdso32_int80_start: - .incbin "arch/x86/vdso/vdso32-int80.so" -vdso32_int80_end: - - .globl vdso32_syscall_start, vdso32_syscall_end -vdso32_syscall_start: #ifdef CONFIG_COMPAT - .incbin "arch/x86/vdso/vdso32-syscall.so" +DEFINE_VDSO_IMAGE(vdso32_syscall, "arch/x86/vdso/vdso32-syscall.so") #endif -vdso32_syscall_end: - - .globl vdso32_sysenter_start, vdso32_sysenter_end -vdso32_sysenter_start: - .incbin "arch/x86/vdso/vdso32-sysenter.so" -vdso32_sysenter_end: -__FINIT +DEFINE_VDSO_IMAGE(vdso32_sysenter, "arch/x86/vdso/vdso32-sysenter.so") diff --git a/arch/x86/vdso/vdso_image.h b/arch/x86/vdso/vdso_image.h new file mode 100644 index 0000000..1baa6bc --- /dev/null +++ b/arch/x86/vdso/vdso_image.h @@ -0,0 +1,30 @@ +#ifndef _VDSO_IMAGE_H +#define _VDSO_IMAGE_H + +#include <asm/page_types.h> +#include <linux/linkage.h> + +#define DEFINE_VDSO_IMAGE(symname, filename) \ +__PAGE_ALIGNED_DATA ; \ + .globl symname##_start, symname##_end ; \ + .align PAGE_SIZE ; \ + symname##_start: ; \ + .incbin filename ; \ + symname##_end: ; \ + .align PAGE_SIZE /* extra data here leaks to userspace. */ ; \ + \ +.previous ; \ + \ + .globl symname##_pages ; \ + .bss ; \ + .align 8 ; \ + .type symname##_pages, @object ; \ + symname##_pages: ; \ + .zero (symname##_end - symname##_start + PAGE_SIZE - 1) / PAGE_SIZE * (BITS_PER_LONG / 8) ; \ + .size symname##_pages, .-symname##_pages + +#define DECLARE_VDSO_IMAGE(symname) \ + extern char symname##_start[], symname##_end[]; \ + extern struct page *symname##_pages[] + +#endif /* _VDSO_IMAGE_H */ diff --git a/arch/x86/vdso/vdsox32.S b/arch/x86/vdso/vdsox32.S index 295f1c7..19a6927 100644 --- a/arch/x86/vdso/vdsox32.S +++ b/arch/x86/vdso/vdsox32.S @@ -1,21 +1,3 @@ -#include <asm/page_types.h> -#include <linux/linkage.h> +#include "vdso_image.h" -__PAGE_ALIGNED_DATA - - .globl vdsox32_start, vdsox32_end - .align PAGE_SIZE -vdsox32_start: - .incbin "arch/x86/vdso/vdsox32.so" -vdsox32_end: - .align PAGE_SIZE /* extra data here leaks to userspace. */ - -.previous - - .globl vdsox32_pages - .bss - .align 8 - .type vdsox32_pages, @object -vdsox32_pages: - .zero (vdsox32_end - vdsox32_start + PAGE_SIZE - 1) / PAGE_SIZE * 8 - .size vdsox32_pages, .-vdsox32_pages +DEFINE_VDSO_IMAGE(vdsox32, "arch/x86/vdso/vdsox32.so") diff --git a/arch/x86/vdso/vma.c b/arch/x86/vdso/vma.c index 7345bc9..6db0bbd 100644 --- a/arch/x86/vdso/vma.c +++ b/arch/x86/vdso/vma.c @@ -15,19 +15,17 @@ #include <asm/proto.h> #include <asm/vdso.h> #include <asm/page.h> +#include "vdso_image.h" #if defined(CONFIG_X86_64) unsigned int __read_mostly vdso_enabled = 1; -extern char vdso_start[], vdso_end[]; +DECLARE_VDSO_IMAGE(vdso); extern unsigned short vdso_sync_cpuid; - -extern struct page *vdso_pages[]; static unsigned vdso_size; #ifdef CONFIG_X86_X32_ABI -extern char vdsox32_start[], vdsox32_end[]; -extern struct page *vdsox32_pages[]; +DECLARE_VDSO_IMAGE(vdsox32); static unsigned vdsox32_size; #endif #endif ^ permalink raw reply [flat|nested] 13+ messages in thread
end of thread, other threads:[~2014-03-20 22:31 UTC | newest] Thread overview: 13+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2014-03-20 7:45 [PATCH] x86, vdso32: fix out of memory handling setup vDSO Stefani Seibold 2014-03-20 9:53 ` Thomas Gleixner 2014-03-20 10:49 ` Thomas Gleixner 2014-03-20 11:38 ` Stefani Seibold 2014-03-20 12:30 ` Thomas Gleixner 2014-03-20 15:02 ` Andy Lutomirski 2014-03-20 15:15 ` Thomas Gleixner 2014-03-20 15:18 ` Andy Lutomirski 2014-03-20 15:59 ` H. Peter Anvin 2014-03-20 16:56 ` Andy Lutomirski 2014-03-20 17:06 ` H. Peter Anvin 2014-03-20 22:01 ` [PATCH] x86: Load the 32-bit vdso in place, just like the 64-bit vdsos Andy Lutomirski 2014-03-20 22:30 ` [tip:x86/vdso] " tip-bot for Andy Lutomirski
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox
Powered by JetHome