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.3 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS, USER_AGENT_SANE_2 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 85643C49361 for ; Thu, 17 Jun 2021 10:44:48 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 63E1F60FDA for ; Thu, 17 Jun 2021 10:44:48 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231756AbhFQKqy convert rfc822-to-8bit (ORCPT ); Thu, 17 Jun 2021 06:46:54 -0400 Received: from wildebeest.demon.nl ([212.238.236.112]:52526 "EHLO gnu.wildebeest.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231260AbhFQKqw (ORCPT ); Thu, 17 Jun 2021 06:46:52 -0400 Received: from tarox.wildebeest.org (83-87-18-245.cable.dynamic.v4.ziggo.nl [83.87.18.245]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by gnu.wildebeest.org (Postfix) with ESMTPSA id 1936F3000D18; Thu, 17 Jun 2021 12:44:43 +0200 (CEST) Received: by tarox.wildebeest.org (Postfix, from userid 1000) id CD625413C28B; Thu, 17 Jun 2021 12:44:42 +0200 (CEST) Message-ID: <46f035765fa4ee139fa5ec387d9395f1f466bb5e.camel@klomp.org> Subject: Re: [PATCH bpf v1] bpf: fix libelf endian handling in resolv_btfids From: Mark Wielaard To: Jiri Olsa , Tony Ambardar Cc: Yonghong Song , Daniel Borkmann , Alexei Starovoitov , Andrii Nakryiko , bpf , Networking , Stable , Jiri Olsa , Frank Eigler Date: Thu, 17 Jun 2021 12:44:42 +0200 In-Reply-To: References: <20210616092521.800788-1-Tony.Ambardar@gmail.com> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8BIT X-Mailer: Evolution 3.28.5 (3.28.5-10.el7) Mime-Version: 1.0 Precedence: bulk List-ID: X-Mailing-List: bpf@vger.kernel.org On Thu, 2021-06-17 at 11:10 +0200, Jiri Olsa wrote: > On Wed, Jun 16, 2021 at 03:09:13PM -0700, Tony Ambardar wrote: > > On Wed, 16 Jun 2021 at 09:38, Jiri Olsa wrote: > > > I have no idea how is this handled in libelf (perhaps it's ok), > > > but just that comment above suggests it could be also 64 bits, > > > cc-ing Frank and Mark for more insight > > > > > > > One other area I'd like to confirm is with section compression. Is > > it safe > > to ignore this for .BTF_ids? I've done so because > > include/linux/btf_ids.h > > appears to define the section with SHF_ALLOC flag set, which is > > incompatible with compression based on "libelf.h" comments. > > not sure what you mean.. where it wouldn't be safe? > what workflow/processing I haven't looked at the code/patch, but Tony is correct that if a section has SHF_ALLOC set it cannot be a compressed section. SHF_COMPRESSED is incompatbile with SHF_ALLOC (or SHF_NOBITS) sections, because it would be unclear what a loader would need to do with them (uncompress the data first, then map it, or map the compressed data as is into memory). So ignoring whether or not a section is compressed for SHF_ALLOC sections is fine. Cheers, Mark