Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756244AbbKRQOl (ORCPT ); Wed, 18 Nov 2015 11:14:41 -0500 Received: from mail-oi0-f49.google.com ([209.85.218.49]:35095 "EHLO mail-oi0-f49.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754756AbbKRQOj (ORCPT ); Wed, 18 Nov 2015 11:14:39 -0500 MIME-Version: 1.0 In-Reply-To: <564B35CC.3050803@suse.cz> References: <564B35CC.3050803@suse.cz> From: Andy Lutomirski Date: Wed, 18 Nov 2015 08:14:19 -0800 Message-ID: Subject: Re: .gnu.hash into text PHDR? To: Jiri Slaby Cc: "linux-kernel@vger.kernel.org" , X86 ML Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 4002 Lines: 99 On Nov 17, 2015 6:12 AM, "Jiri Slaby" wrote: > > Hi, > > after > commit 6b7e26547fad7ace3dcb27a5babd2317fb9d1e12 > Author: Andy Lutomirski > 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@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/