[PATCH 0/3] Improve 32 bit vDSO time

[PATCH 0/3] Improve 32 bit vDSO time

[Stefani Seibold]

This patch bring some improvments to the vDSO 32 bit:

- undef some kernel configs which increase the code size of the VDSO
- remove vsyscall and prevent wrong conditional VVAR_PAGE mapping
- handle VDSO larger than a page

The patch set is agains tip 7ed5ee279499a02bf35c77f0a91d657c24f6474e

[PATCH 1/3] x86, vdso32: undef CONFIG_OPTIMIZE_INLINING and CONFIG_X86_PPRO_FENCE

[Stefani Seibold]

In case of a 32 bit vDSO build the CONFIG_OPTIMIZE_INLINING and
CONFIG_X86_PPRO_FENCE options will increase the size of the generated
vDSO not to fit in a page.

A #undef of this config options will solve this.

Signed-off-by: Stefani Seibold <stefani@seibold.net>
---
 arch/x86/vdso/vdso32/vclock_gettime.c | 6 ++++++
 1 file changed, 6 insertions(+)

diff --git a/arch/x86/vdso/vdso32/vclock_gettime.c b/arch/x86/vdso/vdso32/vclock_gettime.c
index ab092f7..175cc72 100644
--- a/arch/x86/vdso/vdso32/vclock_gettime.c
+++ b/arch/x86/vdso/vdso32/vclock_gettime.c
@@ -1,5 +1,11 @@
 #define BUILD_VDSO32
 
+#ifndef CONFIG_CC_OPTIMIZE_FOR_SIZE
+#undef CONFIG_OPTIMIZE_INLINING
+#endif
+
+#undef CONFIG_X86_PPRO_FENCE
+
 #ifdef CONFIG_X86_64
 
 /*
-- 
1.9.0

[PATCH 2/3] x86, vdso32: remove vsyscall_32.c

[Stefani Seibold]

vsyscall_32.c has not much code in it and the only function map_vsyscall()
was invoked prior to vdso_setup() which results in wrong conditional
mapping of VVAR_PAGE.

Moving the whole fixmap initialization into map_compat_vdso() will
solve this calling dependences.

Signed-off-by: Stefani Seibold <stefani@seibold.net>
---
 arch/x86/kernel/Makefile      |  1 -
 arch/x86/kernel/hpet.c        |  6 ------
 arch/x86/kernel/setup.c       |  2 ++
 arch/x86/kernel/vsyscall_32.c | 24 ------------------------
 arch/x86/vdso/vdso32-setup.c  |  5 +++++
 5 files changed, 7 insertions(+), 31 deletions(-)
 delete mode 100644 arch/x86/kernel/vsyscall_32.c

diff --git a/arch/x86/kernel/Makefile b/arch/x86/kernel/Makefile
index 3282eda..f4d9600 100644
--- a/arch/x86/kernel/Makefile
+++ b/arch/x86/kernel/Makefile
@@ -27,7 +27,6 @@ obj-y			+= probe_roms.o
 obj-$(CONFIG_X86_32)	+= i386_ksyms_32.o
 obj-$(CONFIG_X86_64)	+= sys_x86_64.o x8664_ksyms_64.o
 obj-y			+= syscall_$(BITS).o vsyscall_gtod.o
-obj-$(CONFIG_X86_32)	+= vsyscall_32.o
 obj-$(CONFIG_X86_64)	+= vsyscall_64.o
 obj-$(CONFIG_X86_64)	+= vsyscall_emu_64.o
 obj-$(CONFIG_SYSFS)	+= ksysfs.o
diff --git a/arch/x86/kernel/hpet.c b/arch/x86/kernel/hpet.c
index b99544b..1129f79 100644
--- a/arch/x86/kernel/hpet.c
+++ b/arch/x86/kernel/hpet.c
@@ -12,7 +12,6 @@
 #include <linux/pm.h>
 #include <linux/io.h>
 
-#include <asm/fixmap.h>
 #include <asm/hpet.h>
 #include <asm/time.h>
 #include <asm/elf.h>
@@ -75,11 +74,6 @@ static inline void hpet_writel(unsigned int d, unsigned int a)
 static inline void hpet_set_mapping(void)
 {
 	hpet_virt_address = ioremap_nocache(hpet_address, HPET_MMAP_SIZE);
-#ifdef CONFIG_X86_32
-	if (vdso_enabled != VDSO_COMPAT)
-		return;
-#endif
-	__set_fixmap(VSYSCALL_HPET, hpet_address, PAGE_KERNEL_VVAR_NOCACHE);
 }
 
 static inline void hpet_clear_mapping(void)
diff --git a/arch/x86/kernel/setup.c b/arch/x86/kernel/setup.c
index 56ff330..ebf1c00 100644
--- a/arch/x86/kernel/setup.c
+++ b/arch/x86/kernel/setup.c
@@ -1182,7 +1182,9 @@ void __init setup_arch(char **cmdline_p)
 
 	tboot_probe();
 
+#ifndef CONFIG_X86_32
 	map_vsyscall();
+#endif
 
 	generic_apic_probe();
 
diff --git a/arch/x86/kernel/vsyscall_32.c b/arch/x86/kernel/vsyscall_32.c
deleted file mode 100644
index 0cbf94b..0000000
--- a/arch/x86/kernel/vsyscall_32.c
+++ /dev/null
@@ -1,24 +0,0 @@
-/*
- *  Copyright (C) 2001 Andrea Arcangeli <andrea@suse.de> SuSE
- *  Copyright 2003 Andi Kleen, SuSE Labs.
- *
- *  Modified for x86 32 bit arch by Stefani Seibold <stefani@seibold.net>
- *
- *  Thanks to hpa@transmeta.com for some useful hint.
- *  Special thanks to Ingo Molnar for his early experience with
- *  a different vsyscall implementation for Linux/IA32 and for the name.
- *
- */
-
-#include <asm/vsyscall.h>
-#include <asm/pgtable.h>
-#include <asm/fixmap.h>
-#include <asm/elf.h>
-
-void __init map_vsyscall(void)
-{
-	if (vdso_enabled != VDSO_COMPAT)
-		return;
-
-	__set_fixmap(VVAR_PAGE, __pa_symbol(&__vvar_page), PAGE_KERNEL_VVAR);
-}
diff --git a/arch/x86/vdso/vdso32-setup.c b/arch/x86/vdso/vdso32-setup.c
index b37aa1d..1a9f8c3 100644
--- a/arch/x86/vdso/vdso32-setup.c
+++ b/arch/x86/vdso/vdso32-setup.c
@@ -262,6 +262,11 @@ static void map_compat_vdso(int map)
 
 	vdso_mapped = map;
 
