RE: [RFC bpf-next 1/5] bpf, sockmap: Let BPF helpers use lookup operation on SOCKMAP

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Jakub Sitnicki wrote:
> Don't require the BPF helpers that need to access SOCKMAP maps to live in
> the sock_map module. Expose SOCKMAP lookup to all kernel-land.
> 
> Signed-off-by: Jakub Sitnicki <jakub@xxxxxxxxxxxxxx>
> ---
>  net/core/sock_map.c | 4 +++-
>  1 file changed, 3 insertions(+), 1 deletion(-)
> 
> diff --git a/net/core/sock_map.c b/net/core/sock_map.c
> index eb114ee419b6..facacc296e6c 100644
> --- a/net/core/sock_map.c
> +++ b/net/core/sock_map.c
> @@ -271,7 +271,9 @@ static struct sock *__sock_map_lookup_elem(struct bpf_map *map, u32 key)
>  
>  static void *sock_map_lookup(struct bpf_map *map, void *key)
>  {
> -	return ERR_PTR(-EOPNOTSUPP);
> +	u32 index = *(u32 *)key;
> +
> +	return __sock_map_lookup_elem(map, index);
>  }
>  
>  static int __sock_map_delete(struct bpf_stab *stab, struct sock *sk_test,
> -- 
> 2.20.1
> 

OK, I'm looking into the latest BTF bits to see if we can do something
more useful here to keep the type information when the lookup is done so
the sock can be feed from sk_lookup and actually read.

As this series stands after the lookup its just an opaque ptr_to_map_value
right?



[Index of Archives]     [Linux Samsung SoC]     [Linux Rockchip SoC]     [Linux Actions SoC]     [Linux for Synopsys ARC Processors]     [Linux NFS]     [Linux NILFS]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]


  Powered by Linux