[PATCH bpf-next] bpf: lift hashtab key_size limit

[PATCH bpf-next] bpf: lift hashtab key_size limit

[Florian Lehner]

Currently key_size of hashtab is limited to MAX_BPF_STACK.

As the key of hashtab can also be a value from a per cpu map it can be
larger than MAX_BPF_STACK.
---
 kernel/bpf/hashtab.c                    | 16 +++++-----------
 tools/testing/selftests/bpf/test_maps.c |  2 +-
 2 files changed, 6 insertions(+), 12 deletions(-)

diff --git a/kernel/bpf/hashtab.c b/kernel/bpf/hashtab.c
index fe0e06284..fcac16cd4 100644
--- a/kernel/bpf/hashtab.c
+++ b/kernel/bpf/hashtab.c
@@ -390,17 +390,11 @@ static int htab_map_alloc_check(union bpf_attr *attr)
 	    attr->value_size == 0)
 		return -EINVAL;
 
-	if (attr->key_size > MAX_BPF_STACK)
-		/* eBPF programs initialize keys on stack, so they cannot be
-		 * larger than max stack size
-		 */
-		return -E2BIG;
-
-	if (attr->value_size >= KMALLOC_MAX_SIZE -
-	    MAX_BPF_STACK - sizeof(struct htab_elem))
-		/* if value_size is bigger, the user space won't be able to
-		 * access the elements via bpf syscall. This check also makes
-		 * sure that the elem_size doesn't overflow and it's
+	if ((attr->key_size + attr->value_size) >= KMALLOC_MAX_SIZE -
+	    sizeof(struct htab_elem))
+		/* if key_size + value_size is bigger, the user space won't be
+		 * able to access the elements via bpf syscall. This check
+		 * also makes sure that the elem_size doesn't overflow and it's
 		 * kmalloc-able later in htab_map_update_elem()
 		 */
 		return -E2BIG;
diff --git a/tools/testing/selftests/bpf/test_maps.c b/tools/testing/selftests/bpf/test_maps.c
index 754cf6117..9b2a096f0 100644
--- a/tools/testing/selftests/bpf/test_maps.c
+++ b/tools/testing/selftests/bpf/test_maps.c
@@ -1225,7 +1225,7 @@ static void test_map_large(void)
 {
 	struct bigkey {
 		int a;
-		char b[116];
+		char b[4096];
 		long long c;
 	} key;
 	int fd, i, value;
-- 
2.26.2

RE: [PATCH bpf-next] bpf: lift hashtab key_size limit

[John Fastabend]

Florian Lehner wrote:
> Currently key_size of hashtab is limited to MAX_BPF_STACK.
> 
> As the key of hashtab can also be a value from a per cpu map it can be
> larger than MAX_BPF_STACK.
> ---

Will need a signed-off-by line at minimum.

>  kernel/bpf/hashtab.c                    | 16 +++++-----------
>  tools/testing/selftests/bpf/test_maps.c |  2 +-
>  2 files changed, 6 insertions(+), 12 deletions(-)
> 
> diff --git a/kernel/bpf/hashtab.c b/kernel/bpf/hashtab.c
> index fe0e06284..fcac16cd4 100644
> --- a/kernel/bpf/hashtab.c
> +++ b/kernel/bpf/hashtab.c
> @@ -390,17 +390,11 @@ static int htab_map_alloc_check(union bpf_attr *attr)
>  	    attr->value_size == 0)
>  		return -EINVAL;
>  
> -	if (attr->key_size > MAX_BPF_STACK)
> -		/* eBPF programs initialize keys on stack, so they cannot be
> -		 * larger than max stack size
> -		 */
> -		return -E2BIG;
> -
> -	if (attr->value_size >= KMALLOC_MAX_SIZE -
> -	    MAX_BPF_STACK - sizeof(struct htab_elem))
> -		/* if value_size is bigger, the user space won't be able to
> -		 * access the elements via bpf syscall. This check also makes
> -		 * sure that the elem_size doesn't overflow and it's
> +	if ((attr->key_size + attr->value_size) >= KMALLOC_MAX_SIZE -
> +	    sizeof(struct htab_elem))
> +		/* if key_size + value_size is bigger, the user space won't be
> +		 * able to access the elements via bpf syscall. This check
> +		 * also makes sure that the elem_size doesn't overflow and it's
>  		 * kmalloc-able later in htab_map_update_elem()
>  		 */
>  		return -E2BIG;
> diff --git a/tools/testing/selftests/bpf/test_maps.c b/tools/testing/selftests/bpf/test_maps.c
> index 754cf6117..9b2a096f0 100644
> --- a/tools/testing/selftests/bpf/test_maps.c
> +++ b/tools/testing/selftests/bpf/test_maps.c
> @@ -1225,7 +1225,7 @@ static void test_map_large(void)
>  {
>  	struct bigkey {
>  		int a;
> -		char b[116];
> +		char b[4096];
>  		long long c;
>  	} key;
>  	int fd, i, value;
> -- 
> 2.26.2
> 

Also how about adding a test for bpf side this just updates the key
from user side iirc. I would want a test to do the per cpu update from
BPF side as well.