+	if (hpet_address)
+		__set_fixmap(VSYSCALL_HPET, hpet_address, PAGE_KERNEL_VVAR_NOCACHE);
+
+	__set_fixmap(VVAR_PAGE, __pa_symbol(&__vvar_page), PAGE_KERNEL_VVAR);
+
 	__set_fixmap(FIX_VDSO, page_to_pfn(vdso32_pages[0]) << PAGE_SHIFT,
 		     map ? PAGE_READONLY_EXEC : PAGE_NONE);
 
-- 
1.9.0

[PATCH 3/3] x86, vdso32: handle 32 bit vDSO larger one page

[Stefani Seibold]

This patch enables 32 bit vDSO which are larger than a page. Currently
two pages are reserved, this should be enough for future improvements.

Signed-off-by: Stefani Seibold <stefani@seibold.net>
---
 arch/x86/include/asm/fixmap.h |  4 +++-
 arch/x86/vdso/vdso32-setup.c  | 29 +++++++++++++++++++----------
 2 files changed, 22 insertions(+), 11 deletions(-)

diff --git a/arch/x86/include/asm/fixmap.h b/arch/x86/include/asm/fixmap.h
index 094d0cc..f513f14 100644
--- a/arch/x86/include/asm/fixmap.h
+++ b/arch/x86/include/asm/fixmap.h
@@ -43,6 +43,8 @@ extern unsigned long __FIXADDR_TOP;
 
 #define FIXADDR_USER_START     __fix_to_virt(FIX_VDSO)
 #define FIXADDR_USER_END       __fix_to_virt(FIX_VDSO - 1)
+
+#define MAX_VDSO_PAGES	2
 #else
 #define FIXADDR_TOP	(VSYSCALL_END-PAGE_SIZE)
 
@@ -74,7 +76,7 @@ extern unsigned long __FIXADDR_TOP;
 enum fixed_addresses {
 #ifdef CONFIG_X86_32
 	FIX_HOLE,
-	FIX_VDSO,
+	FIX_VDSO = MAX_VDSO_PAGES,
 	VVAR_PAGE,
 	VSYSCALL_HPET,
 #else
diff --git a/arch/x86/vdso/vdso32-setup.c b/arch/x86/vdso/vdso32-setup.c
index 1a9f8c3..aa785f0 100644
--- a/arch/x86/vdso/vdso32-setup.c
+++ b/arch/x86/vdso/vdso32-setup.c
@@ -16,6 +16,7 @@
 #include <linux/mm.h>
 #include <linux/err.h>
 #include <linux/module.h>
+#include <linux/slab.h>
 
 #include <asm/cpufeature.h>
 #include <asm/msr.h>
@@ -190,7 +191,8 @@ static __init void relocate_vdso(Elf32_Ehdr *ehdr)
 	}
 }
 
