From: Alexei Starovoitov <alexei.starovoitov@gmail.com>
To: Martin Lau <kafai@fb.com>
Cc: Alexei Starovoitov <ast@kernel.org>,
"davem@davemloft.net" <davem@davemloft.net>,
"daniel@iogearbox.net" <daniel@iogearbox.net>,
"jakub.kicinski@netronome.com" <jakub.kicinski@netronome.com>,
"netdev@vger.kernel.org" <netdev@vger.kernel.org>,
Kernel Team <Kernel-team@fb.com>
Subject: Re: [PATCH bpf-next 1/9] bpf: introduce bpf_spin_lock
Date: Wed, 16 Jan 2019 17:02:03 -0800 [thread overview]
Message-ID: <20190117010201.dig6y6ddtfurzizt@ast-mbp> (raw)
In-Reply-To: <20190117001615.pleazxhez7aplc3m@kafai-mbp.dhcp.thefacebook.com>
On Thu, Jan 17, 2019 at 12:16:18AM +0000, Martin Lau wrote:
> On Tue, Jan 15, 2019 at 09:08:22PM -0800, Alexei Starovoitov wrote:
> [ ... ]
>
> > +/* copy everything but bpf_spin_lock */
> > +static inline void copy_map_value(struct bpf_map *map, void *dst, void *src)
> > +{
> > + if (unlikely(map_value_has_spin_lock(map))) {
> > + u32 off = map->spin_lock_off;
> > +
> > + memcpy(dst, src, off);
> > + memcpy(dst + off + sizeof(struct bpf_spin_lock),
> > + src + off + sizeof(struct bpf_spin_lock),
> > + map->value_size - off - sizeof(struct bpf_spin_lock));
> > + } else {
> > + memcpy(dst, src, map->value_size);
> > + }
> > +}
> > +
> [ ... ]
>
> > +int btf_find_spin_lock(const struct btf *btf, const struct btf_type *t)
> > +{
> > + const struct btf_member *member;
> > + u32 i, off = -ENOENT;
> > +
> > + if (BTF_INFO_KIND(t->info) != BTF_KIND_STRUCT)
> > + return -EINVAL;
> > +
> > + for_each_member(i, t, member) {
> > + const struct btf_type *member_type = btf_type_by_id(btf,
> > + member->type);
> > + if (!btf_type_is_struct(member_type))
> may be using "BTF_INFO_KIND(t->info) != BTF_KIND_STRUCT" here also.
good point. will do.
> > + continue;
> > + if (member_type->size != sizeof(struct bpf_spin_lock))
> > + continue;
> > + if (strcmp(__btf_name_by_offset(btf, member_type->name_off),
> > + "bpf_spin_lock"))
> > + continue;
> > + if (off != -ENOENT)
> > + /* only one 'struct bpf_spin_lock' is allowed */
> > + return -E2BIG;
> > + off = btf_member_bit_offset(t, member);
> > + if (off % 8)
> > + /* valid C code cannot generate such BTF */
> > + return -EINVAL;
> > + off /= 8;
> > + if (off % __alignof__(struct bpf_spin_lock))
> > + /* valid struct bpf_spin_lock will be 4 byte aligned */
> > + return -EINVAL;
> > + }
> > + return off;
> > +}
> > +
> [ ... ]
>
>
> > diff --git a/kernel/bpf/syscall.c b/kernel/bpf/syscall.c
> > index b155cd17c1bd..ebf0a673cb83 100644
> > --- a/kernel/bpf/syscall.c
> > +++ b/kernel/bpf/syscall.c
> [ ... ]
>
> > err = security_bpf_map_alloc(map);
> > @@ -740,7 +757,7 @@ static int map_lookup_elem(union bpf_attr *attr)
> > err = -ENOENT;
> > } else {
> > err = 0;
> > - memcpy(value, ptr, value_size);
> > + copy_map_value(map, value, ptr);
> copy_map_value() skips the bpf_spin_lock and "value" has not been zero-ed.
> "value" is then copied to the "__user *uvalue".
> May be init the bpf_spin_lock part of the "uvalue" to 0?
I guess something went wrong with my scripts.
The patch on my side has this:
if (attr->flags & BPF_F_LOCK) {
/* lock 'ptr' elem and copy
* everything but the lock
*/
copy_map_value_locked(map, value, ptr, true);
/* mask lock, since value was kmalloced */
check_and_init_map_lock(map, value);
} else {
copy_map_value(map, value, ptr);
}
and lock is inited to zero before copying to user space.
But I don't see the same in patchworks, so you're absolutely right
to point it out as a bug.
> btw, somehow patch 6 and 7 are missing:
> https://patchwork.ozlabs.org/cover/1025640/
Indeed and I cannot explain why. Hopefully v2 won't have this weirdness.
next prev parent reply other threads:[~2019-01-17 1:02 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-01-16 5:08 [PATCH bpf-next 0/9] introduce bpf_spin_lock Alexei Starovoitov
2019-01-16 5:08 ` [PATCH bpf-next 1/9] bpf: " Alexei Starovoitov
2019-01-16 22:48 ` Daniel Borkmann
2019-01-16 23:16 ` Daniel Borkmann
2019-01-16 23:30 ` Alexei Starovoitov
2019-01-17 0:21 ` Daniel Borkmann
2019-01-17 1:16 ` Alexei Starovoitov
2019-01-17 11:27 ` Daniel Borkmann
2019-01-18 5:51 ` Alexei Starovoitov
2019-01-16 23:23 ` Alexei Starovoitov
2019-01-17 0:16 ` Martin Lau
2019-01-17 1:02 ` Alexei Starovoitov [this message]
2019-01-16 5:08 ` [PATCH bpf-next 2/9] bpf: add support for bpf_spin_lock to cgroup local storage Alexei Starovoitov
2019-01-16 5:08 ` [PATCH bpf-next 3/9] tools/bpf: sync include/uapi/linux/bpf.h Alexei Starovoitov
2019-01-16 5:08 ` [PATCH bpf-next 4/9] selftests/bpf: add bpf_spin_lock tests Alexei Starovoitov
2019-01-16 5:08 ` [PATCH bpf-next 5/9] selftests/bpf: add bpf_spin_lock C test Alexei Starovoitov
2019-01-16 5:08 ` [PATCH bpf-next 8/9] libbpf: introduce bpf_map_lookup_elem_flags() Alexei Starovoitov
2019-01-16 6:18 ` Yonghong Song
2019-01-16 6:28 ` Alexei Starovoitov
2019-01-16 5:08 ` [PATCH bpf-next 9/9] selftests/bpf: test for BPF_F_LOCK 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=20190117010201.dig6y6ddtfurzizt@ast-mbp \
--to=alexei.starovoitov@gmail.com \
--cc=Kernel-team@fb.com \
--cc=ast@kernel.org \
--cc=daniel@iogearbox.net \
--cc=davem@davemloft.net \
--cc=jakub.kicinski@netronome.com \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox