Bug 427641

Also present in kernel-2.6.23.12-52.fc7.

*** This bug has been marked as a duplicate of 375681 ***

Please re-open, because vdso=2 is not a duplicate of vdso=off (or vdso=0) as is
the case in bug # 375681.

The documented [linux/Documentation/kernel-parameters.txt] and desired behavior
with vdso=2 is for the vdso to be present and announced to the process via
AT_SYSINFO*, but for the vdso page to be placed at a very high virtual address,
higher than any other valid user-accessible address, higher than anywhere in the
stack, higher than any pointer to (or characters of) a commandline argument or
environment variable, higher than any AT_* vector.

Also, the documentation says that "vdso=0" works, whereas comments to bug #
375681 shows that it didn't work then.

(In reply to comment #3)

> The documented [linux/Documentation/kernel-parameters.txt] and desired behavior
> with vdso=2 is for the vdso to be present and announced to the process via
> AT_SYSINFO*, but for the vdso page to be placed at a very high virtual address,
> higher than any other valid user-accessible address, higher than anywhere in the
> stack, higher than any pointer to (or characters of) a commandline argument or
> environment variable, higher than any AT_* vector.

Sorry. per comment #0 you mention that you want no vdso, which vdso=off would
have given you.  What about the sysctl recommended in bug 375681?  Has the
behavior of that changed at all?

It's also worth noting that I could not reproduce this on my laptop (a Core 2
Duo with 2GB RAM).  Then I tried on a VMWare guest that I gave the maximum
amount of RAM (3600MB) and it is reproducible there.

> Also, the documentation says that "vdso=0" works, whereas comments to bug #
> 375681 shows that it didn't work then.

Right, but vdso=off did.

(In reply to comment #4)

> What about the sysctl recommended in bug 375681?

Running (as root) "sysctl vm.vdso_enabled=2" causes *every* new process to crash
with Segmentation fault.  Existing processes run, but the system is unusable for
anything else.  Shutdown fails; hardware reset is necessary.

> It's also worth noting that I could not reproduce this on my laptop (a Core 2
> Duo with 2GB RAM).  Then I tried on a VMWare guest that I gave the maximum
> amount of RAM (3600MB) and it is reproducible there.

Booting vdso=2 always hangs for me on i686 (amd64 in i686 mode, NVidia CK804
chipset) with 1GB RAM.

Its easy for me to replicate this, both with current and rawhide kernels. It
might be resolved in Roland McGrath's patchset which didn't make 2.6.24 however....

http://lkml.org/lkml/2007/11/19/277

If you have a live shell you can do "echo 1 > /proc/sys/vm/vdso_enabled" without
needing to exec any new programs that hit the problem.

Reproduced and isolated with 2.6.23.14-107.fc8.  workaround:

 stap -g -e 'function ebx:long() %{ THIS->__retvalue = c->regs->ebx;
c->regs->ebx=0xfffff000; %} probe kernel.statement(0xc10060cd) { printf("%s %d
limit=%x\n", execname(), pid(), ebx()); }'&

I committed a fix to rawhide's linux-2.6-execshield.patch; backporting this to
F-8 should cover it, or it can wait til F-8 rebases from the 2.6.24-based code.

Reassigning to punt worrying about F-8.

--- linux-2.6.23.noarch/arch/i386/kernel/traps.c.~1~
+++ linux-2.6.23.noarch/arch/i386/kernel/traps.c
@@ -599,6 +599,9 @@ unsigned long limit;
 		for (vma = current->mm->mmap; vma; vma = vma->vm_next)
 			if ((vma->vm_flags & VM_EXEC) && (vma->vm_end > limit))
 				limit = vma->vm_end;
+		vma = get_gate_vma(current);
+		if (vma && (vma->vm_flags & VM_EXEC) && (vma->vm_end > limit))
+			limit = vma->vm_end;
 		spin_unlock(&current->mm->page_table_lock);
 		if (limit >= TASK_SIZE)
 			limit = -1UL;

Fixed in 2.6.23.14-125

kernel-2.6.23.15-137.fc8 has been submitted as an update for Fedora 8

kernel-2.6.23.15-137.fc8 has been pushed to the Fedora 8 stable repository.  If problems still persist, please make note of it in this bug report.