-static struct page *vdso32_pages[VDSO_PAGES];
+static struct page *vdso32_pages[MAX_VDSO_PAGES];
+static unsigned int vdso32_size;
 
 #ifdef CONFIG_X86_64
 
@@ -256,6 +258,7 @@ static int __init gate_vma_init(void)
 static void map_compat_vdso(int map)
 {
 	static int vdso_mapped;
+	unsigned int i;
 
 	if (map == vdso_mapped)
 		return;
@@ -267,7 +270,8 @@ static void map_compat_vdso(int map)
 
 	__set_fixmap(VVAR_PAGE, __pa_symbol(&__vvar_page), PAGE_KERNEL_VVAR);
 
-	__set_fixmap(FIX_VDSO, page_to_pfn(vdso32_pages[0]) << PAGE_SHIFT,
+	for(i = 0; i != vdso32_size; ++i)
+		__set_fixmap(FIX_VDSO, page_to_pfn(vdso32_pages[i]) << PAGE_SHIFT,
 		     map ? PAGE_READONLY_EXEC : PAGE_NONE);
 
 	/* flush stray tlbs */
@@ -278,11 +282,10 @@ static void map_compat_vdso(int map)
 
 int __init sysenter_setup(void)
 {
-	void *vdso_page = (void *)get_zeroed_page(GFP_ATOMIC);
+	void *vdso_pages;
 	const void *vdso;
 	size_t vdso_len;
-
-	vdso32_pages[0] = virt_to_page(vdso_page);
+	unsigned int i;
 
 #ifdef CONFIG_X86_32
 	gate_vma_init();
@@ -299,9 +302,15 @@ int __init sysenter_setup(void)
 		vdso_len = &vdso32_int80_end - &vdso32_int80_start;
 	}
 
-	memcpy(vdso_page, vdso, vdso_len);
-	patch_vdso32(vdso_page, vdso_len);
-	relocate_vdso(vdso_page);
+	vdso32_size = (vdso_len + PAGE_SIZE - 1) / PAGE_SIZE;
+	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));
+
+	memcpy(vdso_pages, vdso, vdso_len);
+	patch_vdso32(vdso_pages, vdso_len);
+	relocate_vdso(vdso_pages);
 
 	return 0;
 }
