linux-kernel - Re: [RFC] bpf: change bpf syacall to use u64 temp variables

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] [day] [month] [year] [list]

Message-ID: <20151019190835.GA19852@Alexeis-MBP.westell.com>
Date:	Mon, 19 Oct 2015 12:08:36 -0700
From:	Alexei Starovoitov <alexei.starovoitov@...il.com>
To:	yalin wang <yalin.wang2010@...il.com>
Cc:	ast@...nel.org, netdev@...r.kernel.org,
	linux-kernel@...r.kernel.org
Subject: Re: [RFC] bpf: change bpf syacall to use u64 temp variables

On Mon, Oct 19, 2015 at 03:10:46PM +0800, yalin wang wrote:
> This patch change map_lookup_elem() and map_update_elem() function
> to use u64 temp variable if the key_size or value_size is less than
> u64, we don't need use kmalloc() for these small variables.
> 
> Signed-off-by: yalin wang <yalin.wang2010@...il.com>
> ---
>  kernel/bpf/syscall.c | 30 ++++++++++++++++++++----------
>  1 file changed, 20 insertions(+), 10 deletions(-)
> 
> diff --git a/kernel/bpf/syscall.c b/kernel/bpf/syscall.c
> index f640e5f..c82d7bf 100644
> --- a/kernel/bpf/syscall.c
> +++ b/kernel/bpf/syscall.c
> @@ -189,7 +189,8 @@ static int map_lookup_elem(union bpf_attr *attr)
>  	void __user *uvalue = u64_to_ptr(attr->value);
>  	int ufd = attr->map_fd;
>  	struct bpf_map *map;
> -	void *key, *value, *ptr;
> +	u64 key_buf, value_buf;
> +	void *key = &key_buf, *value = &value_buf, *ptr;
>  	struct fd f;
>  	int err;
>  
> @@ -202,7 +203,8 @@ static int map_lookup_elem(union bpf_attr *attr)
>  		return PTR_ERR(map);
>  
>  	err = -ENOMEM;
> -	key = kmalloc(map->key_size, GFP_USER);
> +	if (map->key_size > sizeof(u64))
> +		key = kmalloc(map->key_size, GFP_USER);

I think it's a good optimization for common case.
Performance numbers would be good to prove the point.
Thanks

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/