Fix COMPAT_VDSO regression bug

Revert "[PATCH] Fix CONFIG_COMPAT_VDSO"
This reverts commit a1f3bb9ae4497a2ed3eac773fd7798ac33a0371f.

Several systems couldnt boot using CONFIG_HIGHMEM64G=y as reported in bug #8040. Reverting the above patch solved the problem.

arch/i386/kernel/entry.S    |    4 ----
arch/i386/kernel/sysenter.c |    2 --
include/asm-i386/elf.h      |    7 ++++---
include/asm-i386/fixmap.h   |    2 --
include/asm-i386/page.h     |    2 --
5 files changed, 4 insertions(+), 13 deletions(-)

index 5e47683..06461b8 100644
@@ -302,16 +302,12 @@ sysenter_past_esp:
       pushl $(__USER_CS)
       CFI_ADJUST_CFA_OFFSET 4
       /*CFI_REL_OFFSET cs, 0*/
-#ifndef CONFIG_COMPAT_VDSO
       /*
        * Push current_thread_info()->sysenter_return to the stack.
        * A tiny bit of offset fixup is necessary - 4*4 means the 4 words
        * pushed above; +8 corresponds to copy_thread's esp0 setting.
        */
       pushl (TI_sysenter_return-THREAD_SIZE+8+4*4)(%esp)
-#else
-       pushl $SYSENTER_RETURN
-#endif
       CFI_ADJUST_CFA_OFFSET 4
       CFI_REL_OFFSET eip, 0
 

index 666f70d..a1090e1 100644
@@ -95,7 +95,6 @@ int __init sysenter_setup(void)
       return 0;

}

-#ifndef CONFIG_COMPAT_VDSO
static struct page *syscall_nopage(struct vm_area_struct *vma,
unsigned long adr, int *type)
{
@@ -190,4 +189,3 @@ int in_gate_area_no_task(unsigned long addr)

{
       return 0;
}

-#endif

index 369035d..157bb7a 100644
@@ -143,9 +143,12 @@ extern int dump_task_extended_fpu (struct

task_struct *, struct user_fxsr_struct

# define VDSO_PRELINK          0
#endif

-#define VDSO_SYM(x) \
+#define VDSO_COMPAT_SYM(x) \
(VDSO_COMPAT_BASE + (unsigned long)(x) - VDSO_PRELINK)

+#define VDSO_SYM(x) \
+ (VDSO_BASE + (unsigned long)(x) - VDSO_PRELINK)
+
#define VDSO_HIGH_EHDR ((const struct elfhdr *) VDSO_HIGH_BASE)
#define VDSO_EHDR ((const struct elfhdr *) VDSO_COMPAT_BASE)

@@ -153,12 +156,10 @@ extern void __kernel_vsyscall;

#define VDSO_ENTRY VDSO_SYM(&__kernel_vsyscall)

-#ifndef CONFIG_COMPAT_VDSO
#define ARCH_HAS_SETUP_ADDITIONAL_PAGES
struct linux_binprm;
extern int arch_setup_additional_pages(struct linux_binprm *bprm,

                                       int executable_stack);

-#endif

extern unsigned int vdso_enabled;

index 3e9f610..02428cb 100644
@@ -23,8 +23,6 @@

extern unsigned long __FIXADDR_TOP;
#else
#define __FIXADDR_TOP 0xfffff000
-#define FIXADDR_USER_START __fix_to_virt(FIX_VDSO)
-#define FIXADDR_USER_END __fix_to_virt(FIX_VDSO - 1)
#endif

#ifndef __ASSEMBLY__

index 7b19f45..fd3f64a 100644
@@ -143,9 +143,7 @@ extern int page_is_ram(unsigned long pagenr);

#include <asm-generic/memory_model.h>
#include <asm-generic/page.h>

-#ifndef CONFIG_COMPAT_VDSO
#define __HAVE_ARCH_GATE_AREA 1
-#endif
#endif /* __KERNEL__ */

#endif /* _I386_PAGE_H */

I built a CONFIG_COMPAT_VDSO=y, CONFIG_HIGHMEM64G=y kernel and it has no problems with FC-6 userland. Everything looks fine with the vDSO. So either some more details of your kernel config are relevant, or something about the userland usage pattern.

Thanks,
Roland

What stable version did you revert this in that solved your problem?

thanks,

greg k-h

v2.6.20.3

--
Leroy

From: Nilshar <nilshar <at> gmail.com>
Subject: Re: [Bug 8040] Hang before INIT when CONFIG_HIGHMEM4G=y
Date: 2007-03-15 10:02:14 GMT (4 minutes ago)

Hello,

I can confirm that the problem disappear when I disable Compat VDSO support by setting CONFIG_COMPAT_VDSO=n.

I think reverting it is probably the right thing to do, unless we can fix it for real quite promptly.

But nobody will be able to apply this patch - your email client as really gone to town on it - the results are phenomenally ugly.

And the patch wouldn't have applied to mainline anyway - there have been other changes.

Chuck Ebbert at redhat.com asked:

bisects go bad.

As requested I started to redo the test but now without git using kernel.org tars. The results now are, still using the same .config:
linux-2.6.20.tar.gz : bad
linux-2.6.20.1.tar.gz: bad (boot log equal) linux-2.6.20.2.tar.gz: good
linux-2.6.20.3.tar.gz: good
(triple checked)

Chuck is right, the bisect gone bad.
I asked Nilshar to try these kernels too with:
COMPAT_VDSO=y
CONFIG_HIGHMEM64G=y

He did and says 2.6.20.3 works fine. So only 2.6.20 and 2.6.20.1 had this 'hang' at boot behavior on my Supermicro 7044 while Nilshar's machine started working with 2.6.20.3

Reverting avoided imo. I hope more people cheer up who reported bug #8040 and confirm it's fine with the latest stable.