@@ -334,7 +343,7 @@ int arch_setup_additional_pages(struct linux_binprm *bprm, int uses_interp)
 	if (compat)
 		addr = VDSO_HIGH_BASE;
 	else {
-		addr = get_unmapped_area(NULL, 0, VDSO_OFFSET(VDSO_PAGES), 0, 0);
+		addr = get_unmapped_area(NULL, 0, VDSO_OFFSET(VDSO_PREV_PAGES + vdso32_size), 0, 0);
 		if (IS_ERR_VALUE(addr)) {
 			ret = addr;
 			goto up_fail;
@@ -351,7 +360,7 @@ int arch_setup_additional_pages(struct linux_binprm *bprm, int uses_interp)
 		 */
 		ret = install_special_mapping(mm,
 				addr,
-				VDSO_OFFSET(VDSO_PAGES - VDSO_PREV_PAGES),
+				VDSO_OFFSET(vdso32_size),
 				VM_READ|VM_EXEC|
 				VM_MAYREAD|VM_MAYWRITE|VM_MAYEXEC,
 				vdso32_pages);
-- 
1.9.0

Re: [PATCH 0/3] Improve 32 bit vDSO time

[Andy Lutomirski]

Since no one seems to object to the latest patch I sent out, wouldn't
it make more sense to base this on top of my patch?

--Andy

On Wed, Mar 12, 2014 at 3:51 PM, Stefani Seibold <stefani@seibold.net> wrote:
> This patch bring some improvments to the vDSO 32 bit:
>
> - undef some kernel configs which increase the code size of the VDSO
> - remove vsyscall and prevent wrong conditional VVAR_PAGE mapping
> - handle VDSO larger than a page
>
> The patch set is agains tip 7ed5ee279499a02bf35c77f0a91d657c24f6474e



-- 
Andy Lutomirski
AMA Capital Management, LLC

Re: [PATCH 3/3] x86, vdso32: handle 32 bit vDSO larger one page

[H. Peter Anvin]

On 03/12/2014 03:51 PM, Stefani Seibold wrote:
> This patch enables 32 bit vDSO which are larger than a page. Currently
> two pages are reserved, this should be enough for future improvements.
> 
> Signed-off-by: Stefani Seibold <stefani@seibold.net>
> ---
>  arch/x86/include/asm/fixmap.h |  4 +++-
>  arch/x86/vdso/vdso32-setup.c  | 29 +++++++++++++++++++----------
>  2 files changed, 22 insertions(+), 11 deletions(-)
> 
> diff --git a/arch/x86/include/asm/fixmap.h b/arch/x86/include/asm/fixmap.h
> index 094d0cc..f513f14 100644
> --- a/arch/x86/include/asm/fixmap.h
> +++ b/arch/x86/include/asm/fixmap.h
> @@ -43,6 +43,8 @@ extern unsigned long __FIXADDR_TOP;
>  
>  #define FIXADDR_USER_START     __fix_to_virt(FIX_VDSO)
>  #define FIXADDR_USER_END       __fix_to_virt(FIX_VDSO - 1)
> +
> +#define MAX_VDSO_PAGES	2
>  #else
>  #define FIXADDR_TOP	(VSYSCALL_END-PAGE_SIZE)
>  
> @@ -74,7 +76,7 @@ extern unsigned long __FIXADDR_TOP;
>  enum fixed_addresses {
>  #ifdef CONFIG_X86_32
>  	FIX_HOLE,
> -	FIX_VDSO,
> +	FIX_VDSO = MAX_VDSO_PAGES,
>  	VVAR_PAGE,
>  	VSYSCALL_HPET,

Can we make this FIX_HOLE + MAX_VDSO_PAGES or at least a comment
explaning the constraint here... otherwise I fear random breakage.

> +	for(i = 0; i != vdso32_size; ++i)
> +		vdso32_pages[i] = virt_to_page(vdso_pages + VDSO_OFFSET(i));

Stylistic note:

	for (i = 0; i < vdso32_size; i++)

Otherwise it really seems simple enough.

Re: [PATCH 3/3] x86, vdso32: handle 32 bit vDSO larger one page

[Andy Lutomirski]

On Wed, Mar 12, 2014 at 3:58 PM, H. Peter Anvin <hpa@zytor.com> wrote:
> On 03/12/2014 03:51 PM, Stefani Seibold wrote:
>> This patch enables 32 bit vDSO which are larger than a page. Currently
>> two pages are reserved, this should be enough for future improvements.
>>
>> Signed-off-by: Stefani Seibold <stefani@seibold.net>
>> ---
>>  arch/x86/include/asm/fixmap.h |  4 +++-
>>  arch/x86/vdso/vdso32-setup.c  | 29 +++++++++++++++++++----------
>>  2 files changed, 22 insertions(+), 11 deletions(-)
>>
>> diff --git a/arch/x86/include/asm/fixmap.h b/arch/x86/include/asm/fixmap.h
>> index 094d0cc..f513f14 100644
>> --- a/arch/x86/include/asm/fixmap.h
>> +++ b/arch/x86/include/asm/fixmap.h
>> @@ -43,6 +43,8 @@ extern unsigned long __FIXADDR_TOP;
>>
>>  #define FIXADDR_USER_START     __fix_to_virt(FIX_VDSO)
>>  #define FIXADDR_USER_END       __fix_to_virt(FIX_VDSO - 1)
>> +
>> +#define MAX_VDSO_PAGES       2
>>  #else
>>  #define FIXADDR_TOP  (VSYSCALL_END-PAGE_SIZE)
>>
>> @@ -74,7 +76,7 @@ extern unsigned long __FIXADDR_TOP;
>>  enum fixed_addresses {
>>  #ifdef CONFIG_X86_32
>>       FIX_HOLE,
>> -     FIX_VDSO,
>> +     FIX_VDSO = MAX_VDSO_PAGES,
>>       VVAR_PAGE,
>>       VSYSCALL_HPET,
>
> Can we make this FIX_HOLE + MAX_VDSO_PAGES or at least a comment
> explaning the constraint here... otherwise I fear random breakage.

Note that this code is completely unnecessary if either of my patch
sets is accepted.  Since you're the maintainer, can you give an
opinion? :)

--Andy

Re: [PATCH 0/3] Improve 32 bit vDSO time

[stefani]

Zitat von Andy Lutomirski <luto@amacapital.net>:

> Since no one seems to object to the latest patch I sent out, wouldn't
> it make more sense to base this on top of my patch?
>

I will do this when your patch is pulled into tip. For now we have the choice,
but i preferer our solution removing the compat vdso.

- Stefani

Re: [PATCH 0/3] Improve 32 bit vDSO time

[H. Peter Anvin]

On 03/12/2014 04:11 PM, stefani@seibold.net wrote:
> 
> I will do this when your patch is pulled into tip. For now we have the
> choice, but i preferer our solution removing the compat vdso.
> 

Sorry, that didn't parse from me.

Also, if you state a preference, could you please motivate it?

	-hpa

Re: [PATCH 0/3] Improve 32 bit vDSO time

[Stefani Seibold]

Am Mittwoch, den 12.03.2014, 20:48 -0700 schrieb H. Peter Anvin:
> On 03/12/2014 04:11 PM, stefani@seibold.net wrote:
> > 
> > I will do this when your patch is pulled into tip. For now we have the
> > choice, but i preferer our solution removing the compat vdso.
> > 
> 
> Sorry, that didn't parse from me.

I thought it is a good idea to wait until the "remove compat vdso
support" is settled and pulled into tip.

If there is no objections against this patch i am happy to do the
job ;-)

BTW: Thanks to Andy for doing this job to git rid off this ugly compat
vDSO layer.

> Also, if you state a preference, could you please motivate it?

For the next three days i am very busy with a important project, so i
will rebase the vdso 32 bit time patch on Monday or Tuesday. 

- Stefani

Re: [PATCH 3/3] x86, vdso32: handle 32 bit vDSO larger one page

[H. Peter Anvin]

On 03/12/2014 03:59 PM, Andy Lutomirski wrote:
> 
> Note that this code is completely unnecessary if either of my patch
> sets is accepted.  Since you're the maintainer, can you give an
> opinion? :)
> 

I'm trying to unwind all the patches going around, Linus' feedback and
so on, and figure out what this means in concrete terms especially in
the light of the 3.15 merge window coming up.

I tried to apply your patchset "[PATCH v2 0/2] x86: Relocate the compat
vdso per process" on top of tip:x86/vdso, but it conflicts pretty hard
-- I guess you are using a different baseline, but that makes it
complicated to deal with.

Otherwise, it seems the logical way forward.  Could you and/or Stefani
work out the conflicts between the patchsets?

In the meantime I'm going to apply Stefani's first patch.

	-hpa

Re: [PATCH 3/3] x86, vdso32: handle 32 bit vDSO larger one page

[Andy Lutomirski]

On Thu, Mar 13, 2014 at 8:53 AM, H. Peter Anvin <hpa@zytor.com> wrote:
> On 03/12/2014 03:59 PM, Andy Lutomirski wrote:
>>
>> Note that this code is completely unnecessary if either of my patch
>> sets is accepted.  Since you're the maintainer, can you give an
>> opinion? :)
>>
>
> I'm trying to unwind all the patches going around, Linus' feedback and
> so on, and figure out what this means in concrete terms especially in
> the light of the 3.15 merge window coming up.
>
> I tried to apply your patchset "[PATCH v2 0/2] x86: Relocate the compat
> vdso per process" on top of tip:x86/vdso, but it conflicts pretty hard
> -- I guess you are using a different baseline, but that makes it
> complicated to deal with.

