<div dir="auto">Great idea, I hadn't thought of it, I'll try it out. <br></div><div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sat, 24 Sep 2022 at 1:40 AM Dmitry V. Levin <<a href="mailto:ldv@altlinux.org">ldv@altlinux.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;padding-left:1ex;border-left-color:rgb(204,204,204)">On Sat, Sep 24, 2022 at 01:31:55AM +0800, SuHsueyu wrote:<br>
> The tracee call BPF_MAP_LOOKUP_ELEM with map_fd, and tracer get the map_fd.<br>
> Fds are process-scoped. For example, a bpf obj with id 4 would have fd 5 in<br>
> tracee process and fd 6 in tracer process. I found that it cannot do some<br>
> operation with the tracee map_fd like bpf_obj_pin, bpf_obj_get_info_by_fd<br>
> in tracer process.<br>
<br>
Of course the value of map_fd has its meaning only in the tracee, the<br>
tracer is most likely doesn't have this descriptor opened at all.<br>
However, the descriptor is exposed via tracee's /proc, so there is<br>
a chance it could be found and opened there by the tracer.<br>
<br>
> One of the possible way to solve is use bpf_obj_pin in tracee process.<br>
<br>
I don't think it's a viable option as we don't inject any code into the<br>
tracee.<br>
<br>
<br>
-- <br>
ldv<br>
-- <br>
Strace-devel mailing list<br>
<a href="mailto:Strace-devel@lists.strace.io" target="_blank">Strace-devel@lists.strace.io</a><br>
<a href="https://lists.strace.io/mailman/listinfo/strace-devel" rel="noreferrer" target="_blank">https://lists.strace.io/mailman/listinfo/strace-devel</a><br>
</blockquote></div></div>