[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20210324012237.65pf4s52oqlicea3@ast-mbp>
Date: Tue, 23 Mar 2021 18:22:37 -0700
From: Alexei Starovoitov <alexei.starovoitov@...il.com>
To: Jiri Olsa <jolsa@...nel.org>
Cc: Alexei Starovoitov <ast@...nel.org>,
Daniel Borkmann <daniel@...earbox.net>,
Andrii Nakryiko <andriin@...com>, netdev@...r.kernel.org,
bpf@...r.kernel.org, Martin KaFai Lau <kafai@...com>,
Song Liu <songliubraving@...com>, Yonghong Song <yhs@...com>,
John Fastabend <john.fastabend@...il.com>,
KP Singh <kpsingh@...omium.org>,
Steven Rostedt <rostedt@...dmis.org>
Subject: Re: [PATCH bpf] bpf: Take module reference for ip in module code
On Tue, Mar 23, 2021 at 10:15:33PM +0100, Jiri Olsa wrote:
> Currently module can be unloaded even if there's a trampoline
> register in it. It's easily reproduced by running in parallel:
>
> # while :; do ./test_progs -t module_attach; done
> # while :; do ./test_progs -t fentry_test; done
>
> Taking the module reference in case the trampoline's ip is
> within the module code. Releasing it when the trampoline's
> ip is unregistered.
>
> Signed-off-by: Jiri Olsa <jolsa@...nel.org>
> ---
> kernel/bpf/trampoline.c | 32 ++++++++++++++++++++++++++++++++
> 1 file changed, 32 insertions(+)
>
> diff --git a/kernel/bpf/trampoline.c b/kernel/bpf/trampoline.c
> index 1f3a4be4b175..f6cb179842b2 100644
> --- a/kernel/bpf/trampoline.c
> +++ b/kernel/bpf/trampoline.c
> @@ -87,6 +87,27 @@ static struct bpf_trampoline *bpf_trampoline_lookup(u64 key)
> return tr;
> }
>
> +static struct module *ip_module_get(unsigned long ip)
> +{
> + struct module *mod;
> + int err = 0;
> +
> + preempt_disable();
> + mod = __module_text_address(ip);
> + if (mod && !try_module_get(mod))
> + err = -ENOENT;
> + preempt_enable();
> + return err ? ERR_PTR(err) : mod;
> +}
> +
> +static void ip_module_put(unsigned long ip)
> +{
> + struct module *mod = __module_text_address(ip);
Conceptually looks correct, but how did you test it?!
Just doing your reproducer:
while :; do ./test_progs -t module_attach; done & while :; do ./test_progs -t fentry_test; done
I immediately hit:
[ 19.461162] WARNING: CPU: 1 PID: 232 at kernel/module.c:264 module_assert_mutex_or_preempt+0x2e/0x40
[ 19.477126] Call Trace:
[ 19.477464] __module_address+0x28/0xf0
[ 19.477865] ? __bpf_trace_bpf_testmod_test_write_bare+0x10/0x10 [bpf_testmod]
[ 19.478711] __module_text_address+0xe/0x60
[ 19.479156] bpf_trampoline_update+0x2ff/0x470
Which points to an obvious bug above.
How did you debug it to this module going away issue?
Why does test_progs -t fentry_test help to repro?
Or does it?
It doesn't touch anything in modules.
> +
> + if (mod)
> + module_put(mod);
Powered by blists - more mailing lists