On Wed, Apr 1, 2020 at 7:26 AM Edward Cree <ecree@xxxxxxxxxxxxxx> wrote: > > On 01/04/2020 01:22, Andrii Nakryiko wrote: > > Can you please point out where I was objecting to observability API > > (which is LINK_QUERY thing we've discussed and I didn't oppose, and > > I'm going to add next)? > I didn't say you objected to it. > I just said that you argued that it was OK for it to not land in the > same release as the rest of the API, because drgn could paper over > that gap. Which seems to me to signify a dangerous way of thinking, > and I wanted to raise the alarm about that. Let's have a bit more context first. BTW, please don't trim chain of replies (at least not so aggressively) next time. >>> That is my point. You are restricting what root can do and people will >>> not want to resort to killing random processes trying to find the one >>> holding a reference. This is an essential missing piece and should go in >>> at the same time as this set. >> No need to kill random processes, you can kill only those that hold >> bpf_link FD. You can find them using drgn tool with script like [0]. > For the record, I find the argument "we don't need a query feature, > because you can just use a kernel debugger" *utterly* *horrifying*. I was addressing the concern of having to randomly kill processes. Which is a "human override" thing, not really an observability one. And my response is exactly that it's better to be able to see all owners of bpf_link, rather than have a "nuke" option. It so happens that drgn is a very useful tool for this and I was able to prototype such script quickly enough to share it with others. drgn is not the only option, you can do that by iterating procfs and using fdinfo. It can certainly be improved for bpf_link-specific case by providing more information (like cgroup path, etc). But in general, it's a question of "which processes use given file", which unfortunately, I don't think Linux has a better observability APIs for. I'm not happy about that, but it's not really bpf_link-specific issue either. > (If you _don't_ see what's wrong with that argument... well, that'd > be even _more_ alarming. Debuggers — and fuser, for that matter — > are for when things go wrong _in ways the designers of the system > failed to anticipate_. They should not be part of a 'normal' work- > flow for dealing with problems that we already _know_ are possible; > it's kinda-sorta like how exceptions shouldn't be used for non- > exceptional situations.) I don't think it's as quite black and white as you are stating. For instance, I *think* lsof, netstat, bcc tools, etc disagree with you. Also need to kill application because it's attached to XDP or cgroup doesn't seem like a "normal" workflow either. But I really would rather leave it at that, if you don't mind. > > -ed
