lkml.org 
[lkml]   [2015]   [Nov]   [18]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
Date
SubjectRe: .gnu.hash into text PHDR?
On Nov 17, 2015 6:12 AM, "Jiri Slaby" <jslaby@suse.cz> wrote:
>
> Hi,
>
> after
> commit 6b7e26547fad7ace3dcb27a5babd2317fb9d1e12
> Author: Andy Lutomirski <luto@amacapital.net>
> 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


\
 
 \ /
  Last update: 2015-11-18 17:41    [W:0.036 / U:5.964 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site