It applies to -linus.  I think that we should resolve the compat
issues first and then add timing code on top, since a decent chunk of
Stefani's changes will be unnecessary once the compat vdso is either
gone or unified with the non-compat vdso.

Does this mean you prefer the relocation approach to the compat vdso
removal approach?  It seems like Linus is okay with either one.

--Andy

>
> Otherwise, it seems the logical way forward.  Could you and/or Stefani
> work out the conflicts between the patchsets?
>
> In the meantime I'm going to apply Stefani's first patch.
>
>         -hpa
>



-- 
Andy Lutomirski
AMA Capital Management, LLC

Re: [PATCH 3/3] x86, vdso32: handle 32 bit vDSO larger one page

[H. Peter Anvin]

On 03/13/2014 10:28 AM, Andy Lutomirski wrote:
> 
> Does this mean you prefer the relocation approach to the compat vdso
> removal approach?  It seems like Linus is okay with either one.
> 

Actually, thinking about it, removing it is probably better:

a) gets rid of legacy code, making room for unification;
b) either way enabling compat support (either relocation or disabling
   the vdso) has a performance penalty for *all* processes.

The only way to avoid that is to have a vdso at a fixed addresses across
all processes, either in the fixmap or in the user area (presumably at
the very top.)

	-hpa

Re: [PATCH 3/3] x86, vdso32: handle 32 bit vDSO larger one page

[H. Peter Anvin]

On 03/13/2014 11:08 AM, H. Peter Anvin wrote:
> On 03/13/2014 10:28 AM, Andy Lutomirski wrote:
>>
>> Does this mean you prefer the relocation approach to the compat vdso
>> removal approach?  It seems like Linus is okay with either one.
>>
> 
> Actually, thinking about it, removing it is probably better:
> 
> a) gets rid of legacy code, making room for unification;
> b) either way enabling compat support (either relocation or disabling
>    the vdso) has a performance penalty for *all* processes.
> 
> The only way to avoid that is to have a vdso at a fixed addresses across
> all processes, either in the fixmap or in the user area (presumably at
> the very top.)
> 

