From: Roman Gushchin <guro@fb.com>
To: Daniel Borkmann <daniel@iogearbox.net>
Cc: <netdev@vger.kernel.org>, <linux-kernel@vger.kernel.org>,
<kernel-team@fb.com>, Alexei Starovoitov <ast@kernel.org>
Subject: Re: [PATCH bpf-next] bpf: fix flags check in bpf_percpu_cgroup_storage_update()
Date: Fri, 28 Sep 2018 14:29:50 +0100 [thread overview]
Message-ID: <20180928132944.GA30652@castle.intern> (raw)
In-Reply-To: <c093c1ec-2da4-59ef-4617-f494b48952f0@iogearbox.net>
On Fri, Sep 28, 2018 at 02:11:48PM +0200, Daniel Borkmann wrote:
> On 09/28/2018 01:06 PM, Roman Gushchin wrote:
> > Fix an issue in bpf_percpu_cgroup_storage_update(): it should return
> > -EINVAL on an attempt to pass BPF_NOEXIST rather than BPF_EXIST.
> >
> > Cgroup local storage is automatically created on attaching of a bpf
> > program to a cgroup, and it can't be done from the userspace.
> >
> > Fixes: 0daef9b42374 ("bpf: introduce per-cpu cgroup local storage")
> > Signed-off-by: Roman Gushchin <guro@fb.com>
> > Cc: Daniel Borkmann <daniel@iogearbox.net>
> > Cc: Alexei Starovoitov <ast@kernel.org>
> > ---
> > kernel/bpf/local_storage.c | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/kernel/bpf/local_storage.c b/kernel/bpf/local_storage.c
> > index c739f6dcc3c2..190535f6d5e2 100644
> > --- a/kernel/bpf/local_storage.c
> > +++ b/kernel/bpf/local_storage.c
> > @@ -191,7 +191,7 @@ int bpf_percpu_cgroup_storage_update(struct bpf_map *_map, void *_key,
> > int cpu, off = 0;
> > u32 size;
> >
> > - if (unlikely(map_flags & BPF_EXIST))
> > + if (map_flags & BPF_NOEXIST)
> > return -EINVAL;
>
> Hmm, this is also incorrect as any future reserved flag would be accepted here and
> couldn't be extended anymore. :/ And it looks like cgroup_storage_update_elem() is
> doing the same today, given the cgroups local storage is still early, we should route
> a patch to stable for fixing this.
Fair enough, will post soon.
>
> Wrt this series, given the series is top of tree right now, I would prefer a fresh
> respin so we have the fix integrated properly w/o follow-up. Perhaps this could also
> incorporate Alexei's previous cleanup suggestions as well from today if you have a
> chance.
I'm not sure about merging copy() and update() functions, as large #define
blocks are really bad. So I'd think a bit more here. Will do the rest.
Thanks!
prev parent reply other threads:[~2018-09-28 13:30 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-09-28 11:06 [PATCH bpf-next] bpf: fix flags check in bpf_percpu_cgroup_storage_update() Roman Gushchin
2018-09-28 12:11 ` Daniel Borkmann
2018-09-28 13:29 ` Roman Gushchin [this message]
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=20180928132944.GA30652@castle.intern \
--to=guro@fb.com \
--cc=ast@kernel.org \
--cc=daniel@iogearbox.net \
--cc=kernel-team@fb.com \
--cc=linux-kernel@vger.kernel.org \
--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.