On Mon, Sep 30, 2024 at 9:06 PM Abhik Sen <abhikisraina@xxxxxxxxx> wrote: > > Thanks for the reply. > > Yes you did understand the concern I was having, more precisely if I > have a bpf_link from libbpf's bpf_program__attach_uprobe_opts(), on a > binary path say "proc/<PID_12>/root/lib64/libpam.so", and the > namespace containing <PID_12> is terminated, thereby killing the > process <PID_12>, what happens to the bpf_link? > > If I understood you correctly then even in this scenario one should > explicitly call the bpf_link__destroy on that link? Yes, because the file is still there, and the BPF program is still attached. It's just that the file is not visible in the file system anymore. > Thanks. > > On Sat, Sep 28, 2024 at 4:50 AM Andrii Nakryiko > <andrii.nakryiko@xxxxxxxxx> wrote: > > > > On Sun, Sep 22, 2024 at 10:18 PM Abhik Sen <abhikisraina@xxxxxxxxx> wrote: > > > > > > Hello Team! > > > > > > We were looking into the bpf-link and bpf-program-attach-uprobe-opts > > > > Is the API actually called "bpf-program-attach-uprobe-opts" or we are > > talking about libbpf's bpf_program__attach_uprobe_opts()? In the > > former case, which library and API are we talking about? In the latter > > case, why rewrite API names and cause unnecessary confusion? > > > > > implementation and wanted to know if a bpf-link on a binary path > > > resulted out of bpf-program-attach-uprobe-opts([a binary path]), > > > remains valid and leaks memory post the binary path getting invalid > > > (say due to the file getting deleted or path does not exist anymore). > > > > I'll try to guess what you are asking. If you attached uprobe to some > > binary that was present at the time of attachment successfully, and > > then binary was removed from the file system *while uprobe is still > > attached*, then that binary is still there in the kernel and uprobe is > > still, technically active (there could be processes that were loaded > > from that binary that are still running). It's not considered a leak, > > that's how Linux object refcounting works. > > > > > > > > Does calling bpf-link-destroy on that link give any additional safety > > > w.r.t the invalid binary path, or is it not needed to invoke and the > > > internal implementation of the bpf-link takes care of the essential > > > cleanup? > > > > bpf_link__destroy() (that's libbpf API name) will detach uprobe, and > > if that uprobe was the last thing to keep reference to that deleted > > file, it will be truly removed and destroyed at that point. So you > > might want to do that, but it has nothing to do with safety. > > > > > > > > Thanks, > > > Abhik > > >
