All of lore.kernel.org
 help / color / mirror / Atom feed
From: sdf@google.com
To: Alexei Starovoitov <alexei.starovoitov@gmail.com>
Cc: Network Development <netdev@vger.kernel.org>,
	bpf <bpf@vger.kernel.org>, Alexei Starovoitov <ast@kernel.org>,
	Daniel Borkmann <daniel@iogearbox.net>,
	Andrii Nakryiko <andrii@kernel.org>,
	Martin KaFai Lau <kafai@fb.com>
Subject: Re: [PATCH bpf-next v2] bpf: move rcu lock management out of BPF_PROG_RUN routines
Date: Mon, 18 Apr 2022 09:50:45 -0700	[thread overview]
Message-ID: <Yl2W5ThWCFPIeLW8@google.com> (raw)
In-Reply-To: <CAADnVQJ-kiWJopu+VjLDXYb9ifjKyA2h8MO=CaQppNxbHqH=-Q@mail.gmail.com>

On 04/16, Alexei Starovoitov wrote:
> On Thu, Apr 14, 2022 at 9:12 AM Stanislav Fomichev <sdf@google.com> wrote:
> > +static int
> > +bpf_prog_run_array_cg_flags(const struct cgroup_bpf *cgrp,
> > +                           enum cgroup_bpf_attach_type atype,
> > +                           const void *ctx, bpf_prog_run_fn run_prog,
> > +                           int retval, u32 *ret_flags)
> > +{
> > +       const struct bpf_prog_array_item *item;
> > +       const struct bpf_prog *prog;
> > +       const struct bpf_prog_array *array;
> > +       struct bpf_run_ctx *old_run_ctx;
> > +       struct bpf_cg_run_ctx run_ctx;
> > +       u32 func_ret;
> > +
> > +       run_ctx.retval = retval;
> > +       migrate_disable();
> > +       rcu_read_lock();
> > +       array = rcu_dereference(cgrp->effective[atype]);
> > +       item = &array->items[0];
> > +       old_run_ctx = bpf_set_run_ctx(&run_ctx.run_ctx);
> > +       while ((prog = READ_ONCE(item->prog))) {
> > +               run_ctx.prog_item = item;
> > +               func_ret = run_prog(prog, ctx);
> ...
> > +       ret = bpf_prog_run_array_cg(&cgrp->bpf, CGROUP_GETSOCKOPT,
> >                                     &ctx, bpf_prog_run, retval);

> Did you check the asm that bpf_prog_run gets inlined
> after being passed as a pointer to a function?
> Crossing fingers... I suspect not every compiler can do that :(
> De-virtualization optimization used to be tricky.

No, I didn't, but looking at it right now, both gcc and clang
seem to be doing inlining all way up to bpf_dispatcher_nop_func.

clang:

   0000000000001750 <__cgroup_bpf_run_filter_sock_addr>:
   __cgroup_bpf_run_filter_sock_addr():
   ./kernel/bpf/cgroup.c:1226
   int __cgroup_bpf_run_filter_sock_addr(struct sock *sk,
   				      struct sockaddr *uaddr,
   				      enum cgroup_bpf_attach_type atype,
   				      void *t_ctx,
   				      u32 *flags)
   {

   ...

   ./include/linux/filter.h:628
   		ret = dfunc(ctx, prog->insnsi, prog->bpf_func);
       1980:	49 8d 75 48          	lea    0x48(%r13),%rsi
   bpf_dispatcher_nop_func():
   ./include/linux/bpf.h:804
   	return bpf_func(ctx, insnsi);
       1984:	4c 89 f7             	mov    %r14,%rdi
       1987:	41 ff 55 30          	call   *0x30(%r13)
       198b:	89 c3                	mov    %eax,%ebx

gcc (w/retpoline):

   0000000000001110 <__cgroup_bpf_run_filter_sock_addr>:
   __cgroup_bpf_run_filter_sock_addr():
   kernel/bpf/cgroup.c:1226
   {

   ...

   ./include/linux/filter.h:628
   		ret = dfunc(ctx, prog->insnsi, prog->bpf_func);
       11c5:	49 8d 75 48          	lea    0x48(%r13),%rsi
   bpf_dispatcher_nop_func():
   ./include/linux/bpf.h:804
       11c9:	48 8d 7c 24 10       	lea    0x10(%rsp),%rdi
       11ce:	e8 00 00 00 00       	call   11d3  
<__cgroup_bpf_run_filter_sock_addr+0xc3>
   			11cf: R_X86_64_PLT32	__x86_indirect_thunk_rax-0x4
       11d3:	89 c3                	mov    %eax,%ebx

  reply	other threads:[~2022-04-18 16:50 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-04-14 16:12 [PATCH bpf-next v2] bpf: move rcu lock management out of BPF_PROG_RUN routines Stanislav Fomichev
2022-04-14 20:23 ` Martin KaFai Lau
2022-04-16  1:28 ` Alexei Starovoitov
2022-04-18 16:50   ` sdf [this message]
2022-04-19  5:18     ` Alexei Starovoitov
2022-04-19 15:42       ` sdf
2022-04-19 16:20         ` Alexei Starovoitov
2022-04-19 16:32           ` Alexei Starovoitov
2022-04-19 16:35             ` Stanislav Fomichev
2022-04-19 16:48               ` Alexei Starovoitov
2022-04-19 17:01                 ` Stanislav Fomichev
2022-04-19 17:05                   ` Alexei Starovoitov

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=Yl2W5ThWCFPIeLW8@google.com \
    --to=sdf@google.com \
    --cc=alexei.starovoitov@gmail.com \
    --cc=andrii@kernel.org \
    --cc=ast@kernel.org \
    --cc=bpf@vger.kernel.org \
    --cc=daniel@iogearbox.net \
    --cc=kafai@fb.com \
    --cc=netdev@vger.kernel.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.