BPF Archive on lore.kernel.org
 help / color / Atom feed
* [PATCH bpf-next v2] bpf: Lift hashtab key_size limit
@ 2020-09-22 19:02 Florian Lehner
  2020-10-12 19:45 ` John Fastabend
       [not found] ` <20201013144515.298647-1-dev@der-flo.net>
  0 siblings, 2 replies; 6+ messages in thread
From: Florian Lehner @ 2020-09-22 19:02 UTC (permalink / raw)
  To: bpf; +Cc: ast, daniel, john.fastabend, 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.

Changelog:

v2:
 -  Add a test for bpf side

Signed-off-by: Florian Lehner <dev@der-flo.net>
---
 kernel/bpf/hashtab.c                          | 16 +++----
 .../selftests/bpf/prog_tests/hash_large_key.c | 28 ++++++++++++
 .../selftests/bpf/progs/test_hash_large_key.c | 45 +++++++++++++++++++
 tools/testing/selftests/bpf/test_maps.c       |  2 +-
 4 files changed, 79 insertions(+), 12 deletions(-)
 create mode 100644 tools/testing/selftests/bpf/prog_tests/hash_large_key.c
 create mode 100644 tools/testing/selftests/bpf/progs/test_hash_large_key.c

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/prog_tests/hash_large_key.c b/tools/testing/selftests/bpf/prog_tests/hash_large_key.c
new file mode 100644
index 000000000..962f56060
--- /dev/null
+++ b/tools/testing/selftests/bpf/prog_tests/hash_large_key.c
@@ -0,0 +1,28 @@
+// SPDX-License-Identifier: GPL-2.0
+// Copyright (c) 2020 Florian Lehner
+
+#include <test_progs.h>
+
+void test_hash_large_key(void)
+{
+	const char *file = "./test_hash_large_key.o";
+	int prog_fd, map_fd[2];
+	struct bpf_object *obj = NULL;
+	int err = 0;
+
+	err = bpf_prog_load(file, BPF_PROG_TYPE_CGROUP_SKB, &obj, &prog_fd);
+	if (CHECK_FAIL(err)) {
+		printf("test_hash_large_key: bpf_prog_load errno %d", errno);
+		goto close_prog;
+	}
+
+	map_fd[0] = bpf_find_map(__func__, obj, "hash_map");
+	if (CHECK_FAIL(map_fd[0] < 0))
+		goto close_prog;
+	map_fd[1] = bpf_find_map(__func__, obj, "key_map");
+	if (CHECK_FAIL(map_fd[1] < 0))
+		goto close_prog;
+
+close_prog:
+	bpf_object__close(obj);
+}
diff --git a/tools/testing/selftests/bpf/progs/test_hash_large_key.c b/tools/testing/selftests/bpf/progs/test_hash_large_key.c
new file mode 100644
index 000000000..622ee73a4
--- /dev/null
+++ b/tools/testing/selftests/bpf/progs/test_hash_large_key.c
@@ -0,0 +1,45 @@
+// SPDX-License-Identifier: GPL-2.0
+// Copyright (c) 2020 Florian Lehner
+
+#include <linux/bpf.h>
+#include <linux/version.h>
+#include <bpf/bpf_helpers.h>
+
+struct bigelement {
+	int a;
+	char b[4096];
+	long long c;
+};
+
+struct {
+	__uint(type, BPF_MAP_TYPE_HASH);
+	__uint(max_entries, 1);
+	__type(key, struct bigelement);
+	__type(value, __u32);
+} hash_map SEC(".maps");
+
+struct {
+	__uint(type, BPF_MAP_TYPE_PERCPU_ARRAY);
+	__uint(max_entries, 1);
+	__type(key, __u32);
+	__type(value, struct bigelement);
+} key_map SEC(".maps");
+
+SEC("hash_large_key_demo")
+int bpf_hash_large_key_test(struct __sk_buf *skb)
+{
+	int zero = 0, err = 1, value = 42;
+	struct bigelement *key;
+
+	key = bpf_map_lookup_elem(&key_map, &zero);
+	if (!key)
+		goto err;
+
+	if (bpf_map_update_elem(&hash_map, key, &value, BPF_ANY))
+		goto err;
+	err = 0;
+err:
+	return err;
+}
+
+char _license[] SEC("license") = "GPL";
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


^ permalink raw reply	[flat|nested] 6+ messages in thread

* RE: [PATCH bpf-next v2] bpf: Lift hashtab key_size limit
  2020-09-22 19:02 [PATCH bpf-next v2] bpf: Lift hashtab key_size limit Florian Lehner
@ 2020-10-12 19:45 ` John Fastabend
  2020-10-14 19:25   ` Florian Lehner
       [not found] ` <20201013144515.298647-1-dev@der-flo.net>
  1 sibling, 1 reply; 6+ messages in thread
From: John Fastabend @ 2020-10-12 19:45 UTC (permalink / raw)
  To: Florian Lehner, bpf; +Cc: ast, daniel, john.fastabend, Florian Lehner

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.
> 
> Changelog:
> 
> v2:
>  -  Add a test for bpf side
> 
> Signed-off-by: Florian Lehner <dev@der-flo.net>
> ---

I think this is OK, but just curious is there a real use-case
that has keys bigger than stack size or is this just an
in-theory observation.

Thanks,
John

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: [PATCH bpf-next v2] bpf: Lift hashtab key_size limit
  2020-10-12 19:45 ` John Fastabend