So going back and re-reading all the threads, the consensus was to
remove the compat vdso, but recycling the CONFIG_COMPAT_VDSO
configuration option name for the default-disable option.

It is important that anyone who actually cares about performance unsets
the option.

	-hpa

Re: [PATCH 3/3] x86, vdso32: handle 32 bit vDSO larger one page

[Andy Lutomirski]

On Thu, Mar 13, 2014 at 11:21 AM, H. Peter Anvin <hpa@zytor.com> wrote:
> On 03/13/2014 11:08 AM, H. Peter Anvin wrote:
>> On 03/13/2014 10:28 AM, Andy Lutomirski wrote:
>>>
>>> Does this mean you prefer the relocation approach to the compat vdso
>>> removal approach?  It seems like Linus is okay with either one.
>>>
>>
>> Actually, thinking about it, removing it is probably better:
>>
>> a) gets rid of legacy code, making room for unification;
>> b) either way enabling compat support (either relocation or disabling
>>    the vdso) has a performance penalty for *all* processes.
>>
>> The only way to avoid that is to have a vdso at a fixed addresses across
>> all processes, either in the fixmap or in the user area (presumably at
>> the very top.)
>>
>
> So going back and re-reading all the threads, the consensus was to
> remove the compat vdso, but recycling the CONFIG_COMPAT_VDSO
> configuration option name for the default-disable option.
>

I don't recall anyone suggesting keeping the name.  CONFIG_COMPAT_VDSO
will henceforth be a silly name, since the "compat" mode won't have a
vdso.

The consensus was that the default should be no vdso, right?  My most
recent patchset calls it CONFIG_ENABLE_VDSO32_BY_DEFAULT and defaults
to n.

--Andy

> It is important that anyone who actually cares about performance unsets
> the option.

Should there be a warning at startup if the option is set?

--Andy

Re: [PATCH 3/3] x86, vdso32: handle 32 bit vDSO larger one page

[H. Peter Anvin]

On 03/13/2014 11:32 AM, Andy Lutomirski wrote:
> 
> I don't recall anyone suggesting keeping the name.  CONFIG_COMPAT_VDSO
> will henceforth be a silly name, since the "compat" mode won't have a
> vdso.
> 

Linus suggested it:
> What might be acceptable then is to just keep the old config name, and
> if the COMPAT_VDSO config is enabled, you just disable the non-compat
> vdso. At least that way, presumably any opensuse people would have
> their kernel config continue working.

	...

> The consensus was that the default should be no vdso, right?  My most
> recent patchset calls it CONFIG_ENABLE_VDSO32_BY_DEFAULT and defaults
> to n.

On any practical system, the vdso needs to be turned on -- the syscall
performance difference is very significant.

>> It is important that anyone who actually cares about performance unsets
>> the option.
> 
> Should there be a warning at startup if the option is set?

Possibly.  Not sure if anyone will read it.

	-hpa

Re: [PATCH 3/3] x86, vdso32: handle 32 bit vDSO larger one page

[Andy Lutomirski]

On Thu, Mar 13, 2014 at 12:06 PM, Linus Torvalds
<torvalds@linux-foundation.org> wrote:
> On my phone, so the lists will reject this, and sorry for top posting.
>
> Maybe we could do something similar to the vsyscall=native thing, where the
> compat vdso just does the system calls, but at least uses syscall rather
> than int80 when appropriate? Make the suse situation not suck horribly...

How?  We either set null in AT_SYSINFO_EHDR, we set something simple
that SuSE is okay with (and compile separate images?) or we set
something fancy and not relocated, and SuSE crashes.

At least for the 64-bit vsyscall case, modern code is polite enough to
completely ignore the vsyscall page.  Unfortunately, modern 32-bit
glibc looks at the exact same AT_SYSINFO_EHDR.

If the syscall overhead is that bad, the dynamic relocation approach
might be better...

On a related note: is it okay to keep the option called
CONFIG_COMPAT_VDSO but change the default to n?  The assumption is
that everyone with OpenSUSE already has a working config, but new
defconfig users will get the better choice?

--Andy

Re: [PATCH 3/3] x86, vdso32: handle 32 bit vDSO larger one page

[H. Peter Anvin]

If we have to stick anything in the fixmap it might add well be the real vdso...

