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=-6.8 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SIGNED_OFF_BY, SPF_HELO_NONE,SPF_PASS,USER_AGENT_GIT autolearn=unavailable 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 4B35BC32771 for ; Fri, 24 Jan 2020 09:33:29 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 18F152070A for ; Fri, 24 Jan 2020 09:33:29 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1579858409; bh=k6hM2ffp9xfbNIFXsjABnq/7bBzSMoNDBNeX2sLKJfk=; h=From:To:Cc:Subject:Date:In-Reply-To:References:List-ID:From; b=2IbC4/Fkf2bE6eSQL+UutjQLs3XUjGePWpZS4HSLts3YOMfN37fk+LzaZHmS4c6uF OeV7+Cp/rYuE0racPG2KROfVi32dexU240A47Lzpho82Yack6BM+xEsscNgVLWCCJn eOc9MI3n2wyBvEZHulD6cXtBs9ws/2bNY8Kda7Zs= Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1725821AbgAXJdZ (ORCPT ); Fri, 24 Jan 2020 04:33:25 -0500 Received: from mail.kernel.org ([198.145.29.99]:59814 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1729715AbgAXJdY (ORCPT ); Fri, 24 Jan 2020 04:33:24 -0500 Received: from localhost (unknown [145.15.244.15]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id A5FDF208C4; Fri, 24 Jan 2020 09:33:22 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1579858403; bh=k6hM2ffp9xfbNIFXsjABnq/7bBzSMoNDBNeX2sLKJfk=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=yOi8JAlFmIR90491rwMamNJuQTCsHTgTU3RdPakv91aOrCH32CQz9DPRHKXZF/mzV w+uQPqcCheOLc2Aw3mJBRsPoG2HmDuqgsvSvQclicL6GOHFX58XWPQqsdGs11nRp4p Bj2IGtdSABetCnjzs8PX3D7RZfdfYhs98rlN9R6s= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Jesper Dangaard Brouer , Alexei Starovoitov , =?UTF-8?q?Toke=20H=C3=B8iland-J=C3=B8rgensen?= , Andrii Nakryiko Subject: [PATCH 5.4 010/102] samples/bpf: Fix broken xdp_rxq_info due to map order assumptions Date: Fri, 24 Jan 2020 10:30:11 +0100 Message-Id: <20200124092807.703448130@linuxfoundation.org> X-Mailer: git-send-email 2.25.0 In-Reply-To: <20200124092806.004582306@linuxfoundation.org> References: <20200124092806.004582306@linuxfoundation.org> User-Agent: quilt/0.66 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Sender: stable-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: stable@vger.kernel.org From: Jesper Dangaard Brouer commit edbca120a8cdfa5a5793707e33497aa5185875ca upstream. In the days of using bpf_load.c the order in which the 'maps' sections were defines in BPF side (*_kern.c) file, were used by userspace side to identify the map via using the map order as an index. In effect the order-index is created based on the order the maps sections are stored in the ELF-object file, by the LLVM compiler. This have also carried over in libbpf via API bpf_map__next(NULL, obj) to extract maps in the order libbpf parsed the ELF-object file. When BTF based maps were introduced a new section type ".maps" were created. I found that the LLVM compiler doesn't create the ".maps" sections in the order they are defined in the C-file. The order in the ELF file is based on the order the map pointer is referenced in the code. This combination of changes lead to xdp_rxq_info mixing up the map file-descriptors in userspace, resulting in very broken behaviour, but without warning the user. This patch fix issue by instead using bpf_object__find_map_by_name() to find maps via their names. (Note, this is the ELF name, which can be longer than the name the kernel retains). Fixes: be5bca44aa6b ("samples: bpf: convert some XDP samples from bpf_load to libbpf") Fixes: 451d1dc886b5 ("samples: bpf: update map definition to new syntax BTF-defined map") Signed-off-by: Jesper Dangaard Brouer Signed-off-by: Alexei Starovoitov Acked-by: Toke Høiland-Jørgensen Acked-by: Andrii Nakryiko Link: https://lore.kernel.org/bpf/157529025128.29832.5953245340679936909.stgit@firesoul Signed-off-by: Greg Kroah-Hartman --- samples/bpf/xdp_rxq_info_user.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) --- a/samples/bpf/xdp_rxq_info_user.c +++ b/samples/bpf/xdp_rxq_info_user.c @@ -489,9 +489,9 @@ int main(int argc, char **argv) if (bpf_prog_load_xattr(&prog_load_attr, &obj, &prog_fd)) return EXIT_FAIL; - map = bpf_map__next(NULL, obj); - stats_global_map = bpf_map__next(map, obj); - rx_queue_index_map = bpf_map__next(stats_global_map, obj); + map = bpf_object__find_map_by_name(obj, "config_map"); + stats_global_map = bpf_object__find_map_by_name(obj, "stats_global_map"); + rx_queue_index_map = bpf_object__find_map_by_name(obj, "rx_queue_index_map"); if (!map || !stats_global_map || !rx_queue_index_map) { printf("finding a map in obj file failed\n"); return EXIT_FAIL;