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 >