On March 13, 2014 12:21:54 PM PDT, Linus Torvalds <torvalds@linux-foundation.org> wrote:
>On Mar 13, 2014 12:13 PM, "Andy Lutomirski" <luto@amacapital.net>
>wrote:
>>
>> How?  We either set null in AT_SYSINFO_EHDR, we set something simple
>> that SuSE is okay with (and compile separate images?) or we set
>> something fancy and not relocated, and SuSE crashes.
>
>Yeah, I was thinking that "something simple is the fixmap space that
>suse
>would be happy with"
>
>Keyword being "simple", ie so simple that it's not a maintenance
>headache
>even if it's different from the "real" vdso.
>
>But I suspect we don't really need it.
>
>> On a related note: is it okay to keep the option called
>> CONFIG_COMPAT_VDSO but change the default to n?
>
>Yes. If you start from scratch with a config, you have to get the
>options
>right. It's just the "I upgraded the kernel, did an oldconfig, and it
>doesn't work" case that we should avoid.
>
>The alternative would be to make a new config name, but then it has to
>default to the compatible state (iow no vdso at all by default),
>because
>that's the rule: make oldconfig should work for people.
>
>Basically, kernel upgrades should be nobrainers and "just work".
>
>     Linus

-- 
Sent from my mobile phone.  Please pardon brevity and lack of formatting.

Re: [PATCH 3/3] x86, vdso32: handle 32 bit vDSO larger one page

[Andy Lutomirski]

On Thu, Mar 13, 2014 at 12:21 PM, Linus Torvalds
<torvalds@linux-foundation.org> wrote:
>
> On Mar 13, 2014 12:13 PM, "Andy Lutomirski" <luto@amacapital.net> wrote:
>>
>> How?  We either set null in AT_SYSINFO_EHDR, we set something simple
>> that SuSE is okay with (and compile separate images?) or we set
>> something fancy and not relocated, and SuSE crashes.
>
> Yeah, I was thinking that "something simple is the fixmap space that suse
> would be happy with"
>
> Keyword being "simple", ie so simple that it's not a maintenance headache
> even if it's different from the "real" vdso.
>
> But I suspect we don't really need it.

I agree.  Also, the syscall instruction selection is currently rather
complicated, and I don't think it can ever be *that* simple :(

>
>> On a related note: is it okay to keep the option called
>> CONFIG_COMPAT_VDSO but change the default to n?
>
> Yes. If you start from scratch with a config, you have to get the options
> right. It's just the "I upgraded the kernel, did an oldconfig, and it
> doesn't work" case that we should avoid.
>
> The alternative would be to make a new config name, but then it has to
> default to the compatible state (iow no vdso at all by default), because
> that's the rule: make oldconfig should work for people.
>
> Basically, kernel upgrades should be nobrainers and "just work".

OK.  I'll send out new patches.

--Andy

Re: [PATCH 3/3] x86, vdso32: handle 32 bit vDSO larger one page

[H. Peter Anvin]

On 03/13/2014 12:37 PM, Linus Torvalds wrote:
> There are big advantages to "minimal code" at fixed addresses. The
> vdso=native thing fills the page with 0xcc just to not give useful
> instructions (still on my phone, so that may be a bogus memory)
> 
> That said, I doubt we care just for OpenSUSE 9. Let it be slower.

Yes.

	-hpa

Re: [PATCH 3/3] x86, vdso32: handle 32 bit vDSO larger one page

[Andi Kleen]

On Thu, Mar 13, 2014 at 12:58:35PM -0700, H. Peter Anvin wrote:
> On 03/13/2014 12:37 PM, Linus Torvalds wrote:
> > There are big advantages to "minimal code" at fixed addresses. The
> > vdso=native thing fills the page with 0xcc just to not give useful
> > instructions (still on my phone, so that may be a bogus memory)
> > 
> > That said, I doubt we care just for OpenSUSE 9. Let it be slower.
> 
> Yes.

At some point the majority of my nfsroot test image were OpenSUSE 9.
It was the last opensuse system that booted fast without udev or initrd :-)

I have mostly retired them by now, but still occasional usage.

So that why i would prefer to not cripple it.

-Andi

Re: [PATCH 3/3] x86, vdso32: handle 32 bit vDSO larger one page

[H. Peter Anvin]

On 03/13/2014 02:00 PM, Andi Kleen wrote:
> 
> At some point the majority of my nfsroot test image were OpenSUSE 9.
> It was the last opensuse system that booted fast without udev or initrd :-)
> 
> I have mostly retired them by now, but still occasional usage.
> 
> So that why i would prefer to not cripple it.
> 

It is already crippled in the sense that you can't boot without
CONFIG_COMPAT_VDSO... so in that sense nothing has really changed.

	-hpa

Re: [PATCH 3/3] x86, vdso32: handle 32 bit vDSO larger one page

[Andi Kleen]

