From: Jessica Yu <jeyu@kernel.org>
To: Andrii Nakryiko <andrii@kernel.org>
Cc: bpf@vger.kernel.org, netdev@vger.kernel.org, ast@fb.com,
daniel@iogearbox.net, kernel-team@fb.com,
linux-kernel@vger.kernel.org, rafael@kernel.org,
Arnaldo Carvalho de Melo <acme@redhat.com>,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Subject: Re: [PATCH v4 bpf-next 4/5] bpf: load and verify kernel module BTFs
Date: Wed, 11 Nov 2020 11:13:17 +0100 [thread overview]
Message-ID: <20201111101316.GA5304@linux-8ccs> (raw)
In-Reply-To: <20201110011932.3201430-5-andrii@kernel.org>
+++ Andrii Nakryiko [09/11/20 17:19 -0800]:
[snipped]
>diff --git a/kernel/module.c b/kernel/module.c
>index a4fa44a652a7..f2996b02ab2e 100644
>--- a/kernel/module.c
>+++ b/kernel/module.c
>@@ -380,6 +380,35 @@ static void *section_objs(const struct load_info *info,
> return (void *)info->sechdrs[sec].sh_addr;
> }
>
>+/* Find a module section: 0 means not found. Ignores SHF_ALLOC flag. */
>+static unsigned int find_any_sec(const struct load_info *info, const char *name)
>+{
>+ unsigned int i;
>+
>+ for (i = 1; i < info->hdr->e_shnum; i++) {
>+ Elf_Shdr *shdr = &info->sechdrs[i];
>+ if (strcmp(info->secstrings + shdr->sh_name, name) == 0)
>+ return i;
>+ }
>+ return 0;
>+}
>+
>+/*
>+ * Find a module section, or NULL. Fill in number of "objects" in section.
>+ * Ignores SHF_ALLOC flag.
>+ */
>+static __maybe_unused void *any_section_objs(const struct load_info *info,
>+ const char *name,
>+ size_t object_size,
>+ unsigned int *num)
>+{
>+ unsigned int sec = find_any_sec(info, name);
>+
>+ /* Section 0 has sh_addr 0 and sh_size 0. */
>+ *num = info->sechdrs[sec].sh_size / object_size;
>+ return (void *)info->sechdrs[sec].sh_addr;
>+}
>+
Hm, I see this patchset has already been applied to bpf-next, but I
guess that doesn't preclude any follow-up patches :-)
I am not a huge fan of the code duplication here, and also the fact
that they're only called in one place. any_section_objs() and
find_any_sec() are pretty much identical to section_objs() and
find_sec(), other than the fact the former drops the SHF_ALLOC check.
Moreover, since it appears that the ".BTF" section is not marked
SHF_ALLOC, I think this will leave mod->btf_data as a dangling pointer
after the module is done loading and the module's load_info has been
deallocated, since SHF_ALLOC sections are not allocated nor copied to
the module's final location in memory.
Why not simply mark the ".BTF" section in the module SHF_ALLOC? We
already do some sh_flags rewriting in rewrite_section_headers(). Then
the module loader knows to keep the section in memory and you can use
section_objs(). And since the .BTF section stays in module memory,
that might save you the memcpy() to btf->data in btf_parse_module()
(unless that is still needed for some reason).
Thanks,
Jessica
> /* Provided by the linker */
> extern const struct kernel_symbol __start___ksymtab[];
> extern const struct kernel_symbol __stop___ksymtab[];
>@@ -3250,6 +3279,9 @@ static int find_module_sections(struct module *mod, struct load_info *info)
> sizeof(*mod->bpf_raw_events),
> &mod->num_bpf_raw_events);
> #endif
>+#ifdef CONFIG_DEBUG_INFO_BTF_MODULES
>+ mod->btf_data = any_section_objs(info, ".BTF", 1, &mod->btf_data_size);
>+#endif
> #ifdef CONFIG_JUMP_LABEL
> mod->jump_entries = section_objs(info, "__jump_table",
> sizeof(*mod->jump_entries),
>--
>2.24.1
>
next prev parent reply other threads:[~2020-11-11 10:13 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-11-10 1:19 [PATCH v4 bpf-next 0/5] Integrate kernel module BTF support Andrii Nakryiko
2020-11-10 1:19 ` [PATCH v4 bpf-next 1/5] bpf: add in-kernel split " Andrii Nakryiko
2020-11-10 17:49 ` Song Liu
2020-11-10 18:31 ` Andrii Nakryiko
2020-11-10 20:14 ` Song Liu
2020-11-10 1:19 ` [PATCH v4 bpf-next 2/5] bpf: assign ID to vmlinux BTF and return extra info for BTF in GET_OBJ_INFO Andrii Nakryiko
2020-11-10 20:24 ` Song Liu
2020-11-10 1:19 ` [PATCH v4 bpf-next 3/5] kbuild: build kernel module BTFs if BTF is enabled and pahole supports it Andrii Nakryiko
2020-11-11 1:04 ` Song Liu
2020-11-16 19:55 ` Allan, Bruce W
2020-11-16 20:34 ` Andrii Nakryiko
2020-11-16 21:24 ` Jakub Kicinski
2020-11-16 22:35 ` Andrii Nakryiko
2021-11-26 15:16 ` Fabian Grünbichler
2021-12-08 0:08 ` Andrii Nakryiko
2020-11-17 3:44 ` David Ahern
2020-11-10 1:19 ` [PATCH v4 bpf-next 4/5] bpf: load and verify kernel module BTFs Andrii Nakryiko
2020-11-11 7:11 ` kernel test robot
2020-11-11 10:13 ` Jessica Yu [this message]
2020-11-11 20:11 ` Andrii Nakryiko
2020-11-13 10:31 ` Jessica Yu
2020-11-13 18:54 ` Andrii Nakryiko
2020-11-10 1:19 ` [PATCH v4 bpf-next 5/5] tools/bpftool: add support for in-kernel and named BTF in `btf show` Andrii Nakryiko
2020-11-11 1:15 ` Song Liu
2020-11-11 4:19 ` Andrii Nakryiko
2020-11-11 7:44 ` Song Liu
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20201111101316.GA5304@linux-8ccs \
--to=jeyu@kernel.org \
--cc=acme@redhat.com \
--cc=andrii@kernel.org \
--cc=ast@fb.com \
--cc=bpf@vger.kernel.org \
--cc=daniel@iogearbox.net \
--cc=gregkh@linuxfoundation.org \
--cc=kernel-team@fb.com \
--cc=linux-kernel@vger.kernel.org \
--cc=netdev@vger.kernel.org \
--cc=rafael@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).