All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Eelco Chaudron" <echaudro@redhat.com>
To: "Jiri Olsa" <jolsa@redhat.com>
Cc: "Yonghong Song" <yhs@fb.com>,
	bpf@vger.kernel.org, netdev@vger.kernel.org, ast@kernel.org,
	daniel@iogearbox.net, kafai@fb.com, songliubraving@fb.com,
	andriin@fb.com, toke@redhat.com
Subject: Re: fentry/fexit attach to EXT type XDP program does not work
Date: Mon, 27 Jul 2020 09:59:14 +0200	[thread overview]
Message-ID: <5CF6086F-412C-4934-9AC6-4B1821ADDF74@redhat.com> (raw)
In-Reply-To: <20200726122450.GC1175442@krava>



On 26 Jul 2020, at 14:24, Jiri Olsa wrote:

> On Tue, Jun 09, 2020 at 10:52:34AM +0200, Eelco Chaudron wrote:
>
> SNIP
>
>>>>    libbpf: failed to load object 'test_xdp_bpf2bpf'
>>>>    libbpf: failed to load BPF skeleton 'test_xdp_bpf2bpf': -4007
>>>>    test_xdp_fentry_ext:FAIL:__load ftrace skeleton failed
>>>>    #91 xdp_fentry_ext:FAIL
>>>>    Summary: 0/0 PASSED, 0 SKIPPED, 1 FAILED
>>>>
>>>> Any idea what could be the case here? The same fentry/fexit attach
>>>> code works fine in the xdp_bpf2bpf.c tests case.
>>
>> <SNIP>
>>>
>>> I think this is not supported now. That is, you cannot attach a 
>>> fentry
>>> trace
>>> to the EXT program. The current implementation for fentry program 
>>> simply
>>> trying to find and match the signature of freplace program which by
>>> default
>>> is a pointer to void.
>>>
>>> It is doable in that in kernel we could recognize to-be-attached 
>>> program
>>> is
>>> a freplace and further trace down to find the real signature. The
>>> related
>>> kernel function is btf_get_prog_ctx_type(). You can try to implement 
>>> by
>>> yourself
>>> or I can have a patch for this once bpf-next opens.
>>
>> I’m not familiar with this area of the code, so if you could 
>> prepare a patch
>> that would nice.
>> You can also send it to me before bpf-next opens and I can verify it, 
>> and
>> clean up the self-test so it can be included as well.
>>
>
> hi,
> it seems that you cannot exten fentry/fexit programs,
> but it's possible to attach fentry/fexit to ext program.
>
>    /* Program extensions can extend all program types
>     * except fentry/fexit. The reason is the following.
>     * The fentry/fexit programs are used for performance
>     * analysis, stats and can be attached to any program
>     * type except themselves. When extension program is
>     * replacing XDP function it is necessary to allow
>     * performance analysis of all functions. Both original
>     * XDP program and its program extension. Hence
>     * attaching fentry/fexit to BPF_PROG_TYPE_EXT is
>     * allowed. If extending of fentry/fexit was allowed it
>     * would be possible to create long call chain
>     * fentry->extension->fentry->extension beyond
>     * reasonable stack size. Hence extending fentry is not
>     * allowed.
>     */
>
> I changed fexit_bpf2bpf.c test just to do a quick check
> and it seems to work:

Hi Jiri this is exactly what I’m trying, however when you do this 
where the first argument is a pointer to some context data which you are 
accessing it’s failing in the verifier.
This is a link to the original email, which has a test patch attached 
that will show the failure when trying to load/attach the fentry 
function and access the context:

https://lore.kernel.org/bpf/159162546868.10791.12432342618156330247.stgit@ebuild/

//Eelco

>
>   # echo > /sys/kernel/debug/tracing/trace
>   #  ./test_progs -t fexit_bpf2bpf
>   #25 fexit_bpf2bpf:OK
>   Summary: 1/0 PASSED, 0 SKIPPED, 0 FAILED
>   # cat /sys/kernel/debug/tracing/trace | tail -2
>            <...>-75365 [012] d... 313932.416780: bpf_trace_printk: 
> ENTRY val 123
>            <...>-75365 [012] d... 313932.416784: bpf_trace_printk: 
> EXIT  val 123, ret 1
>
< SNIP>


  reply	other threads:[~2020-07-27  7:59 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-06-08 14:11 fentry/fexit attach to EXT type XDP program does not work Eelco Chaudron
2020-06-08 16:58 ` Yonghong Song
2020-06-09  8:52   ` Eelco Chaudron
2020-07-26 12:24     ` Jiri Olsa
2020-07-27  7:59       ` Eelco Chaudron [this message]
2020-07-27 14:53         ` Jiri Olsa
2020-07-29  6:23           ` Eelco Chaudron
2020-07-29  8:09             ` Jiri Olsa

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=5CF6086F-412C-4934-9AC6-4B1821ADDF74@redhat.com \
    --to=echaudro@redhat.com \
    --cc=andriin@fb.com \
    --cc=ast@kernel.org \
    --cc=bpf@vger.kernel.org \
    --cc=daniel@iogearbox.net \
    --cc=jolsa@redhat.com \
    --cc=kafai@fb.com \
    --cc=netdev@vger.kernel.org \
    --cc=songliubraving@fb.com \
    --cc=toke@redhat.com \
    --cc=yhs@fb.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.