On Thu, Mar 13, 2014 at 02:04:56PM -0700, H. Peter Anvin wrote:
> On 03/13/2014 02:00 PM, Andi Kleen wrote:
> > 
> > At some point the majority of my nfsroot test image were OpenSUSE 9.
> > It was the last opensuse system that booted fast without udev or initrd :-)
> > 
> > I have mostly retired them by now, but still occasional usage.
> > 
> > So that why i would prefer to not cripple it.
> > 
> 
> It is already crippled in the sense that you can't boot without
> CONFIG_COMPAT_VDSO... so in that sense nothing has really changed.

And?  I always set that option of course.

Doesn't cripple it in any way.

Forcing it to int 0x80 does however.

-Andi

Re: [PATCH 3/3] x86, vdso32: handle 32 bit vDSO larger one page

[Linus Torvalds]

On Thu, Mar 13, 2014 at 2:10 PM, Andi Kleen <ak@linux.intel.com> wrote:
>
> Doesn't cripple it in any way.
>
> Forcing it to int 0x80 does however.

No it doesn't.

It runs fine. No crippling.

If you are silly enough to run a eight-year-old distribution, and then
upgrade just the kernel, you'll run a bit slower. So what?

We care about it *working*. We don't care about optimal performance of
an old distribution. People can upgrade if they want.

              Linus

Re: [PATCH 0/3] Improve 32 bit vDSO time

[H. Peter Anvin]

On 03/13/2014 01:11 AM, Stefani Seibold wrote:
> Am Mittwoch, den 12.03.2014, 20:48 -0700 schrieb H. Peter Anvin:
>> On 03/12/2014 04:11 PM, stefani@seibold.net wrote:
>>>
>>> I will do this when your patch is pulled into tip. For now we have the
>>> choice, but i preferer our solution removing the compat vdso.
>>>
>>
>> Sorry, that didn't parse from me.
> 
> I thought it is a good idea to wait until the "remove compat vdso
> support" is settled and pulled into tip.
> 
> If there is no objections against this patch i am happy to do the
> job ;-)
> 
> BTW: Thanks to Andy for doing this job to git rid off this ugly compat
> vDSO layer.
> 
>> Also, if you state a preference, could you please motivate it?
> 
> For the next three days i am very busy with a important project, so i
> will rebase the vdso 32 bit time patch on Monday or Tuesday. 
> 

So when I get the updated patch from Andy I will pull it into tip,
resetting the x86/vdso branch.  I'll then expect an upgraded and
simplified patchset from you to put on top.

Sounds like a plan.

	-hpa

Re: [PATCH 0/3] Improve 32 bit vDSO time

[Stefani Seibold]

Am Donnerstag, den 13.03.2014, 15:08 -0700 schrieb H. Peter Anvin:
> On 03/13/2014 01:11 AM, Stefani Seibold wrote:
> > Am Mittwoch, den 12.03.2014, 20:48 -0700 schrieb H. Peter Anvin:
> >> On 03/12/2014 04:11 PM, stefani@seibold.net wrote:
> >>>
> >>> I will do this when your patch is pulled into tip. For now we have the
> >>> choice, but i preferer our solution removing the compat vdso.
> >>>
> >>
> >> Sorry, that didn't parse from me.
> > 
> > I thought it is a good idea to wait until the "remove compat vdso
> > support" is settled and pulled into tip.
> > 
> > If there is no objections against this patch i am happy to do the
> > job ;-)
> > 
> > BTW: Thanks to Andy for doing this job to git rid off this ugly compat
> > vDSO layer.
> > 
> >> Also, if you state a preference, could you please motivate it?
> > 
> > For the next three days i am very busy with a important project, so i
> > will rebase the vdso 32 bit time patch on Monday or Tuesday. 
> > 
> 
> So when I get the updated patch from Andy I will pull it into tip,
> resetting the x86/vdso branch.  I'll then expect an upgraded and
> simplified patchset from you to put on top.
> 
> Sounds like a plan.
> 

I love it when a plan comes together.

OT: Re: [PATCH 3/3] x86, vdso32: handle 32 bit vDSO larger one page

[Hans-Peter Jansen]

On Donnerstag, 13. März 2014 14:00:10 Andi Kleen wrote:
 
> At some point the majority of my nfsroot test image were OpenSUSE 9.

Hehe, I had a 9.3 system (2.6.11.4) with an uptime of > 1000 days before power 
outage, and one 11.1 (2.6.27.56), that has an uptime of 1029 days now. While 
git brought in many good aspects, the gain in development speed resulted in 
noticeable decrease of long term stability. And the kernel is a pretty well 
managed project still, compared to other related ones..

> It was the last opensuse system that booted fast without udev or initrd :-)

The ramifications of udev and initrd where tiny, given what systemd has caused 
to openSUSE lately, combined with the (nowadays) usual nfs and autofs 
dysfunctions.. It all made 13.1 sucking rocks. 

SCR,
 Pete