Re: [RPC PATCH bpf-next] bpf: implement new BPF_CGROUP_INET_SOCK_POST_CONNECT

On Thu, Jan 14, 2021 at 8:27 PM Yonghong Song [off-list ref] wrote:

On 1/14/21 7:59 PM, Alexei Starovoitov wrote:

quoted

On Thu, Jan 14, 2021 at 7:51 PM Stanislav Fomichev [off-list ref] wrote:

quoted

quoted

quoted

         lock_sock(sock->sk);
         err = __inet_stream_connect(sock, uaddr, addr_len, flags, 0);

Similarly here, attaching fexit to __inet_stream_connect would execute
your BPF program at exactly the same time (and then you can check for
err value).

Or the point here is to have a more "stable" BPF program type?

Good suggestion, I can try to play with it, I think it should give me
all the info I need (I only need sock).
But yeah, I'd rather prefer a stable interface against stable
__sk_buff, but maybe fexit will also work.

Maybe we can add an extension to fentry/fexit that are cgroup scoped?
I think this will solve many such cases.

Currently, google is pushing LTO build of the kernel. If this happens,
it is possible one global function in one file (say a.c) might be
inlined into another file (say b.c). So in this particular case,
if the global function is inlined, fentry/fexit approach might be
missing some cases? We could mark certain *special purpose* function
as non-inline, but not sure whether this is scalable or not.

For this particular case I don't think it matters, right?
I'd like to fexit ip4_datagram_connect which is exported symbol,
it's accessed via proto->connect and there is no way it's
gonna be inlined. Unless our indirect call macros give clang
a hint :-/

I'm in general a bit concerned about using tracing calls for stuff
like that and depending on the non-uapi, but it's probably
time to give it a try and see how co-re works :-)