2015-11-17 14:12:34

by Jiri Slaby

[permalink] [raw]
Subject: .gnu.hash into text PHDR?

Hi,

after
commit 6b7e26547fad7ace3dcb27a5babd2317fb9d1e12
Author: Andy Lutomirski <[email protected]>
Date: Thu Aug 6 14:45:45 2015 -0700

x86/vdso: Emit a GNU hash

I believe .gnu.hash in arch/x86/entry/vdso/vdso-layout.lds.S should have
":text", right?

Not that it would matter (it is put there automagically), but I noted it
while hunting a new failure inside KVM (host is 4.2 for some time, guest
was upgraded to 4.3 recently). KVM dies when javac invokes gtod:
KVM internal error. Suberror: 1
emulation failure
...
[javac] # C [linux-vdso.so.1+0xe45] __vdso_gettimeofday+0x125

which is "movl hpet_page+240(%rip), %eax". Any ideas?

More details at:
https://bugzilla.novell.com/show_bug.cgi?id=954218

thanks,
--
js
suse labs


2015-11-18 16:14:41

by Andy Lutomirski

[permalink] [raw]
Subject: Re: .gnu.hash into text PHDR?

On Nov 17, 2015 6:12 AM, "Jiri Slaby" <[email protected]> wrote:
>
> Hi,
>
> after
> commit 6b7e26547fad7ace3dcb27a5babd2317fb9d1e12
> Author: Andy Lutomirski <[email protected]>
> Date: Thu Aug 6 14:45:45 2015 -0700
>
> x86/vdso: Emit a GNU hash
>
> I believe .gnu.hash in arch/x86/entry/vdso/vdso-layout.lds.S should have
> ":text", right?

ld --verbose says:

SECTIONS
{
/* Read-only sections, merged into text segment: */
PROVIDE (__executable_start = SEGMENT_START("text-segment",
0x400000)); . = SEGMENT_START("text-segment", 0x400000) +
SIZEOF_HEADERS;
.interp : { *(.interp) }
.note.gnu.build-id : { *(.note.gnu.build-id) }
.hash : { *(.hash) }
.gnu.hash : { *(.gnu.hash) }

so I'm not sure it's needed.

Did you confirm that reverting that patch fixes it?

>
> Not that it would matter (it is put there automagically), but I noted it
> while hunting a new failure inside KVM (host is 4.2 for some time, guest
> was upgraded to 4.3 recently). KVM dies when javac invokes gtod:
> KVM internal error. Suberror: 1
> emulation failure
> ...
> [javac] # C [linux-vdso.so.1+0xe45] __vdso_gettimeofday+0x125
>
> which is "movl hpet_page+240(%rip), %eax". Any ideas?

That's really weird. Can you send the guest kernel log (or at least
anything containing the substrings tsc, hpet, or clock)? Could you
also send arch/x86/entry/vdso/vdso64.so{,.dbg} from a bad kernel?

If it's easy in your environment, the
/sys/devices/system/clocksource/clocksource0/current_clocksource on
the guest as well as the output of dump-vdso_64 from git clone
git://git.kernel.org/pub/scm/linux/kernel/git/luto/misc-tests.git are
also potentially useful.

How did that backtrace show up after the emulation failure? Usually
everything's dead when emulation fails for me. Also, the fact that
"Code" is blank is suspicious.

My best guess is that the guest doesn't have an hpet (or that the host
is providing a totally nonfunctional hpet) and that something (my
patch?) is causing an entry into the wrong place in the vdso. Bad
relocation, perhaps?

For me, at least, the image seems fine:

$ readelf -s -D vdso64.so

Symbol table for image:
Num Buc: Value Size Type Bind Vis Ndx Name
5 0: 0000000000000e70 21 FUNC GLOBAL DEFAULT 12 __vdso_time
10 0: 0000000000000e90 41 FUNC WEAK DEFAULT 12 getcpu
9 0: 0000000000000e90 41 FUNC GLOBAL DEFAULT 12 __vdso_getcpu
3 0: 0000000000000d00 354 FUNC GLOBAL DEFAULT 12 __vdso_gettimeofday
8 0: 0000000000000000 0 OBJECT GLOBAL DEFAULT ABS LINUX_2.6
4 1: 0000000000000d00 354 FUNC WEAK DEFAULT 12 gettimeofday
7 2: 0000000000000a80 630 FUNC GLOBAL DEFAULT 12
__vdso_clock_gettime
6 2: 0000000000000e70 21 FUNC WEAK DEFAULT 12 time
2 2: 0000000000000a80 630 FUNC WEAK DEFAULT 12 clock_gettime

Symbol table of `.gnu.hash' for image:
Num Buc: Value Size Type Bind Vis Ndx Name
2 0: 0000000000000a80 630 FUNC WEAK DEFAULT 12 clock_gettime
3 0: 0000000000000d00 354 FUNC GLOBAL DEFAULT 12 __vdso_gettimeofday
4 0: 0000000000000d00 354 FUNC WEAK DEFAULT 12 gettimeofday
5 0: 0000000000000e70 21 FUNC GLOBAL DEFAULT 12 __vdso_time
6 1: 0000000000000e70 21 FUNC WEAK DEFAULT 12 time
7 1: 0000000000000a80 630 FUNC GLOBAL DEFAULT 12
__vdso_clock_gettime
8 2: 0000000000000000 0 OBJECT GLOBAL DEFAULT ABS LINUX_2.6
9 2: 0000000000000e90 41 FUNC GLOBAL DEFAULT 12 __vdso_getcpu
10 2: 0000000000000e90 41 FUNC WEAK DEFAULT 12 getcpu

I have the same result if I run readelf -s -D on the output from dump-vdso_64.

--Andy