Description of problem: Any program which use vdso gettimeofday is segfaulted. Version-Release number of selected component (if applicable): 2.6.18-238.el5 #1 SMP Sun Dec 19 14:22:44 EST 2010 x86_64 x86_64 x86_64 GNU/Linux How reproducible: 100% Steps to Reproduce: 1. try chroot in fedora-13 2. 3. Actual results: Segmentation fault Expected results: gettimeofday returns 0 Additional info: See fix in attachment
Created attachment 475892 [details] patch to fix this bug
Hi Andrey, I hate to ask (because it is so simple ;) ) but would you mind attaching the program that segfaults? I'm just curious ;) Thanks, P.
I don't understand your sarcasm. I wrote that you can try chroot to fc13. You can make following actions: * mkdir fc; cd fc * wget http://download.openvz.org/template/precreated/fedora-13-x86_64.tar.gz * tar -xzf fedora-13-x86_64.tar.gz * ulimit -c unlimited * chroot . Segmentation fault (core dumped) [root@dhcp-10-30-20-213 fc13]# gdb -c core.8294 GNU gdb Fedora (6.8-37.el5) Copyright (C) 2008 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "x86_64-redhat-linux-gnu". (no debugging symbols found) Core was generated by `/bin/bash -i'. Program terminated with signal 11, Segmentation fault. [New process 8294] #0 0x00007fff55ffd6eb in ?? () (gdb) disassemble 0x00007fff55ffd6eb-50 0x00007fff55ffd6eb+50 Dump of assembler code from 0x7fff55ffd6b9 to 0x7fff55ffd71d: 0x00007fff55ffd6b9: jmpq 0x7fff55ffd636 0x00007fff55ffd6be: addq $0x1,(%rdi) 0x00007fff55ffd6c2: sub $0x3b9aca00,%rax 0x00007fff55ffd6c8: jmp 0x7fff55ffd667 0x00007fff55ffd6ca: add %al,(%rax) 0x00007fff55ffd6cc: add %al,(%rax) 0x00007fff55ffd6ce: add %al,(%rax) 0x00007fff55ffd6d0: mov %rbx,-0x10(%rsp) 0x00007fff55ffd6d5: mov %rbp,-0x8(%rsp) 0x00007fff55ffd6da: sub $0x10,%rsp 0x00007fff55ffd6de: mov 0x543(%rip),%rax # 0x7fff55ffdc28 0x00007fff55ffd6e5: mov %rdi,%rbx 0x00007fff55ffd6e8: mov %rsi,%rbp 0x00007fff55ffd6eb: mov (%rax),%eax <-------------------------- 0x00007fff55ffd6ed: test %eax,%eax 0x00007fff55ffd6ef: je 0x7fff55ffd740 0x00007fff55ffd6f1: mov 0x208(%rip),%rax # 0x7fff55ffd900 0x00007fff55ffd6f8: cmpl $0x4,0x30(%rax) 0x00007fff55ffd6fc: je 0x7fff55ffd740 0x00007fff55ffd6fe: callq 0x7fff55ffd600 0x00007fff55ffd703: mov 0x8(%rbx),%rcx 0x00007fff55ffd707: mov $0x20c49ba5e353f7cf,%rdx 0x00007fff55ffd711: mov %rcx,%rax 0x00007fff55ffd714: sar $0x3f,%rcx 0x00007fff55ffd718: imul %rdx 0x00007fff55ffd71b: xor %eax,%eax End of assembler dump. (gdb) info registers rax 0x0 0 rbx 0x7fff55f530f0 140734635520240 rcx 0x2b5836723e90 47657870573200 rdx 0x0 0 rsi 0x0 0 rdi 0x7fff55f530f0 140734635520240 rbp 0x0 0x0 rsp 0x7fff55f530c8 0x7fff55f530c8 r8 0xfefefefefefefeff -72340172838076673 r9 0x0 0 r10 0x7fff55f52e70 140734635519600 r11 0x2b583643f760 47657867540320 r12 0x1656b240 374780480 r13 0x7fff55f53120 140734635520288 r14 0x6 6 r15 0x0 0 rip 0x7fff55ffd6eb 0x7fff55ffd6eb eflags 0x202 [ IF ] cs 0x83 131 ss 0x7b 123 ds 0x0 0 es 0x0 0 fs 0x0 0 gs 0x0 0 fctrl 0x37f 895 fstat 0x0 0 ftag 0xffff 65535 fiseg 0x0 0 fioff 0x0 0 foseg 0x0 0 fooff 0x0 0 fop 0x0 0 mxcsr 0x1f80 [ IM DM ZM OM UM PM ] (gdb) p *0x7fff55ffdc28 $2 = 0
Created attachment 477178 [details] core.8294
You can look at arch/x86_64/vdso/vextern.h /* Any kernel variables used in the vDSO must be exported in the main kernel's vmlinux.lds.S/vsyscall.h/proper __section and put into vextern.h and be referenced as a pointer with vdso prefix. The main kernel later fills in the values. */ Your vDSO code use sysctl_vsyscall which isn't exported. My patch fix this one.
(In reply to comment #3) > I don't understand your sarcasm. > Oops -- no sarcasm intended. I was wondering if you had a single program (other than the chroot method) because I'd like to test *exactly* what you did to reproduce. chroot seems like a longer test ... I'll write up a simple program to call gettimeofday() and (if I understand things correctly) it should just segfault. P.
(In reply to comment #5) > You can look at arch/x86_64/vdso/vextern.h > > /* Any kernel variables used in the vDSO must be exported in the main > kernel's vmlinux.lds.S/vsyscall.h/proper __section and > put into vextern.h and be referenced as a pointer with vdso prefix. > The main kernel later fills in the values. */ > > Your vDSO code use sysctl_vsyscall which isn't exported. My patch fix this one. Absolutely correct. I did see that but was wondering if you had a simpler reproducer in mind. Anyway ... I'll reserve a system and see if can easily reproduce. Thanks for the patch -- it's much appreciated! P.
(In reply to comment #6) > chroot seems like a longer test ... I'll write up a simple program to call > gettimeofday() and (if I understand things correctly) it should just segfault. > > P. You are not absolutely right, because glibc in rhel6 isn't supported vdso and use generic syscalls all time. Fedora 13 contains glibc with vdso support, so I suggest chroot.
(In reply to comment #8) > (In reply to comment #6) > > chroot seems like a longer test ... I'll write up a simple program to call > > gettimeofday() and (if I understand things correctly) it should just segfault. > > > > P. > > You are not absolutely right, because glibc in rhel6 isn't supported vdso and > use generic syscalls all time. Fedora 13 contains glibc with vdso support, so I > suggest chroot. Oof ... yeah. Good point. The chroot test definitely fails, and after I add your suggested patch it works. I'll review the patch and make sure no additional patches are required and then pass it on for internal review. Again, thanks for the patch. :) P.
Created attachment 477421 [details] Export wall_to_monotonic to vdso code. Need apply both patches. wall_to_monotonic isn't exported too.
Andrew, I'm going to open up a NEW Bugzilla in a few minutes with your patch from comment #10. I will cc you directly on the new BZ. P.
Andrew, for the patch in comment #10 please see BZ 675727. Thanks, P.
This request was evaluated by Red Hat Product Management for inclusion in a Red Hat Enterprise Linux maintenance release. Product Management has requested further review of this request by Red Hat Engineering, for potential inclusion in a Red Hat Enterprise Linux Update release for currently deployed products. This request is not yet committed for inclusion in an Update release.
*** Bug 678351 has been marked as a duplicate of this bug. ***
in kernel-2.6.18-245.el5 You can download this test kernel (or newer) from http://people.redhat.com/jwilson/el5 Detailed testing feedback is always welcomed.
Reproduced in 2.6.18-244.el5 and verified in 2.6.18-245.el5.
Technical note added. If any revisions are required, please edit the "Technical Notes" field accordingly. All revisions will be proofread by the Engineering Content Services team. New Contents: VDSO (Virtual Dynamically-linked Shared Object) kernel variables must be exported in vextern.h, otherwise they end up as undefined pointers. When calling the VDSO gettimeofday() function in Red Hat Enterprise Linux 5, a missing declaration lead to a segmentation fault. With this update, the sysctl_vsyscall system call is properly exported and segmentation faults no longer occur.
An advisory has been issued which should help the problem described in this bug report. This report is therefore being closed with a resolution of ERRATA. For more information on therefore solution and/or where to find the updated files, please follow the link below. You may reopen this bug report if the solution does not work for you. http://rhn.redhat.com/errata/RHSA-2011-1065.html