public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Jiri Olsa <olsajiri@gmail.com>
To: Andrii Nakryiko <andrii.nakryiko@gmail.com>
Cc: Jiri Olsa <olsajiri@gmail.com>, Oleg Nesterov <oleg@redhat.com>,
	andrii@kernel.org, mhiramat@kernel.org, peterz@infradead.org,
	clm@meta.com, mingo@kernel.org, paulmck@kernel.org,
	rostedt@goodmis.org, linux-kernel@vger.kernel.org,
	linux-trace-kernel@vger.kernel.org
Subject: Re: [PATCH 3/3] uprobes: make uprobe_register() return struct uprobe *
Date: Wed, 10 Jul 2024 21:38:40 +0200	[thread overview]
Message-ID: <Zo7jQOWyUGp6YTbz@krava> (raw)
In-Reply-To: <CAEf4BzaSDUWiSywUNrDtd-yW6p53vFYkZkr5mb461jmUgWV_2g@mail.gmail.com>

On Wed, Jul 10, 2024 at 11:23:10AM -0700, Andrii Nakryiko wrote:
> On Wed, Jul 10, 2024 at 9:49 AM Jiri Olsa <olsajiri@gmail.com> wrote:
> >
> > On Wed, Jul 10, 2024 at 06:31:33PM +0200, Oleg Nesterov wrote:
> >
> > SNIP
> >
> > > diff --git a/kernel/trace/bpf_trace.c b/kernel/trace/bpf_trace.c
> > > index 467f358c8ce7..7571811127a2 100644
> > > --- a/kernel/trace/bpf_trace.c
> > > +++ b/kernel/trace/bpf_trace.c
> > > @@ -3157,6 +3157,7 @@ struct bpf_uprobe {
> > >       loff_t offset;
> > >       unsigned long ref_ctr_offset;
> > >       u64 cookie;
> > > +     struct uprobe *uprobe;
> > >       struct uprobe_consumer consumer;
> > >  };
> > >
> > > @@ -3180,10 +3181,8 @@ static void bpf_uprobe_unregister(struct path *path, struct bpf_uprobe *uprobes,
> > >  {
> > >       u32 i;
> > >
> > > -     for (i = 0; i < cnt; i++) {
> > > -             uprobe_unregister(d_real_inode(path->dentry), uprobes[i].offset,
> > > -                               &uprobes[i].consumer);
> > > -     }
> >
> > nice, we could also drop path argument now
> 
> see my comments to Oleg, I think we can/should get rid of link->path
> altogether if uprobe itself keeps inode alive.

yea, I was thinking of that, but then it's kind of useful to have it in
bpf_uprobe_multi_link_fill_link_info, otherwise we have to take it from
first uprobe in the link, but ok, still probably worth to remove it ;-)

anyway as you wrote it's ok for follow up cleanup, I'll check on that

> 
> BTW, Jiri, do we have any test for multi-uprobe that simulates partial
> attachment success/failure (whichever way you want to look at it). It
> would be super useful to have to check at least some error handling
> code in the uprobe code base. If we don't, do you mind adding
> something simple to BPF selftests?

there's test_attach_api_fails, but I think all checked fails are before
actually calling uprobe_register function

I think there are few ways to fail the uprobe_register, like install it
on top of int3.. will check add some test for that

jirka

> 
> >
> > jirka
> >
> > > +     for (i = 0; i < cnt; i++)
> > > +             uprobe_unregister(uprobes[i].uprobe, &uprobes[i].consumer);
> > >  }
> > >
> > >  static void bpf_uprobe_multi_link_release(struct bpf_link *link)
> > > @@ -3477,11 +3476,12 @@ int bpf_uprobe_multi_link_attach(const union bpf_attr *attr, struct bpf_prog *pr
> > >                     &bpf_uprobe_multi_link_lops, prog);
> > >
> > >       for (i = 0; i < cnt; i++) {
> > > -             err = uprobe_register(d_real_inode(link->path.dentry),
> > > +             uprobes[i].uprobe = uprobe_register(d_real_inode(link->path.dentry),
> > >                                            uprobes[i].offset,
> > >                                            uprobes[i].ref_ctr_offset,
> > >                                            &uprobes[i].consumer);
> > > -             if (err) {
> > > +             if (IS_ERR(uprobes[i].uprobe)) {
> > > +                     err = PTR_ERR(uprobes[i].uprobe);
> > >                       bpf_uprobe_unregister(&path, uprobes, i);
> > >                       goto error_free;
> > >               }

  reply	other threads:[~2024-07-10 19:38 UTC|newest]

Thread overview: 30+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-07-10 14:00 [PATCH 0/2] uprobes: document mmap_lock, don't abuse get_user_pages_remote() Oleg Nesterov
2024-07-10 14:00 ` [PATCH 1/2] uprobes: document the usage of mm->mmap_lock Oleg Nesterov
2024-07-10 14:51   ` Masami Hiramatsu
2024-07-10 15:10     ` Oleg Nesterov
2024-07-11  0:07       ` Masami Hiramatsu
2024-07-11  9:49         ` Oleg Nesterov
2024-07-11 14:19           ` Masami Hiramatsu
2024-07-11 15:25             ` Oleg Nesterov
2024-07-10 14:01 ` [PATCH 2/2] uprobes: is_trap_at_addr: don't use get_user_pages_remote() Oleg Nesterov
2024-07-10 15:15   ` Andrii Nakryiko
2024-07-10 16:30 ` [PATCH 0/3] uprobes: future cleanups for review Oleg Nesterov
2024-07-10 16:30   ` [PATCH 1/3] uprobes: kill uprobe_register_refctr() Oleg Nesterov
2024-07-10 18:03     ` Andrii Nakryiko
2024-07-10 19:32       ` Oleg Nesterov
2024-07-10 16:31   ` [PATCH 2/3] uprobes: simplify error handling for alloc_uprobe() Oleg Nesterov
2024-07-11 15:18     ` Masami Hiramatsu
2024-07-10 16:31   ` [PATCH 3/3] uprobes: make uprobe_register() return struct uprobe * Oleg Nesterov
2024-07-10 16:48     ` Jiri Olsa
2024-07-10 18:23       ` Andrii Nakryiko
2024-07-10 19:38         ` Jiri Olsa [this message]
2024-07-10 19:48           ` Andrii Nakryiko
2024-07-10 19:20       ` Oleg Nesterov
2024-07-10 18:21     ` Andrii Nakryiko
2024-07-10 20:16       ` Oleg Nesterov
2024-07-10 20:46         ` Andrii Nakryiko
2024-07-11  9:26     ` Oleg Nesterov
2024-07-11 17:11       ` Andrii Nakryiko
2024-07-11 18:26         ` Oleg Nesterov
2024-07-11  8:27   ` [PATCH 0/3] uprobes: future cleanups for review Peter Zijlstra
2024-07-11  8:45     ` Oleg Nesterov

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=Zo7jQOWyUGp6YTbz@krava \
    --to=olsajiri@gmail.com \
    --cc=andrii.nakryiko@gmail.com \
    --cc=andrii@kernel.org \
    --cc=clm@meta.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-trace-kernel@vger.kernel.org \
    --cc=mhiramat@kernel.org \
    --cc=mingo@kernel.org \
    --cc=oleg@redhat.com \
    --cc=paulmck@kernel.org \
    --cc=peterz@infradead.org \
    --cc=rostedt@goodmis.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox