bpf.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Alexei Starovoitov <ast@fb.com>
To: Martin Lau <kafai@fb.com>,
	"bpf@vger.kernel.org" <bpf@vger.kernel.org>,
	"netdev@vger.kernel.org" <netdev@vger.kernel.org>
Cc: Daniel Borkmann <daniel@iogearbox.net>,
	David Miller <davem@davemloft.net>,
	Kernel Team <Kernel-team@fb.com>
Subject: Re: [PATCH bpf-next] bpf: Prepare btf_ctx_access for non raw_tp use case.
Date: Thu, 24 Oct 2019 21:39:47 +0000	[thread overview]
Message-ID: <f229a628-52fc-2728-6dd8-1c47a4962201@fb.com> (raw)
In-Reply-To: <20191024201524.685995-1-kafai@fb.com>

On 10/24/19 1:15 PM, Martin KaFai Lau wrote:
> This patch makes a few changes to btf_ctx_access() to prepare
> it for non raw_tp use case.
> 
> btf_ctx_access() only needs the attach_btf_id from prog.  Hence, this patch
> only passes the attach_btf_id instead of passing prog.  It allows other
> use cases when the prog->aux->attach_btf_id may not be a typedef.
> For example, in the future, a bpf_prog can attach to
> "struct tcp_congestion_ops" and its attach_btf_id is
> pointing to the btf_id of "struct tcp_congestion_ops".
> 
> While at it, allow btf_ctx_access to directly take a BTF_KIND_FUNC_PROTO
> btf_id.  It is to prepare for a later patch that does not need a "typedef"
> to figure out the func_proto.  For example, when attaching a bpf_prog
> to an ops in "struct tcp_congestion_ops", the func_proto can be
> found directly by following the members of "struct tcp_congestion_ops".
> 
> For the no typedef use case, there is no extra first arg.  Hence, this
> patch only limits the skip arg logic to raw_tp only.
> 
> Since a BTF_KIND_FUNC_PROTO type does not have a name (i.e. "(anon)"),
> an optional name arg is added also.  If specified, this name will be used
> in the bpf_log() message instead of the type's name obtained from btf_id.
> For example, the function pointer member name of
> "struct tcp_congestion_ops" can be used.
> 
> Signed-off-by: Martin KaFai Lau <kafai@fb.com>

...

> +static bool btf_type_is_typedef(const struct btf_type *t)
> +{
> +	return BTF_INFO_KIND(t->info) == BTF_KIND_TYPEDEF;
> +}

yeah. I was to lazy to add it. Thanks for doing this cleanup.

> @@ -3459,37 +3464,49 @@ bool btf_ctx_access(int off, int size, enum bpf_access_type type,
>   	}
>   
>   	t = btf_type_by_id(btf_vmlinux, btf_id);
> -	if (!t || BTF_INFO_KIND(t->info) != BTF_KIND_TYPEDEF) {
> +	if (!t || (!btf_type_is_typedef(t) && !btf_type_is_func_proto(t))) {
>   		bpf_log(log, "btf_id is invalid\n");
>   		return false;
>   	}
>   
>   	tname = __btf_name_by_offset(btf_vmlinux, t->name_off);
> -	if (strncmp(prefix, tname, sizeof(prefix) - 1)) {
> -		bpf_log(log, "btf_id points to wrong type name %s\n", tname);
> -		return false;
> +	if (btf_type_is_typedef(t)) {

This check cannot be done conditionally.
Otherwise raw_tp bpf prog with partially "invalid" attach_btf_id
will successfully load, but will fail to attach to raw_tp
in raw_tp_open command.
I think better way is to move this check early into the verifier.
That will speed up this function as well that is called
multiple times for ever ctx access in the prog.
Thanks!

      reply	other threads:[~2019-10-24 21:40 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-10-24 20:15 [PATCH bpf-next] bpf: Prepare btf_ctx_access for non raw_tp use case Martin KaFai Lau
2019-10-24 21:39 ` Alexei Starovoitov [this message]

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=f229a628-52fc-2728-6dd8-1c47a4962201@fb.com \
    --to=ast@fb.com \
    --cc=Kernel-team@fb.com \
    --cc=bpf@vger.kernel.org \
    --cc=daniel@iogearbox.net \
    --cc=davem@davemloft.net \
    --cc=kafai@fb.com \
    --cc=netdev@vger.kernel.org \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).