On Thu, 12 Aug 2021 20:31:10 +0900 Masami Hiramatsu <mhiramat@xxxxxxxxxx> wrote: > > Yes, anyway we need a way to find loops on histogram/eprobe at last. > > BTW, what about using similar machanism of "current_kprobe()" to detect > the reccursion? As an easy way, prepare a static per-cpu pointer which sets > the current eprobe and if the eprobe handler detects that is already set, > it may warn (or silently ignore) and reject it. > (Of course it is better to detect the loop when user sets the hist-trigger > by reverse link) Thinking more about this, I believe there is a use case for synthetic event on a eprobe. Basically: normal_event -> eprobe (extracts struct data into $dat) -> onmax($dat) -> synthetic event But I can not come up with any use case of: eprobe -> synthetic event -> eprobe or synthetic event -> eprobe -> synthetic event That's because once you have an eprobe, you can extract what you want, and once you have that synthetic event, you can get the data you want. Maybe we should prevent the above and allow one eprobe on a synthetic event and one synthetic event on an eprobe. Or just don't prevent it at all, and let the user shoot themselves in the foot ;-) The more I think about this, I'm thinking we just let them shoot themselves if they want to. But I still agree that eprobes should not be attached to kprobes or uprobes directly (although they may be able to be attached to a synthetic event that is attached to one!) -- Steve
|