Re: .gnu.hash into text PHDR?

[Andy Lutomirski]

On Nov 17, 2015 6:12 AM, "Jiri Slaby" <jslaby@xxxxxxx> wrote:
>
> Hi,
>
> after
> commit 6b7e26547fad7ace3dcb27a5babd2317fb9d1e12
> Author: Andy Lutomirski <luto@xxxxxxxxxxxxxx>
> 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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/