All of lore.kernel.org
 help / color / mirror / Atom feed
From: Martin KaFai Lau <martin.lau@linux.dev>
To: Kumar Kartikeya Dwivedi <memxor@gmail.com>
Cc: ameryhung@gmail.com, andrii@kernel.org, ast@kernel.org,
	bpf@vger.kernel.org, daniel@iogearbox.net, eddyz87@gmail.com,
	grbell@redhat.com, haoluo@google.com, john.fastabend@gmail.com,
	jolsa@kernel.org, kpsingh@kernel.org, sdf@fomichev.me,
	song@kernel.org, yonghong.song@linux.dev
Subject: Re: [PATCH] bpf: Release module BTF IDR before module unload
Date: Wed, 11 Mar 2026 12:10:20 -0700	[thread overview]
Message-ID: <65de5cff-4675-4f56-8e2e-fae68ece4865@linux.dev> (raw)
In-Reply-To: <20260311130321.1055808-1-memxor@gmail.com>



On 3/11/26 6:03 AM, Kumar Kartikeya Dwivedi wrote:
> Signed-off-by: Kumar Kartikeya Dwivedi <memxor@gmail.com>
> ---
>   kernel/bpf/btf.c | 15 ++++++++++++++-
>   1 file changed, 14 insertions(+), 1 deletion(-)
> 
> diff --git a/kernel/bpf/btf.c b/kernel/bpf/btf.c
> index 09fcbb125155..d18e218049ed 100644
> --- a/kernel/bpf/btf.c
> +++ b/kernel/bpf/btf.c
> @@ -1883,10 +1883,17 @@ void btf_get(struct btf *btf)
>   	refcount_inc(&btf->refcnt);
>   }
>   
> +static bool btf_is_module(const struct btf *btf);
> +
>   void btf_put(struct btf *btf)
>   {
>   	if (btf && refcount_dec_and_test(&btf->refcnt)) {
> -		btf_free_id(btf);
> +		/*
> +		 * IDR for module BTFs is freed when module's BTF reference is
> +		 * dropped, which may happen before the final put.
> +		 */
> +		if (!btf_is_module(btf))
> +			btf_free_id(btf);
>   		call_rcu(&btf->rcu, btf_free_rcu);
>   	}
>   }
> @@ -8383,6 +8390,12 @@ static int btf_module_notify(struct notifier_block *nb, unsigned long op,
>   			if (btf_mod->module != module)
>   				continue;
>   
> +			/*
> +			 * For modules, we do the freeing of BTF IDR as soon as
> +			 * module goes away to disable BTF discovery, since the
> +			 * btf_try_get_module() on such BTFs will fail.
> +			 */
> +			btf_free_id(btf_mod->btf);
>   			list_del(&btf_mod->list);

The change makes sense.

I looked up a bit because I am interested in who will use the module's 
btf->id without holding the module's refcount. fwiw, here is what I read.

For non struct_ops prog, the module refcount is held in prog->aux->mod 
after commit 31bf1dbccfb0, so should be fine on the 
bpf_trampoline_compute_key() and bpf_prog_get_info_by_fd().

For struct_ops prog, the module refcount is not held in prog->aux->mod. 
I don't think it has to since it is not directly attached to the module. 
The only downside is the bpf_prog_get_info_by_fd() may report an 
out-dated info.attach_btf_obj_id. If it is an issue, maybe just hold the 
module refcount also.

For struct_ops map, it attaches the struct_ops prog to the module, so 
the module refcount is held. It should be fine.


  parent reply	other threads:[~2026-03-11 19:10 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-03-10 20:21 [PATCH bpf-next 0/1] Fix BPF struct_ops BTF cleanup race condition Gregory Bell
2026-03-10 20:21 ` [PATCH bpf-next 1/1] bpf: Fix BTF module cleanup race condition in struct_ops Gregory Bell
2026-03-10 20:58   ` bot+bpf-ci
2026-03-10 21:39   ` Kumar Kartikeya Dwivedi
2026-03-10 22:38     ` Amery Hung
2026-03-10 22:47       ` Kumar Kartikeya Dwivedi
2026-03-10 23:17         ` Amery Hung
2026-03-10 23:35           ` Kumar Kartikeya Dwivedi
2026-03-11  0:20             ` Martin KaFai Lau
2026-03-11  9:30               ` Kumar Kartikeya Dwivedi
2026-03-11  9:34                 ` Kumar Kartikeya Dwivedi
2026-03-11 12:21                 ` Alan Maguire
2026-03-11 13:05                   ` Kumar Kartikeya Dwivedi
2026-03-11 13:03               ` [PATCH] bpf: Release module BTF IDR before module unload Kumar Kartikeya Dwivedi
2026-03-11 13:26                 ` Kumar Kartikeya Dwivedi
2026-03-11 16:48                   ` Greg Bell
2026-03-11 13:40                 ` bot+bpf-ci
2026-03-11 19:10                 ` Martin KaFai Lau [this message]
2026-03-11 19:17                   ` Andrii Nakryiko
2026-03-11 19:55                     ` Martin KaFai Lau
2026-03-12  3:08                 ` kernel test robot

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=65de5cff-4675-4f56-8e2e-fae68ece4865@linux.dev \
    --to=martin.lau@linux.dev \
    --cc=ameryhung@gmail.com \
    --cc=andrii@kernel.org \
    --cc=ast@kernel.org \
    --cc=bpf@vger.kernel.org \
    --cc=daniel@iogearbox.net \
    --cc=eddyz87@gmail.com \
    --cc=grbell@redhat.com \
    --cc=haoluo@google.com \
    --cc=john.fastabend@gmail.com \
    --cc=jolsa@kernel.org \
    --cc=kpsingh@kernel.org \
    --cc=memxor@gmail.com \
    --cc=sdf@fomichev.me \
    --cc=song@kernel.org \
    --cc=yonghong.song@linux.dev \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.