@ 2020-10-14 19:25   ` Florian Lehner
  0 siblings, 0 replies; 6+ messages in thread
From: Florian Lehner @ 2020-10-14 19:25 UTC (permalink / raw)
  To: John Fastabend; +Cc: ast, bpf, daniel, dev

John Fastabend wrote:
> I think this is OK, but just curious is there a real use-case
> that has keys bigger than stack size or is this just an
> in-theory observation.

The use-case for this patch originates to implement allow/disallow
lists for files and file paths. The maximum length of file paths is
defined by PATH_MAX with 4096 chars including nul.
This limit exceeds MAX_BPF_STACK. 

Thanks,
 Florian

^ permalink raw reply	[flat|nested] 6+ messages in thread

* RE: [PATCH bpf-next v2] bpf: Lift hashtab key_size limit
       [not found] ` <20201013144515.298647-1-dev@der-flo.net>
@ 2020-10-15  4:21   ` John Fastabend
  2020-10-23 16:35     ` Florian Lehner
  0 siblings, 1 reply; 6+ messages in thread
From: John Fastabend @ 2020-10-15  4:21 UTC (permalink / raw)
  To: Florian Lehner, john.fastabend; +Cc: ast, bpf, daniel, dev

Florian Lehner wrote:
> John Fastabend wrote:
> > I think this is OK, but just curious is there a real use-case
> > that has keys bigger than stack size or is this just an
> > in-theory observation.
> 
> The use-case for this patch originates to implement allow/disallow
> lists for files and file paths. The maximum length of file paths is
> defined by PATH_MAX with 4096 chars including nul.
> This limit exceeds MAX_BPF_STACK. 
> 
> Thanks,
>  Florian

OK the check appears unnecessary. It seems a bit excessive to have
such large keys though.

Daniel, Alexei I couldn't find this patch in patchworks, not sure
where it went.

Acked-by: John Fastabend <john.fastabend@gmail.com>

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: [PATCH bpf-next v2] bpf: Lift hashtab key_size limit
  2020-10-15  4:21   ` John Fastabend
@ 2020-10-23 16:35     ` Florian Lehner
  2020-10-23 20:27       ` Andrii Nakryiko
  0 siblings, 1 reply; 6+ messages in thread
From: Florian Lehner @ 2020-10-23 16:35 UTC (permalink / raw)
  To: John Fastabend; +Cc: ast, daniel, bpf

On Wed, Oct 14, 2020 at 09:21:56PM -0700, John Fastabend wrote:
> 
> OK the check appears unnecessary. It seems a bit excessive to have
> such large keys though.
> 
> Daniel, Alexei I couldn't find this patch in patchworks, not sure
> where it went.
> 
> Acked-by: John Fastabend <john.fastabend@gmail.com>

Is there something left I have missed to address?
Or should I rebase the patch and send it in again?

Thanks,
 Florian

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: [PATCH bpf-next v2] bpf: Lift hashtab key_size limit
  2020-10-23 16:35     ` Florian Lehner
@ 2020-10-23 20:27       ` Andrii Nakryiko
  0 siblings, 0 replies; 6+ messages in thread
From: Andrii Nakryiko @ 2020-10-23 20:27 UTC (permalink / raw)
  To: Florian Lehner; +Cc: John Fastabend, Alexei Starovoitov, Daniel Borkmann, bpf

On Fri, Oct 23, 2020 at 9:38 AM Florian Lehner <dev@der-flo.net> wrote:
>
> On Wed, Oct 14, 2020 at 09:21:56PM -0700, John Fastabend wrote:
> >
> > OK the check appears unnecessary. It seems a bit excessive to have
> > such large keys though.
> >
> > Daniel, Alexei I couldn't find this patch in patchworks, not sure
> > where it went.
> >
> > Acked-by: John Fastabend <john.fastabend@gmail.com>
>
> Is there something left I have missed to address?
> Or should I rebase the patch and send it in again?

Yeah, please rebase and resubmit. There were some problems with
patchworks and a bunch of patches didn't make it to the system. Yours
might have been one of them.

>
> Thanks,
>  Florian

^ permalink raw reply	[flat|nested] 6+ messages in thread

end of thread, back to index

Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-09-22 19:02 [PATCH bpf-next v2] bpf: Lift hashtab key_size limit Florian Lehner
2020-10-12 19:45 ` John Fastabend
2020-10-14 19:25   ` Florian Lehner
     [not found] ` <20201013144515.298647-1-dev@der-flo.net>
2020-10-15  4:21   ` John Fastabend
2020-10-23 16:35     ` Florian Lehner
2020-10-23 20:27       ` Andrii Nakryiko

BPF Archive on lore.kernel.org

Archives are clonable:
	git clone --mirror https://lore.kernel.org/bpf/0 bpf/git/0.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 bpf bpf/ https://lore.kernel.org/bpf \
		bpf@vger.kernel.org
	public-inbox-index bpf

Example config snippet for mirrors

Newsgroup available over NNTP:
	nntp://nntp.lore.kernel.org/org.kernel.vger.bpf


AGPL code for this site: git clone https://public-inbox.org/public-inbox.git