public inbox for bpf@vger.kernel.org
 help / color / mirror / Atom feed
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
> > > 
> > 
> 

  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