Description of problem: kernel hangs at boot if the kernel boot parameter "vdso=2" is specified. Version-Release number of selected component (if applicable): kernel-2.6.23.9-85.fc8 How reproducible: Always Steps to Reproduce: 1. Append " vdso=2" to the kernel boot command line. 2. Boot. 3. Actual results: Hang with console messages: init[1] general protection eip=3167d9 esp=bfbdd89c error:0 and repetition counts into the multi-millions. Expected results: Enable VDSO_COMPAT feature, which puts the vdso at a very high virtual address. Specifying "vdso=0" does not remove the vdso. Instead, vdso=0 still puts the vdso into the address space, it just doesn't tell you where (it merely omits the AT_SYSINFO* parameters.) What I want is no vdso, or vdso outside the range 0 to 0xa0000000 (2.56GB). Additional info: Somewhat related to bug # 229304.
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(¤t->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.