> On Mon, Dec 18, 2023 at 09:10:19PM +0100, Dmitry Dolgov wrote: > > > > I guess it's corner case that does not make much sense, but still it > > > > feels more natural to me to set it in attach time > > > > > > If we set attach_tracing_prog at attach time, the following will > > > succeed: > > > > > > load (fentry1 -> kernel function) > > > load (fentry2 -> fentry1) > > > load (fentry3 -> fentry2) > > > attach (fentry1) > > > attach (fentry2) > > > attach (fentry3) > > > > > > We can even make attach chain longer, as long as we load > > > the chain first. This is really confusing to me. So I think we should > > > set the flag at load() time. > > > > > > Does this make sense? > > > > yes, I did not consider this option.. makes sense > > Thanks for pointing out this case folks, haven't thought about this > either. > > Just for me to clarify explicitly, the reason why the case (loading a > chain and only then attaching every program) would work is that there is > no additional bpf_check_attach_target in bpf_tracing_prog_attach when > the trampoline is getting reused. I've tried to change this a little, it > seems to possible to prevent such situation, and still keep > attach_tracing_prog flag at attach time if there will be one more > bpf_check_attach_target. > > At the same time setting attach_tracing_prog flag at load time would be > probably less invasive, making it more preferable I guess. Will post the > new patch series with this change soon. Thinking about this more, it seems setting attach_tracing_prog flag at load time should be done not as a replacement (what I've assumed originally), but in addition to setting it at attach time. Otherwise, reattaching the same prog will lead to an inconsistency.
