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=-5.5 required=3.0 tests=BAYES_00,MAILING_LIST_MULTI, NICE_REPLY_A,SPF_HELO_NONE,SPF_PASS,USER_AGENT_SANE_1 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 260C5C433B4 for ; Mon, 3 May 2021 07:59:44 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id E8E1D610C9 for ; Mon, 3 May 2021 07:59:43 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232959AbhECIAe (ORCPT ); Mon, 3 May 2021 04:00:34 -0400 Received: from mail-ej1-f46.google.com ([209.85.218.46]:34519 "EHLO mail-ej1-f46.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229817AbhECIAc (ORCPT ); Mon, 3 May 2021 04:00:32 -0400 Received: by mail-ej1-f46.google.com with SMTP id a4so6542638ejk.1; Mon, 03 May 2021 00:59:39 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:from:to:cc:references:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=5wQ58QmE9rd2XQ2cySSLGBm/LraaVfP/exkFVcgYCBo=; b=czHH6Y9Yv16rQcpHt/8cv7o1GALW6ggM/m7sqI7fvovTQaS3ajLvIiC7pr4rI0h7IY oQrbE+ZNl4SOMjDWo8Oi7upRb6fikb5ECbLwXybYlYHeOturg/UEH63erQ+ZsBvtoQ9L IdgWNeIYpeS8880NN/ogI5P1g+gx8wKizd9aPmK9vQH8jjuzWKflc8HsnoA5GGI2gg0h tWCZpRinNlZzXyB2cRKhpAE4Oz1m9r+5TatXCEsfERiw94GJdrWlwpvL9ku4NccQhZ1E rhjrQa8vvrsXEMDJiYSBZLWrb064edShb8ywRQJ5j677dwxJSNBeXLEYsy2qBPn3yxkb rR6Q== X-Gm-Message-State: AOAM533b8fys9zA+k/QhnvC73+UrbVahH+QExFEYTJ9K1/tGodJqxOGy 3aPEWJoRUH4jXv4fzp8X8zCDfjc+kM6ufg== X-Google-Smtp-Source: ABdhPJzZn5P+RvRABpxkhWuS8v8YFl2b/lIXQbQ+OWi7dMXF7ZzEpJw0BrP/34q8QDEp358leOt85Q== X-Received: by 2002:a17:906:5855:: with SMTP id h21mr15685833ejs.522.1620028778847; Mon, 03 May 2021 00:59:38 -0700 (PDT) Received: from ?IPv6:2a0b:e7c0:0:107::70f? ([2a0b:e7c0:0:107::70f]) by smtp.gmail.com with ESMTPSA id a22sm11793899edu.14.2021.05.03.00.59.37 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 03 May 2021 00:59:38 -0700 (PDT) Subject: Re: linux-next failing build due to missing cubictcp_state symbol From: Jiri Slaby To: =?UTF-8?Q?Michal_Such=c3=a1nek?= , Jiri Olsa Cc: Yonghong Song , linux-kernel@vger.kernel.org, Martin KaFai Lau , "David S. Miller" , Hideaki YOSHIFUJI , David Ahern , Jakub Kicinski , Alexei Starovoitov , Daniel Borkmann , Andrii Nakryiko , Song Liu , John Fastabend , KP Singh , netdev@vger.kernel.org, bpf@vger.kernel.org, Jiri Olsa , Jesper Dangaard Brouer References: <316e86f9-35cc-36b0-1594-00a09631c736@fb.com> <20210423175528.GF6564@kitsune.suse.cz> <20210425111545.GL15381@kitsune.suse.cz> <20210426113215.GM15381@kitsune.suse.cz> <20210426121220.GN15381@kitsune.suse.cz> <20210426121401.GO15381@kitsune.suse.cz> <49f84147-bf32-dc59-48e0-f89241cf6264@fb.com> <20210427121237.GK6564@kitsune.suse.cz> <20210430174723.GP15381@kitsune.suse.cz> <3d148516-0472-8f0a-085b-94d68c5cc0d5@suse.com> <6c14f3c8-7474-9f3f-b4a6-2966cb19e1ed@kernel.org> Message-ID: <4e051459-8532-7b61-c815-f3435767f8a0@kernel.org> Date: Mon, 3 May 2021 09:59:37 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.9.1 MIME-Version: 1.0 In-Reply-To: <6c14f3c8-7474-9f3f-b4a6-2966cb19e1ed@kernel.org> Content-Type: text/plain; charset=iso-8859-2; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Precedence: bulk List-ID: X-Mailing-List: netdev@vger.kernel.org On 03. 05. 21, 8:11, Jiri Slaby wrote: >>>>>> looks like vfs_truncate did not get into BTF data, >>>>>> I'll try to reproduce >> >> _None_ of the functions are generated by pahole -J from debuginfo on >> ppc64. debuginfo appears to be correct. Neither pahole -J fs/open.o >> works correctly. collect_functions in dwarves seems to be defunct on >> ppc64... "functions" array is bogus (so find_function -- the bsearch >> -- fails). > > It's not that bogus. I forgot an asterisk: >> #0  find_function (btfe=0x100269f80, name=0x10024631c "stream_open") >> at /usr/src/debug/dwarves-1.21-1.1.ppc64/btf_encoder.c:350 >> (gdb) p (*functions)@84 >> $5 = {{name = 0x7ffff68e0922 ".__se_compat_sys_ftruncate", addr = >> 75232, size = 72, sh_addr = 65536, generated = false}, { >>     name = 0x7ffff68e019e ".__se_compat_sys_open", addr = 80592, size >> = 216, sh_addr = 65536, generated = false}, { >>     name = 0x7ffff68e0076 ".__se_compat_sys_openat", addr = 80816, >> size = 232, sh_addr = 65536, generated = false}, { >>     name = 0x7ffff68e0908 ".__se_compat_sys_truncate", addr = 74304, >> size = 100, sh_addr = 65536, generated = false}, { > ... >>     name = 0x7ffff68e0808 ".stream_open", addr = 65824, size = 72, >> sh_addr = 65536, generated = false}, { > ... >>     name = 0x7ffff68e0751 ".vfs_truncate", addr = 73392, size = 544, >> sh_addr = 65536, generated = false}} > > The dot makes the difference, of course. The question is why is it > there? I keep looking into it. Only if someone has an immediate idea... Well, .vfs_truncate is in .text (and contains an ._mcount call). And vfs_truncate is in .opd (w/o an ._mcount call). Since setup_functions excludes all functions without the ._mcount call, is_ftrace_func later returns false for such functions and they are filtered before the BTF processing. Technically, get_vmlinux_addrs looks at a list of functions between __start_mcount_loc and __stop_mcount_loc and considers only the listed. I don't know what the correct fix is (exclude .opd functions from the filter?). Neither why cross compiler doesn't fail, nor why ebi v2 avoids this too. regards, -- js