lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20180125044213.xwd3v5guj5xiim2l@ast-mbp>
Date:   Wed, 24 Jan 2018 20:42:14 -0800
From:   Alexei Starovoitov <alexei.starovoitov@...il.com>
To:     Joel Fernandes <joelaf@...gle.com>
Cc:     linux-kernel@...r.kernel.org, kernel-team@...roid.com,
        Daniel Borkmann <daniel@...earbox.net>,
        Brendan Gregg <bgregg@...flix.com>
Subject: Re: [PATCH] bpf/stackmap: Implement bpf_get_next_key

On Wed, Jan 24, 2018 at 08:37:52PM -0800, Joel Fernandes wrote:
> Currently stackmaps can't be iterated over. The keys are obtained
> through other maps and look ups have to be performed. In new usecases,
> its useful to be able to iterate over the stackmap independently.
> Implement bpf_get_next_key to make this possible.
> 
> More details of use case:
> Currently iterating over stack maps is done like so, for example
> in BCC tools offcputime script:
> 1. Obtain keys from the 'counts' hash map.
> 2. Look up stackmap with each of the keys obtained from step 1.
> 
> This makes the iteration of stackmap dependent on the counts map.
> In a new tool I'm working on called BPFd [1], it gives a huge speed
> up when I dump entire maps before transmitting them to BCC tools
> on a different machine [2]. This patch makes it possible to dump
> stackmaps independent of other maps.
> 
> Tested on x86 and arm64 machines.
> 
> [1] https://lwn.net/Articles/744522/
> [2] https://github.com/joelagnel/bpfd/issues/8
> 
> Cc: Alexei Starovoitov <ast@...nel.org>
> Cc: Daniel Borkmann <daniel@...earbox.net>
> Cc: Brendan Gregg <bgregg@...flix.com>
> Cc: Brenden Blanco <bblanco@...il.com>
> Signed-off-by: Joel Fernandes <joelaf@...gle.com>
> ---
>  kernel/bpf/stackmap.c | 18 +++++++++++++++++-
>  1 file changed, 17 insertions(+), 1 deletion(-)
> 
> diff --git a/kernel/bpf/stackmap.c b/kernel/bpf/stackmap.c
> index a15bc636cc98..b0bf7d009f76 100644
> --- a/kernel/bpf/stackmap.c
> +++ b/kernel/bpf/stackmap.c
> @@ -228,7 +228,23 @@ int bpf_stackmap_copy(struct bpf_map *map, void *key, void *value)
>  
>  static int stack_map_get_next_key(struct bpf_map *map, void *key, void *next_key)
>  {
> -	return -EINVAL;
> +	struct bpf_stack_map *smap = container_of(map, struct bpf_stack_map, map);
> +	u32 id = 0;

did you check net-next tree before sending the patch?
Also please see Documentation/bpf/bpf_devel_QA.txt

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