Received: by 2002:a25:8b91:0:0:0:0:0 with SMTP id j17csp1952327ybl; Sat, 11 Jan 2020 06:08:23 -0800 (PST) X-Google-Smtp-Source: APXvYqzq1xSOVtclhxa+lMC82qY7eWzzOf2L11qC4qFHNOb0FeKfwDX7vEhBoeI/WcTQNHXyNO8q X-Received: by 2002:aca:c74e:: with SMTP id x75mr6606672oif.140.1578751703706; Sat, 11 Jan 2020 06:08:23 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1578751703; cv=none; d=google.com; s=arc-20160816; b=V+bhsI5EGJenHkG/vR2GnUSKMOTuwB8oKkOxJ1Ui+0iyDtzmgzhYQC3aqKZ/z2psSX uAAVu4v8I0uaau/Cuz7IAxofJf9ko48DxYrFjVSc+BkhTnZF16giC0HmWRFkuux2xy0o k1maIaVlQ03mFK3ieST6cfmnQ8R3iDUaNyFGElH5f6n0z2NTwpWcCbRcuyMAr9Yp/wS9 G0HpERp4tRXyX8zf1zEw0A/FZqKWkFUJEoAXI9DW+pJJIREJm2I31tCxQm437tZDCNSv le3BQ38yyr3STVHlTE6eXLf87kQrVafOHnLSzqM66NvqqsPgb2C8/U0OKCvBHZQ6aw+W TFuw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-language :content-transfer-encoding:in-reply-to:mime-version:user-agent:date :message-id:from:references:cc:to:subject; bh=Dape5D8w0L+DxpNK7INIxah3q4zxQ9Eplavd2b/A6X8=; b=v5nU9PcYbtl9ZB3EE7XnR7Op8EfNNDs9jsXHIRFkU5/6C4xdEWnDvXtbf7/823aR/l NX5Qv0N+4r47tXxa0xBrZYTAdwK1tStQUwiiTYgE8ah3WXBC43EdQ7/XtGjqmM8YEsu7 HA7J5IgVXXokUYqfcww1jkbZuDo6L/pohym1h/969EFEiVMJmxpmFFv+gU0Ve2FgKoZ/ 05rnhf09/Yp/AvUfrtM3uQxpZEJJJwqctqulkAb/B4DuXEy1to/TR6UH2ALhX6zwneUV ZqBIgwCoxDNJs0z0MblEkaqAoPsfTH7XUHVwO5l7XUkwSX+lZxFo3A6kgPSh9DzlDVat Lt0Q== 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 Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id f15si3119567oij.160.2020.01.11.06.08.00; Sat, 11 Jan 2020 06:08:23 -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 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1729672AbgAKOGH (ORCPT + 99 others); Sat, 11 Jan 2020 09:06:07 -0500 Received: from relay2-d.mail.gandi.net ([217.70.183.194]:59487 "EHLO relay2-d.mail.gandi.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1729622AbgAKOGH (ORCPT ); Sat, 11 Jan 2020 09:06:07 -0500 X-Originating-IP: 79.86.19.127 Received: from [192.168.0.12] (127.19.86.79.rev.sfr.net [79.86.19.127]) (Authenticated sender: alexandre@ghiti.fr) by relay2-d.mail.gandi.net (Postfix) with ESMTPSA id EE08540002; Sat, 11 Jan 2020 14:06:00 +0000 (UTC) Subject: Re: linux-next: build warning after merge of the bpf-next tree To: Alexei Starovoitov Cc: Stephen Rothwell , Daniel Borkmann , Alexei Starovoitov , Networking , Linux Next Mailing List , Linux Kernel Mailing List , ppc-dev , linux-arm-kernel@lists.infradead.org, zong.li@sifive.com, Andrii Nakryiko References: <20191018105657.4584ec67@canb.auug.org.au> <20191028110257.6d6dba6e@canb.auug.org.au> From: Alexandre Ghiti Message-ID: <3e6f298c-e428-fdee-47a8-14addc581501@ghiti.fr> Date: Sat, 11 Jan 2020 09:06:00 -0500 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 1/10/20 6:18 PM, Alexei Starovoitov wrote: > On Fri, Jan 10, 2020 at 2:28 PM Alexandre Ghiti wrote: >> Hi guys, >> >> On 10/27/19 8:02 PM, Stephen Rothwell wrote: >>> Hi all, >>> >>> On Fri, 18 Oct 2019 10:56:57 +1100 Stephen Rothwell wrote: >>>> Hi all, >>>> >>>> After merging the bpf-next tree, today's linux-next build (powerpc >>>> ppc64_defconfig) produced this warning: >>>> >>>> WARNING: 2 bad relocations >>>> c000000001998a48 R_PPC64_ADDR64 _binary__btf_vmlinux_bin_start >>>> c000000001998a50 R_PPC64_ADDR64 _binary__btf_vmlinux_bin_end >>>> >>>> Introduced by commit >>>> >>>> 8580ac9404f6 ("bpf: Process in-kernel BTF") >>> This warning now appears in the net-next tree build. >>> >>> >> I bump that thread up because Zong also noticed that 2 new relocations for >> those symbols appeared in my riscv relocatable kernel branch following >> that commit. >> >> I also noticed 2 new relocations R_AARCH64_ABS64 appearing in arm64 kernel. >> >> Those 2 weak undefined symbols have existed since commit >> 341dfcf8d78e ("btf: expose BTF info through sysfs") but this is the fact >> to declare those symbols into btf.c that produced those relocations. >> >> I'm not sure what this all means, but this is not something I expected >> for riscv for >> a kernel linked with -shared/-fpie. Maybe should we just leave them to >> zero ? >> >> I think that deserves a deeper look if someone understands all this >> better than I do. > Are you saying there is a warning for arm64 as well? Nop. > Can ppc folks explain the above warning? > What does it mean "2 bad relocations"? This is what I'd like to understand too, it is not clear in the ppc tool that outputs this message why it is considered 'bad'. > The code is doing: > extern char __weak _binary__btf_vmlinux_bin_start[]; > extern char __weak _binary__btf_vmlinux_bin_end[]; > Since they are weak they should be zero when not defined. > What's the issue? There likely is no issue, I just want to make sure those relocations are legitimate and I want to understand what we should do with those. At the moment arm64 does not relocate those at runtime and purely ignore them: is this the right thing to do ?