BPF List
 help / color / mirror / Atom feed
From: John Fastabend <john.fastabend@gmail.com>
To: Yonghong Song <yhs@meta.com>,
	John Fastabend <john.fastabend@gmail.com>,
	Yonghong Song <yhs@fb.com>,
	bpf@vger.kernel.org
Cc: Alexei Starovoitov <ast@kernel.org>,
	Andrii Nakryiko <andrii@kernel.org>,
	Daniel Borkmann <daniel@iogearbox.net>,
	kernel-team@fb.com, Kumar Kartikeya Dwivedi <memxor@gmail.com>,
	Martin KaFai Lau <martin.lau@kernel.org>
Subject: Re: [PATCH bpf-next v4 0/4] bpf: Implement two type cast kfuncs
Date: Mon, 21 Nov 2022 17:48:28 -0800	[thread overview]
Message-ID: <637c2a6c4b042_18ed92085f@john.notmuch> (raw)
In-Reply-To: <2c4f8cac-6935-2c72-cc1b-34a34708e127@meta.com>

Yonghong Song wrote:
> 
> 
> On 11/20/22 6:10 PM, John Fastabend wrote:
> > Yonghong Song wrote:
> >> Currenty, a non-tracing bpf program typically has a single 'context' argument
> >> with predefined uapi struct type. Following these uapi struct, user is able
> >> to access other fields defined in uapi header. Inside the kernel, the
> >> user-seen 'context' argument is replaced with 'kernel context' (or 'kctx'
> >> in short) which can access more information than what uapi header provides.
> >> To access other info not in uapi header, people typically do two things:
> >>    (1). extend uapi to access more fields rooted from 'context'.
> >>    (2). use bpf_probe_read_kernl() helper to read particular field based on
> >>      kctx.

[...]

> >  From myside this allows us to pull in the dev info and from that get
> > netns so fixes a gap we had to split into a kprobe + xdp.
> > 
> > If we can get a pointer to the recv queue then with a few reads we
> > get the hash, vlan, etc. (see timestapm thread)
> 
> Thanks, John. Glad to see it is useful.
> 
> > 
> > And then last bit is if we can get a ptr to the net ns list, plus
> 
> Unfortunately, currently vmlinux btf does not have non-percpu global
> variables, so net_namespace_list is not available to bpf programs.
> But I think we could do the following with a little bit user space
> initial involvement as a workaround.

What would you think of another kfunc, bpf_get_global_var() to fetch
the global reference and cast it with a type? I think even if you
had it in BTF you would still need some sort of helper otherwise
how would you know what scope of the var should be and get it
correct in type checker as a TRUSTED arg? I think for my use case
UNTRUSTED is find, seeing we do it with probe_reads already, but
getting a TRUSTED arg seems nicer given it can be known correct
from kernel side.

I was thinking something like,

  struct net *head = bpf_get_global_var(net_namespace_list,
				bpf_core_type_id_kernel(struct *net));

> 
> In bpf program, we could have global variable
>    __u64 net_namespace_list;
> and user space can lookup /proc/kallsyms for net_namespace_list
> and assign it to bpf program 'net_namespace_list' before prog load.
> 
> After that, you could implement an in-bpf-prog iterator with bounded
> loop to ensure eventual ending. You can use
>    struct list_head *lh = bpf_rdonly_cast(net_namespace_list, 
> struct_list_head_btf_id)
> cast to struct list_head pointer. From there you can tracing down
> the list with needed bpf_rdonly_cast() for casting to element type.
> 
> > the rcu patch we can build the net ns iterator directly in BPF
> 
> I just posted rcu patch 
> https://lore.kernel.org/bpf/20221121170515.1193967-1-yhs@fb.com/
> Please help take a look whether it can serve your need.

Will look.

  reply	other threads:[~2022-11-22  1:48 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-11-20 19:54 [PATCH bpf-next v4 0/4] bpf: Implement two type cast kfuncs Yonghong Song
2022-11-20 19:54 ` [PATCH bpf-next v4 1/4] bpf: Add support for kfunc set with common btf_ids Yonghong Song
2022-11-20 19:54 ` [PATCH bpf-next v4 2/4] bpf: Add a kfunc to type cast from bpf uapi ctx to kernel ctx Yonghong Song
2022-11-20 19:54 ` [PATCH bpf-next v4 3/4] bpf: Add a kfunc for generic type cast Yonghong Song
2022-11-20 20:16   ` Alexei Starovoitov
2022-11-20 20:49     ` Kumar Kartikeya Dwivedi
2022-11-20 22:34       ` Alexei Starovoitov
2022-11-20 23:32         ` Alexei Starovoitov
2022-11-20 23:47           ` Alexei Starovoitov
2022-11-20 19:54 ` [PATCH bpf-next v4 4/4] bpf: Add type cast unit tests Yonghong Song
2022-11-21  0:00 ` [PATCH bpf-next v4 0/4] bpf: Implement two type cast kfuncs patchwork-bot+netdevbpf
2022-11-21  2:10 ` John Fastabend
2022-11-21 17:29   ` Yonghong Song
2022-11-22  1:48     ` John Fastabend [this message]
2022-11-22  4:52       ` Alexei Starovoitov
2022-11-23  3:18         ` John Fastabend
2022-11-23 20:46           ` Alexei Starovoitov
2022-11-29 16:30             ` Alan Maguire

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=637c2a6c4b042_18ed92085f@john.notmuch \
    --to=john.fastabend@gmail.com \
    --cc=andrii@kernel.org \
    --cc=ast@kernel.org \
    --cc=bpf@vger.kernel.org \
    --cc=daniel@iogearbox.net \
    --cc=kernel-team@fb.com \
    --cc=martin.lau@kernel.org \
    --cc=memxor@gmail.com \
    --cc=yhs@fb.com \
    --cc=yhs@meta.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox