Received: by 10.223.185.116 with SMTP id b49csp2632347wrg; Mon, 5 Mar 2018 06:19:30 -0800 (PST) X-Google-Smtp-Source: AG47ELvbXzf5RWHa8F2Ykq+bd0kPjPRTOdXC2dDQB8htU57wRWI8BoEcRdq5VXFSgWnMCrhhh1aa X-Received: by 10.99.110.137 with SMTP id j131mr12391253pgc.85.1520259570059; Mon, 05 Mar 2018 06:19:30 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1520259570; cv=none; d=google.com; s=arc-20160816; b=LrUsDUOu7D16dbRTe6Z6/IgJDWsIe5HutKGZ1SKfZ/WDLdCNas/KRicGjfX6WG4VgO uMt9m7nkGLW0X1VUKJlwcqbrV+HY+RSGMz1rb9ACoB7iCyNQsvxdqNOjbz+xRsFVKPCH yG4MYPhb7Xk59bZxzgiOdBMzi2BlPeq9E10b/IOne5ZuaJFOgEJIbWOqoGT9xkJehxrg bTwyMbq4jjPhP76NujecPXtwlNEkjPLsFgTOEAHQB0PiOHI8nMYy894VsABhgi+64FQM Tr/UuR3QdicRU7kLhDhNSyWzL/ddhmYymAvmNP1NtckzhGHAPWFk95umHX3OJkVgxc21 dpAw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date:arc-authentication-results; bh=+vTWMZafn9nZJWMsncP07zmNCTlDM8IRtRcKudJsbl0=; b=EpMeOX2sy1VjGzgs4uvZVlJvDEDzsPpa5R/xakC3H9OSZgC5fdW3zj0nCryYu1F5HJ xqaw+Gu/qPpej2wCF2eGwniqWvzcwD54A6739CKOk58aFGMay6ZnUO6Uq2t6nNrCv7Uk zEPaTFUozAMSOChX3M531FSdv17Xucnkc+cF8ACVWJN93WVsysO/WBwUL3U6BND/WKKQ Wua53a71hd3+DROmC8mhrEYu0QRbNNuaVC6Y+e9lvjZIkmqtiPKiarPHwjOkWicOAo19 JaQ/CDXi4IgAdrhER/YEGxcLsCn+yCDZgSZi4+w1dL+V0mMJwrIaS15kkRspGPb9HCbh wLKw== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=redhat.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id f1si88239pgo.171.2018.03.05.06.19.15; Mon, 05 Mar 2018 06:19:30 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=redhat.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S935155AbeCENiz (ORCPT + 99 others); Mon, 5 Mar 2018 08:38:55 -0500 Received: from mx3-rdu2.redhat.com ([66.187.233.73]:58048 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S933798AbeCENiv (ORCPT ); Mon, 5 Mar 2018 08:38:51 -0500 Received: from smtp.corp.redhat.com (int-mx06.intmail.prod.int.rdu2.redhat.com [10.11.54.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 81739EAE98; Mon, 5 Mar 2018 13:38:50 +0000 (UTC) Received: from treble (ovpn-122-109.rdu2.redhat.com [10.10.122.109]) by smtp.corp.redhat.com (Postfix) with SMTP id 2C8B4213AEF8; Mon, 5 Mar 2018 13:38:50 +0000 (UTC) Date: Mon, 5 Mar 2018 07:38:49 -0600 From: Josh Poimboeuf To: Peter Zijlstra Cc: Sven Joachim , Linus Torvalds , Linux Kernel Mailing List , Thomas Gleixner Subject: Re: Linux 4.16-rc4 Message-ID: <20180305133849.moxovwol5nek2fvh@treble> References: <878tb7eyf8.fsf@turtle.gmx.de> <20180305101748.GL25201@hirez.programming.kicks-ass.net> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20180305101748.GL25201@hirez.programming.kicks-ass.net> User-Agent: Mutt/1.6.0.1 (2016-04-01) X-Scanned-By: MIMEDefang 2.78 on 10.11.54.6 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.11.55.1]); Mon, 05 Mar 2018 13:38:50 +0000 (UTC) X-Greylist: inspected by milter-greylist-4.5.16 (mx1.redhat.com [10.11.55.1]); Mon, 05 Mar 2018 13:38:50 +0000 (UTC) for IP:'10.11.54.6' DOMAIN:'int-mx06.intmail.prod.int.rdu2.redhat.com' HELO:'smtp.corp.redhat.com' FROM:'jpoimboe@redhat.com' RCPT:'' Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Mar 05, 2018 at 11:17:48AM +0100, Peter Zijlstra wrote: > On Mon, Mar 05, 2018 at 09:09:31AM +0100, Sven Joachim wrote: > > On 2018-03-04 15:15 -0800, Linus Torvalds wrote: > > > > > Hmm. A reasonably calm week - the biggest change is to the 'kvm-stat' > > > tool, not any actual kernel files. > > > > > > But there's small changes all over, with architecture updates (x86, > > > s390, arm, parisc) and drivers (media, md, gpu, sound) being the bulk > > > of it. But there's some filesystem fixes (mostly btrfs), > > > documentation updates etc too. > > > > > > Go test, > > > > Huh, this version does not build for me: > > > > ,---- > > | CALL scripts/checksyscalls.sh > > | DESCEND objtool > > | CC /usr/local/src/linux/tools/objtool/check.o > > | In file included from check.c:26:0: > > | check.c: In function 'read_retpoline_hints': > > | warn.h:57:3: error: format '%ld' expects argument of type 'long int', but argument 5 has type 'unsigned int' [-Werror=format=] > > | "%s: warning: objtool: " format "\n", \ > > | ^ > > | check.c:1135:3: note: in expansion of macro 'WARN' > > | WARN("retpoline_safe size mismatch: %d %ld", sec->len, sizeof(unsigned long)); > > | ^~~~ > > | check.c:1135:44: note: format string is defined here > > | WARN("retpoline_safe size mismatch: %d %ld", sec->len, sizeof(unsigned long)); > > | ~~^ > > | %d > > | cc1: all warnings being treated as errors > > | mv: cannot stat '/usr/local/src/linux/tools/objtool/.check.o.tmp': No such file or directory > > | /usr/local/src/linux/tools/build/Makefile.build:96: recipe for target '/usr/local/src/linux/tools/objtool/check.o' failed > > | make[3]: *** [/usr/local/src/linux/tools/objtool/check.o] Error 1 > > `---- > > > > This might be because I still use a 32-bit userland with a 64-bit > > kernel. > > Urgh, so sizeof() returns size_t which is confusing. But what is the > actual value of sizeof(unsigned long) for you? I suspect cross building > objtool doesn't work right at all. We build the kernel using LP64, and > its retpoline_safe section is 8 bytes. But if we build objtool as ILP32 > then it would interpret things as 4 bytes. > > Josh, is that supposed to work? I could of course move the retpoline > annotation over to 4 byte relative addressing which would fix this one > issue. Is that really the only case? I suspect it may be the only case. In most cases objtool relies on libelf for handling the object bit width. It looks like read_retpoline_hints() is "special" compared to the other annotation reading functions. The easiest fix would be to convert it to be like the others. Sven, can you test this patch? --- diff --git a/tools/objtool/check.c b/tools/objtool/check.c index 472e64e95891..e00ff29cb7ea 100644 --- a/tools/objtool/check.c +++ b/tools/objtool/check.c @@ -1112,42 +1112,29 @@ static int read_unwind_hints(struct objtool_file *file) static int read_retpoline_hints(struct objtool_file *file) { - struct section *sec, *relasec; + struct section *sec; struct instruction *insn; struct rela *rela; - int i; - sec = find_section_by_name(file->elf, ".discard.retpoline_safe"); + sec = find_section_by_name(file->elf, ".rela.discard.retpoline_safe"); if (!sec) return 0; - relasec = sec->rela; - if (!relasec) { - WARN("missing .rela.discard.retpoline_safe section"); - return -1; - } - - if (sec->len % sizeof(unsigned long)) { - WARN("retpoline_safe size mismatch: %d %ld", sec->len, sizeof(unsigned long)); - return -1; - } - - for (i = 0; i < sec->len / sizeof(unsigned long); i++) { - rela = find_rela_by_dest(sec, i * sizeof(unsigned long)); - if (!rela) { - WARN("can't find rela for retpoline_safe[%d]", i); + list_for_each_entry(rela, &sec->rela_list, list) { + if (rela->sym->type != STT_SECTION) { + WARN("unexpected relocation symbol type in %s", sec->name); return -1; } insn = find_insn(file, rela->sym->sec, rela->addend); if (!insn) { - WARN("can't find insn for retpoline_safe[%d]", i); + WARN("bad .discard.retpoline_safe entry"); return -1; } if (insn->type != INSN_JUMP_DYNAMIC && insn->type != INSN_CALL_DYNAMIC) { - WARN_FUNC("retpoline_safe hint not a indirect jump/call", + WARN_FUNC("retpoline_safe hint not an indirect jump/call", insn->sec, insn->offset); return -1; }