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=-0.9 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, 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 743ABC352A3 for ; Tue, 11 Feb 2020 14:54:34 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 47FCC20675 for ; Tue, 11 Feb 2020 14:54:34 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b="HBuPh/34" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727264AbgBKOye (ORCPT ); Tue, 11 Feb 2020 09:54:34 -0500 Received: from us-smtp-2.mimecast.com ([205.139.110.61]:36769 "EHLO us-smtp-delivery-1.mimecast.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1729799AbgBKOyd (ORCPT ); Tue, 11 Feb 2020 09:54:33 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1581432871; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=d8NVLxwWTOxE6u7A/qti2YerzSZ7+x+aQJQi9mvS0cs=; b=HBuPh/34z+siAYHz8gkf7jyrXCftvjJWEj4Y4GYQPc8FT4xQTNV1B2qqxauxmsthF689aI eEMXK55kqVcgItoie/DZlqIugiOCWiqHHGK5aIo7JE/G9KFUXElL2iF6oHEOm+GyuEzibG 0E4IioAstvn2ykEvmRtgO+0wtv9BHG4= Received: from mail-lf1-f69.google.com (mail-lf1-f69.google.com [209.85.167.69]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-334--KFedCahN126PpoPnpXotA-1; Tue, 11 Feb 2020 09:54:29 -0500 X-MC-Unique: -KFedCahN126PpoPnpXotA-1 Received: by mail-lf1-f69.google.com with SMTP id y23so1152229lfh.7 for ; Tue, 11 Feb 2020 06:54:29 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:in-reply-to:references:date :message-id:mime-version:content-transfer-encoding; bh=d8NVLxwWTOxE6u7A/qti2YerzSZ7+x+aQJQi9mvS0cs=; b=a8DSijPfRdt7eaNXe6qr6v7lKlQZ0ouasBf18axFlD0W8njrjY4f5VZlsYotat3hYf IGVaNC/ya7ZeZxULoFzfLviiqEDIJG1rSPzuM/YqyQsv112HHxMbDgT0hFFUAfverGJQ Ajdere7UUr3J/hebMOQV4nbQiZKFrHnEk478J2qJT04o1w5vBLQ1t+RnFBGp+OalCiTf rbZm6BYAlqZaSb8pj9imFRigxdZiSekRdJKXR8wYfd+nSwUaO+9ViKstnwEy/HA+KmXK jjVdfFHupjZhOrUQLmbEv5N2d+UEVgydOos9UhYoNaelN4NaDR9d0se8r7N46MV6gcb6 8+0A== X-Gm-Message-State: APjAAAXhoSMR/LIPkNmmDttUNqcoOwozNQXZixZE4EqQzSVf89XeXnGR 1Qwzaq5t49aKIMKsZTVPdPgKQTUqxrDqFzxzCrwwcGSqrrjD7gD6VzJTUJlBSo/jy4Y8wXOd5GO yAuKU6b6mdenw X-Received: by 2002:a19:7401:: with SMTP id v1mr3843617lfe.129.1581432868334; Tue, 11 Feb 2020 06:54:28 -0800 (PST) X-Google-Smtp-Source: APXvYqxJ0zzuLIZLPJvyWS7ogYan9maBy3tqsqdTMzYz5/ikzYB5eKiGpt/P2xxEQRIa4WNjFCOqwg== X-Received: by 2002:a19:7401:: with SMTP id v1mr3843611lfe.129.1581432868083; Tue, 11 Feb 2020 06:54:28 -0800 (PST) Received: from alrua-x1.borgediget.toke.dk ([45.145.92.2]) by smtp.gmail.com with ESMTPSA id w6sm1934253lfq.95.2020.02.11.06.54.27 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 11 Feb 2020 06:54:27 -0800 (PST) Received: by alrua-x1.borgediget.toke.dk (Postfix, from userid 1000) id 8BBDC180365; Tue, 11 Feb 2020 15:54:26 +0100 (CET) From: Toke =?utf-8?Q?H=C3=B8iland-J=C3=B8rgensen?= To: Eelco Chaudron , Andrii Nakryiko Cc: Andrii Nakryiko , Xdp , bpf@vger.kernel.org Subject: Re: Need a way to modify the section name for a read program object In-Reply-To: <0D7B2C92-FC75-4167-A973-EB0AD84FC878@redhat.com> References: <874kw664dy.fsf@toke.dk> <87zhdyduho.fsf@toke.dk> <0D7B2C92-FC75-4167-A973-EB0AD84FC878@redhat.com> X-Clacks-Overhead: GNU Terry Pratchett Date: Tue, 11 Feb 2020 15:54:26 +0100 Message-ID: <87wo8ti38d.fsf@toke.dk> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Sender: bpf-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: bpf@vger.kernel.org "Eelco Chaudron" writes: > On 4 Feb 2020, at 20:32, Andrii Nakryiko wrote: > >> On Tue, Feb 4, 2020 at 11:27 AM Toke H=C3=B8iland-J=C3=B8rgensen=20 >> wrote: >>> >>> Andrii Nakryiko writes: >>> >>>> On 2/4/20 2:19 AM, Toke H=C3=B8iland-J=C3=B8rgensen wrote: >>>>> "Eelco Chaudron" writes: >>>>> >>>>>> Hi All, >>>>>> >>>>>> I'm trying to write an xdpdump like utility and have some missing=20 >>>>>> part >>>>>> in libbpf to change the fentry/FUNCTION section name before=20 >>>>>> loading the >>>>>> trace program. >>>>>> >>>>>> In short, I have an eBPF program that has a section name like >>>>>> "fentry/FUNCTION" where FUNCTION needs to be replaced by the name=20 >>>>>> of the >>>>>> XDP program loaded in the interfaces its start function. >>>>>> >>>>>> The code for loading the ftrace part is something like: >>>>>> >>>>>> open_opts.attach_prog_fd =3D bpf_prog_get_fd_by_id(info.id); >>>>>> trace_obj =3D bpf_object__open_file("xdpdump_bpf.o",=20 >>>>>> &open_opts); >>>>>> >>>>>> trace_prog_fentry =3D=20 >>>>>> bpf_object__find_program_by_title(trace_obj, >>>>>> "fentry/FUNCTION"); >>>>>> >>>>>> /* Here I need to replace the trace_prog_fentry->section_name=20 >>>>>> =3D >>>>>> "fentry/ */ >>>>>> >>>>>> bpf_object__load(trace_obj); >>>>>> trace_link_fentry =3D=20 >>>>>> bpf_program__attach_trace(trace_prog_fentry); >>>>>> >>>>>> >>>>>> See the above, I would like to change the section_name but there=20 >>>>>> is no >>>>>> API to do this, and of course, the struct bpf_program is >>>>>> implementation-specific. >>>>>> >>>>>> Any idea how I would work around this, or what extension to libbpf=20 >>>>>> can >>>>>> be suggested to support this? >>>>> >>>>> I think what's missing is a way for the caller to set the=20 >>>>> attach_btf_id. >>>>> Currently, libbpf always tries to discover this based on the=20 >>>>> section >>>>> name (see libbpf_find_attach_btf_id()). I think the right way to=20 >>>>> let the >>>>> caller specify this is not to change the section name, though, but=20 >>>>> just >>>>> to expose a way to explicitly set the btf_id (which the caller can=20 >>>>> then >>>>> go find on its own). >>>> >>>> Yes, I agree, section name should be treated as an immutable=20 >>>> identifier >>>> and a (overrideable) hint to libbpf. >>>> >>>>> >>>>> Not sure if it would be better with a new open_opt (to mirror >>>>> attach_prog_fd), or just a setter=20 >>>>> (bpf_program__set_attach_btf_id()?). >>>>> Or maybe both? Andrii, WDYT? >>>> >>>> open_opts is definitely wrong way to do this, because open_opts=20 >>>> apply to >>>> all BPF programs, while this should be per-program. >>> >>> Yes, of course; silly me :) >>> >>>> I'm also not sure having API that allows to specify BTF type ID is=20 >>>> the >>>> best, probably better to let libbpf perform the search by name. So=20 >>>> I'd >>>> say something like this: >>>> >>>> int bpf_program__set_attach_target(int attach_prog_fd, const char >>>> *attach_func_name) >>>> >>>> This should handle customizing all the tp_btf/fentry/fexit/freplace=20 >>>> BPF >>>> programs we have. >>> >>> Right, that makes sense; I think that would cover it (apart from your >>> function signature missing a struct bpf_program argument). >> >> great! and, ha-ha, too object-oriented thinking ;) > > Thanks for your feedback, assuming you are not working on it, I=E2=80=99l= l=20 > implement/test it and sent out a patch. Please do! :) -Toke