From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-3.8 required=3.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SIGNED_OFF_BY, SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 0499AC33CB7 for ; Fri, 31 Jan 2020 09:18:33 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id C3C6020CC7 for ; Fri, 31 Jan 2020 09:18:32 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=ellerman.id.au header.i=@ellerman.id.au header.b="mBhwEQHD" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728207AbgAaJSc (ORCPT ); Fri, 31 Jan 2020 04:18:32 -0500 Received: from bilbo.ozlabs.org ([203.11.71.1]:54641 "EHLO ozlabs.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728159AbgAaJSb (ORCPT ); Fri, 31 Jan 2020 04:18:31 -0500 Received: from authenticated.ozlabs.org (localhost [127.0.0.1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by mail.ozlabs.org (Postfix) with ESMTPSA id 488BTw54LNz9sRR; Fri, 31 Jan 2020 20:18:27 +1100 (AEDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ellerman.id.au; s=201909; t=1580462309; bh=cCI4WreJl9TPaQKBLWhchJurIy1jFBvqbedUEJxwYO0=; h=From:To:Subject:In-Reply-To:References:Date:From; b=mBhwEQHDz1XN3CYCwbbKhv0GeXIMwF6PpEKmhsU6baEkq/O5znNz1kxwO04DdH2cV cQHk2ukvWfkffBL51JWySB3i6n7Xl7+K7RF1CR+iQJlUb4nIovevkPsf/8IiWcXORj GnpcWStMenr/9iLqB+KmRYUxsIRmXjpWUw5hp3ZUkzSpP5jJKbtBG4k1xfmDmVRV+b DxTrd/E5w6IIfyo7oKOaCcXqhx0VhKUuGDld1R6qNtw50PBEprXULq816EfAofOTaJ iSMjmoBQSKBOxBN5hak7fA5eN3jYxhDXL/fQxIQu/+805iAC1oUuQmmADCj4gw1uOq PWLBEBWRkYeDw== From: Michael Ellerman To: Alex Ghiti , Benjamin Herrenschmidt , Paul Mackerras , linuxppc-dev@lists.ozlabs.org, linux-kernel@vger.kernel.org, Stephen Rothwell , Alexei Starovoitov , linux-next@vger.kernel.org, Zong Li , Palmer Dabbelt Subject: Re: [PATCH v2] powerpc: Do not consider weak unresolved symbol relocations as bad In-Reply-To: <8a8d45c6-4ad2-c682-abfb-3d97188d0d45@ghiti.fr> References: <20200118170335.21440-1-alex@ghiti.fr> <8a8d45c6-4ad2-c682-abfb-3d97188d0d45@ghiti.fr> Date: Fri, 31 Jan 2020 20:18:25 +1100 Message-ID: <87wo98f0gu.fsf@mpe.ellerman.id.au> MIME-Version: 1.0 Content-Type: text/plain Sender: linux-next-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-next@vger.kernel.org Alex Ghiti writes: > On 1/18/20 12:03 PM, Alexandre Ghiti wrote: >> Commit 8580ac9404f6 ("bpf: Process in-kernel BTF") introduced two weak >> symbols that may be unresolved at link time which result in an absolute >> relocation to 0. relocs_check.sh emits the following warning: >> >> "WARNING: 2 bad relocations >> c000000001a41478 R_PPC64_ADDR64 _binary__btf_vmlinux_bin_start >> c000000001a41480 R_PPC64_ADDR64 _binary__btf_vmlinux_bin_end" >> >> whereas those relocations are legitimate even for a relocatable kernel >> compiled with -pie option. >> >> relocs_check.sh already excluded some weak unresolved symbols explicitly: >> remove those hardcoded symbols and add some logic that parses the symbols >> using nm, retrieves all the weak unresolved symbols and excludes those from >> the list of the potential bad relocations. >> >> Reported-by: Stephen Rothwell >> Signed-off-by: Alexandre Ghiti >> --- >> >> Changes in v2: >> - Follow Stephen advice of using grep -F instead of looping over weak symbols >> using read, patch is way smaller and cleaner. >> - Add missing nm in comment >> >> arch/powerpc/Makefile.postlink | 4 ++-- >> arch/powerpc/tools/relocs_check.sh | 20 ++++++++++++-------- >> 2 files changed, 14 insertions(+), 10 deletions(-) >> ... > > Hi guys, > > > Any thought about that ? > > I do think this patch makes the whole check about absolute relocations > clearer. > And in the future, it will avoid anyone to spend some time on those > "bad" relocations > which actually aren't. Sorry I missed the v2. Will pick it up. cheers