From: David Miller <davem@davemloft.net>
To: ast@fb.com
Cc: daniel@iogearbox.net, kafai@fb.com, davej@codemonkey.org.uk,
netdev@vger.kernel.org, kernel-team@fb.com
Subject: Re: [PATCH net] bpf: fix hashmap extra_elems logic
Date: Wed, 22 Mar 2017 14:12:56 -0700 (PDT) [thread overview]
Message-ID: <20170322.141256.255577722554467671.davem@davemloft.net> (raw)
In-Reply-To: <1490148304-1459018-1-git-send-email-ast@fb.com>
From: Alexei Starovoitov <ast@fb.com>
Date: Tue, 21 Mar 2017 19:05:04 -0700
> In both kmalloc and prealloc mode the bpf_map_update_elem() is using
> per-cpu extra_elems to do atomic update when the map is full.
> There are two issues with it. The logic can be misused, since it allows
> max_entries+num_cpus elements to be present in the map. And alloc_extra_elems()
> at map creation time can fail percpu alloc for large map values with a warn:
> WARNING: CPU: 3 PID: 2752 at ../mm/percpu.c:892 pcpu_alloc+0x119/0xa60
> illegal size (32824) or align (8) for percpu allocation
>
> The fixes for both of these issues are different for kmalloc and prealloc modes.
> For prealloc mode allocate extra num_possible_cpus elements and store
> their pointers into extra_elems array instead of actual elements.
> Hence we can use these hidden(spare) elements not only when the map is full
> but during bpf_map_update_elem() that replaces existing element too.
> That also improves performance, since pcpu_freelist_pop/push is avoided.
> Unfortunately this approach cannot be used for kmalloc mode which needs
> to kfree elements after rcu grace period. Therefore switch it back to normal
> kmalloc even when full and old element exists like it was prior to
> commit 6c9059817432 ("bpf: pre-allocate hash map elements").
>
> Add tests to check for over max_entries and large map values.
>
> Reported-by: Dave Jones <davej@codemonkey.org.uk>
> Fixes: 6c9059817432 ("bpf: pre-allocate hash map elements")
> Signed-off-by: Alexei Starovoitov <ast@kernel.org>
> Acked-by: Daniel Borkmann <daniel@iogearbox.net>
> Acked-by: Martin KaFai Lau <kafai@fb.com>
Applied and queued up for -stable, thanks.
prev parent reply other threads:[~2017-03-22 21:13 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-03-22 2:05 [PATCH net] bpf: fix hashmap extra_elems logic Alexei Starovoitov
2017-03-22 21:12 ` David Miller [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=20170322.141256.255577722554467671.davem@davemloft.net \
--to=davem@davemloft.net \
--cc=ast@fb.com \
--cc=daniel@iogearbox.net \
--cc=davej@codemonkey.org.uk \
--cc=kafai@fb.com \
--cc=kernel-team@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;
as well as URLs for NNTP newsgroup(s).