On Thu, Jan 14, 2021 at 8:27 PM Yonghong Song <yhs@xxxxxx> wrote: > > > > On 1/14/21 7:59 PM, Alexei Starovoitov wrote: > > On Thu, Jan 14, 2021 at 7:51 PM Stanislav Fomichev <sdf@xxxxxxxxxx> wrote: > >>>> > >>>> 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 :-)
