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.
