Re: [PATCH bpf-next 4/9] samples: bpf: refactor task_fd_query program with libbpf

"Daniel T. Lee" <[email protected]>
Newsgroups org.kernel.vger.xdp-newbies,org.kernel.vger.bpf,org.kernel.vger.netdev
Message-ID <CAEKGpzj-4X+OZNmjM+2ZJ+R_k=c_bNBTwiSfsXp2BQ4zV9YE5g@mail.gmail.com>
On Wed, Nov 18, 2020 at 11:58 AM Andrii Nakryiko
<[email protected]> wrote:
>
> On Tue, Nov 17, 2020 at 6:57 AM Daniel T. Lee <[email protected]> wrote:
> >
> > This commit refactors the existing kprobe program with libbpf bpf
> > loader. To attach bpf program, this uses generic bpf_program__attach()
> > approach rather than using bpf_load's load_bpf_file().
> >
> > To attach bpf to perf_event, instead of using previous ioctl method,
> > this commit uses bpf_program__attach_perf_event since it manages the
> > enable of perf_event and attach of BPF programs to it, which is much
> > more intuitive way to achieve.
> >
> > Also, explicit close(fd) has been removed since event will be closed
> > inside bpf_link__destroy() automatically.
> >
> > DEBUGFS macro from trace_helpers has been used to control uprobe events.
> > Furthermore, to prevent conflict of same named uprobe events, O_TRUNC
> > flag has been used to clear 'uprobe_events' interface.
> >
> > Signed-off-by: Daniel T. Lee <[email protected]>
> > ---
> >  samples/bpf/Makefile             |   2 +-
> >  samples/bpf/task_fd_query_user.c | 101 ++++++++++++++++++++++---------
> >  2 files changed, 74 insertions(+), 29 deletions(-)
> >
>
> [...]
>
> >  static int test_debug_fs_uprobe(char *binary_path, long offset, bool is_return)
> >  {
> > +       char buf[256], event_alias[sizeof("test_1234567890")];
> >         const char *event_type = "uprobe";
> >         struct perf_event_attr attr = {};
> > -       char buf[256], event_alias[sizeof("test_1234567890")];
> >         __u64 probe_offset, probe_addr;
> >         __u32 len, prog_id, fd_type;
> > -       int err, res, kfd, efd;
> > +       int err = -1, res, kfd, efd;
> > +       struct bpf_link *link;
> >         ssize_t bytes;
> >
> > -       snprintf(buf, sizeof(buf), "/sys/kernel/debug/tracing/%s_events",
> > -                event_type);
> > -       kfd = open(buf, O_WRONLY | O_APPEND, 0);
> > +       snprintf(buf, sizeof(buf), DEBUGFS "%s_events", event_type);
> > +       kfd = open(buf, O_WRONLY | O_TRUNC, 0);
>
> O_TRUNC will also remove other events, created by users. Not a great
> experience. Let's leave the old behavior?
>

The reason why I used O_TRUNC is, it gets conflict error during tests.
I'm not sure if it is a bug of ftrace uprobes_events or not, but seems adding
same name of uprobe_events with another type seems not working.
(adding uretprobes after uprobes returns an error)

    samples/bpf # echo 'p:uprobes/test_500836 ./task_fd_query:0x3d80'
>> /sys/kernel/debug/tracing/uprobe_events
    samples/bpf # cat /sys/kernel/debug/tracing/uprobe_events
     p:uprobes/test_500836 ./task_fd_query:0x0000000000003d80
    samples/bpf# echo 'r:uprobes/test_500836 ./task_fd_query:0x3d80'
>> /sys/kernel/debug/tracing/uprobe_events
     bash: echo: write error: File exists

Since this gets error, I've just truncated on every open of this interface.

> >         CHECK_PERROR_RET(kfd < 0);
> >
> >         res = snprintf(event_alias, sizeof(event_alias), "test_%d", getpid());
> > @@ -240,8 +252,8 @@ static int test_debug_fs_uprobe(char *binary_path, long offset, bool is_return)
> >         close(kfd);
> >         kfd = -1;
> >
> > -       snprintf(buf, sizeof(buf), "/sys/kernel/debug/tracing/events/%ss/%s/id",
> > -                event_type, event_alias);
> > +       snprintf(buf, sizeof(buf), DEBUGFS "events/%ss/%s/id", event_type,
>
> I'd leave the string verbatim here (and above), I think it's better
> that way and easier to figure out what's written where. And then no
> need to expose DEBUGFS.
>

Sounds great. I'll keep the string path as it was.

> > +                event_alias);
> >         efd = open(buf, O_RDONLY, 0);
> >         CHECK_PERROR_RET(efd < 0);
> >
>
> [...]



-- 
Best,
Daniel T. Lee
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.