From: Jiri Olsa <olsajiri@gmail.com>
To: Viktor Malik <vmalik@redhat.com>
Cc: Jiri Olsa <olsajiri@gmail.com>,
bpf@vger.kernel.org, Alexei Starovoitov <ast@kernel.org>,
Daniel Borkmann <daniel@iogearbox.net>,
John Fastabend <john.fastabend@gmail.com>,
Andrii Nakryiko <andrii@kernel.org>,
Martin KaFai Lau <martin.lau@linux.dev>,
Song Liu <song@kernel.org>, Yonghong Song <yhs@fb.com>,
KP Singh <kpsingh@kernel.org>,
Stanislav Fomichev <sdf@google.com>, Hao Luo <haoluo@google.com>,
Luis Chamberlain <mcgrof@kernel.org>
Subject: Re: [PATCH bpf-next v6 1/2] bpf: Fix attaching fentry/fexit/fmod_ret/lsm to modules
Date: Thu, 16 Feb 2023 16:50:41 +0100 [thread overview]
Message-ID: <Y+5Q0UK09HsxM4ht@krava> (raw)
In-Reply-To: <1992d09a-0ef8-66e3-1da0-5d13c2fecc3d@redhat.com>
On Thu, Feb 16, 2023 at 03:45:11PM +0100, Viktor Malik wrote:
SNIP
> > > diff --git a/kernel/bpf/verifier.c b/kernel/bpf/verifier.c
> > > index 388245e8826e..6a19bd450558 100644
> > > --- a/kernel/bpf/verifier.c
> > > +++ b/kernel/bpf/verifier.c
> > > @@ -24,6 +24,7 @@
> > > #include <linux/bpf_lsm.h>
> > > #include <linux/btf_ids.h>
> > > #include <linux/poison.h>
> > > +#include "../module/internal.h"
> > > #include "disasm.h"
> > > @@ -16868,6 +16869,7 @@ int bpf_check_attach_target(struct bpf_verifier_log *log,
> > > const char *tname;
> > > struct btf *btf;
> > > long addr = 0;
> > > + struct module *mod = NULL;
> > > if (!btf_id) {
> > > bpf_log(log, "Tracing programs must provide btf_id\n");
> > > @@ -17041,7 +17043,17 @@ int bpf_check_attach_target(struct bpf_verifier_log *log,
> > > else
> > > addr = (long) tgt_prog->aux->func[subprog]->bpf_func;
> > > } else {
> > > - addr = kallsyms_lookup_name(tname);
> > > + if (btf_is_module(btf)) {
> > > + preempt_disable();
> >
> > btf_try_get_module takes mutex, so you can't preempt_disable in here,
> > I got this when running the test:
> >
> > [ 691.916989][ T2585] BUG: sleeping function called from invalid context at kernel/locking/mutex.c:580
> >
>
> Hm, do we even need to preempt_disable? IIUC, preempt_disable is used
> in module kallsyms to prevent taking the module lock b/c kallsyms are
> used in the oops path. That shouldn't be an issue here, is that correct?
btf_try_get_module calls try_module_get which disables the preemption,
so no need to call it in here
jirka
>
> > > + mod = btf_try_get_module(btf);
> > > + if (mod)
> > > + addr = find_kallsyms_symbol_value(mod, tname);
> > > + else
> > > + addr = 0;
> > > + preempt_enable();
> > > + } else {
> > > + addr = kallsyms_lookup_name(tname);
> > > + }
> > > if (!addr) {
> > > bpf_log(log,
> > > "The address of function %s cannot be found\n",
> > > @@ -17105,6 +17117,12 @@ int bpf_check_attach_target(struct bpf_verifier_log *log,
> > > tgt_info->tgt_addr = addr;
> > > tgt_info->tgt_name = tname;
> > > tgt_info->tgt_type = t;
> > > + if (mod) {
> > > + if (!prog->aux->mod)
> > > + prog->aux->mod = mod;
> >
> > can this actually happen? would it be better to have bpf_check_attach_target
> > just to take take the module ref and return it in tgt_info->tgt_mod and it'd
> > be up to caller to decide what to do with that
>
> Ok, I'll try to do it that way.
>
> Thanks for the review!
> Viktor
>
> >
> > thanks,
> > jirka
> >
> > > + else
> > > + module_put(mod);
> > > + }
> > > return 0;
> > > }
> > > diff --git a/kernel/module/internal.h b/kernel/module/internal.h
> > > index 2e2bf236f558..5cb103a46018 100644
> > > --- a/kernel/module/internal.h
> > > +++ b/kernel/module/internal.h
> > > @@ -256,6 +256,11 @@ static inline bool sect_empty(const Elf_Shdr *sect)
> > > static inline void init_build_id(struct module *mod, const struct load_info *info) { }
> > > static inline void layout_symtab(struct module *mod, struct load_info *info) { }
> > > static inline void add_kallsyms(struct module *mod, const struct load_info *info) { }
> > > +static inline unsigned long find_kallsyms_symbol_value(struct module *mod
> > > + const char *name)
> > > +{
> > > + return 0;
> > > +}
> > > #endif /* CONFIG_KALLSYMS */
> > > #ifdef CONFIG_SYSFS
> > > --
> > > 2.39.1
> > >
> >
>
next prev parent reply other threads:[~2023-02-16 15:50 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-02-16 10:32 [PATCH bpf-next v6 0/2] Fix attaching fentry/fexit/fmod_ret/lsm to modules Viktor Malik
2023-02-16 10:32 ` [PATCH bpf-next v6 1/2] bpf: " Viktor Malik
2023-02-16 13:50 ` Jiri Olsa
2023-02-16 14:45 ` Viktor Malik
2023-02-16 15:50 ` Jiri Olsa [this message]
2023-03-22 9:49 ` Artem Savkov
2023-03-22 12:14 ` Jiri Olsa
2023-03-22 16:03 ` Alexei Starovoitov
2023-03-23 14:00 ` Jiri Olsa
2023-03-30 7:29 ` Jiri Olsa
2023-03-30 12:26 ` Leizhen (ThunderTown)
2023-03-30 20:59 ` Jiri Olsa
2023-03-31 8:31 ` Petr Mladek
2023-03-31 9:15 ` Leizhen (ThunderTown)
2023-03-31 11:08 ` Petr Mladek
2023-03-31 21:25 ` Jiri Olsa
2023-04-03 1:46 ` Leizhen (ThunderTown)
2023-04-03 8:46 ` Petr Mladek
2023-02-16 10:32 ` [PATCH bpf-next v6 2/2] bpf/selftests: Test fentry attachment to shadowed functions Viktor Malik
2023-02-16 23:55 ` Andrii Nakryiko
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=Y+5Q0UK09HsxM4ht@krava \
--to=olsajiri@gmail.com \
--cc=andrii@kernel.org \
--cc=ast@kernel.org \
--cc=bpf@vger.kernel.org \
--cc=daniel@iogearbox.net \
--cc=haoluo@google.com \
--cc=john.fastabend@gmail.com \
--cc=kpsingh@kernel.org \
--cc=martin.lau@linux.dev \
--cc=mcgrof@kernel.org \
--cc=sdf@google.com \
--cc=song@kernel.org \
--cc=vmalik@redhat.com \
--cc=yhs@fb.com \
/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