From: Stanislav Fomichev <sdf@google.com>
To: Andrii Nakryiko <andrii.nakryiko@gmail.com>
Cc: Networking <netdev@vger.kernel.org>, bpf <bpf@vger.kernel.org>,
Alexei Starovoitov <ast@kernel.org>,
Daniel Borkmann <daniel@iogearbox.net>,
Andrii Nakryiko <andrii@kernel.org>
Subject: Re: [PATCH bpf-next] bpf: use bpf_prog_run_array_cg_flags everywhere
Date: Wed, 20 Apr 2022 15:30:43 -0700 [thread overview]
Message-ID: <CAKH8qBsTiQA5knxoBSqxCYav89QdSN0j6t1EWX1MEVbAqLj6kg@mail.gmail.com> (raw)
In-Reply-To: <CAEf4BzYoA4xvqv7SaM2TvcbKef=m4n6TSGVNA34T2we05fRwpw@mail.gmail.com>
On Wed, Apr 20, 2022 at 3:04 PM Andrii Nakryiko
<andrii.nakryiko@gmail.com> wrote:
>
> On Tue, Apr 19, 2022 at 3:23 PM Stanislav Fomichev <sdf@google.com> wrote:
> >
> > Rename bpf_prog_run_array_cg_flags to bpf_prog_run_array_cg and
> > use it everywhere. check_return_code already enforces sane
> > return ranges for all cgroup types. (only egress and bind hooks have
> > uncanonical return ranges, the rest is using [0, 1])
> >
> > No functional changes.
> >
> > Suggested-by: Alexei Starovoitov <ast@kernel.org>
> > Signed-off-by: Stanislav Fomichev <sdf@google.com>
> > ---
> > include/linux/bpf-cgroup.h | 8 ++---
> > kernel/bpf/cgroup.c | 70 ++++++++++++--------------------------
> > 2 files changed, 24 insertions(+), 54 deletions(-)
> >
> > diff --git a/include/linux/bpf-cgroup.h b/include/linux/bpf-cgroup.h
> > index 88a51b242adc..669d96d074ad 100644
> > --- a/include/linux/bpf-cgroup.h
> > +++ b/include/linux/bpf-cgroup.h
> > @@ -225,24 +225,20 @@ static inline bool cgroup_bpf_sock_enabled(struct sock *sk,
> >
> > #define BPF_CGROUP_RUN_SA_PROG(sk, uaddr, atype) \
> > ({ \
> > - u32 __unused_flags; \
> > int __ret = 0; \
> > if (cgroup_bpf_enabled(atype)) \
> > __ret = __cgroup_bpf_run_filter_sock_addr(sk, uaddr, atype, \
> > - NULL, \
> > - &__unused_flags); \
> > + NULL, NULL); \
> > __ret; \
> > })
> >
> > #define BPF_CGROUP_RUN_SA_PROG_LOCK(sk, uaddr, atype, t_ctx) \
> > ({ \
> > - u32 __unused_flags; \
> > int __ret = 0; \
> > if (cgroup_bpf_enabled(atype)) { \
> > lock_sock(sk); \
> > __ret = __cgroup_bpf_run_filter_sock_addr(sk, uaddr, atype, \
> > - t_ctx, \
> > - &__unused_flags); \
> > + t_ctx, NULL); \
> > release_sock(sk); \
> > } \
> > __ret; \
> > diff --git a/kernel/bpf/cgroup.c b/kernel/bpf/cgroup.c
> > index 0cb6211fcb58..f61eca32c747 100644
> > --- a/kernel/bpf/cgroup.c
> > +++ b/kernel/bpf/cgroup.c
> > @@ -25,50 +25,18 @@ EXPORT_SYMBOL(cgroup_bpf_enabled_key);
> > /* __always_inline is necessary to prevent indirect call through run_prog
> > * function pointer.
> > */
> > -static __always_inline 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);
> > - if (!(func_ret & 1) && !IS_ERR_VALUE((long)run_ctx.retval))
> > - run_ctx.retval = -EPERM;
> > - *(ret_flags) |= (func_ret >> 1);
> > - item++;
> > - }
> > - bpf_reset_run_ctx(old_run_ctx);
> > - rcu_read_unlock();
> > - migrate_enable();
> > - return run_ctx.retval;
> > -}
> > -
> > static __always_inline int
> > bpf_prog_run_array_cg(const struct cgroup_bpf *cgrp,
> > enum cgroup_bpf_attach_type atype,
> > const void *ctx, bpf_prog_run_fn run_prog,
> > - int retval)
> > + 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();
> > @@ -78,8 +46,11 @@ bpf_prog_run_array_cg(const struct cgroup_bpf *cgrp,
> > old_run_ctx = bpf_set_run_ctx(&run_ctx.run_ctx);
> > while ((prog = READ_ONCE(item->prog))) {
> > run_ctx.prog_item = item;
> > - if (!run_prog(prog, ctx) && !IS_ERR_VALUE((long)run_ctx.retval))
> > + func_ret = run_prog(prog, ctx);
> > + if (!(func_ret & 1) && !IS_ERR_VALUE((long)run_ctx.retval))
>
> to be completely true to previous behavior, shouldn't there be
>
> if (ret_flags)
> func_ret &= 1;
> if (!func_ret && !IS_ERR_VALUE(...))
>
> here?
>
> This might have been discussed previously and I missed it. If that's
> so, please ignore.
We are converting the cases where run_prog(prog, ctx) returns 0 or 1,
so it seems like we don't have to reproduce the existing behavior
1-to-1?
So I'm not sure it matters, or am I missing something?
next prev parent reply other threads:[~2022-04-20 22:30 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-04-19 22:22 [PATCH bpf-next] bpf: use bpf_prog_run_array_cg_flags everywhere Stanislav Fomichev
2022-04-20 22:04 ` Andrii Nakryiko
2022-04-20 22:30 ` Stanislav Fomichev [this message]
2022-04-25 20:37 ` Martin KaFai Lau
2022-04-25 21:48 ` Stanislav Fomichev
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=CAKH8qBsTiQA5knxoBSqxCYav89QdSN0j6t1EWX1MEVbAqLj6kg@mail.gmail.com \
--to=sdf@google.com \
--cc=andrii.nakryiko@gmail.com \
--cc=andrii@kernel.org \
--cc=ast@kernel.org \
--cc=bpf@vger.kernel.org \
--cc=daniel@iogearbox.net \
--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.