From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail.189.cn (189sx01-ptr.21cn.com [14.18.100.240]) by smtp.subspace.kernel.org (Postfix) with ESMTP id 05160311967; Fri, 30 Jan 2026 02:22:06 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=14.18.100.240 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1769739732; cv=none; b=nYG+621QNL9Z9N0Syzh16g9tw4fmyKqCHwFepiH/Lt+kAJljaq+B45B8OilimhYiaycvu2QqajsZv8UHG94XZ643eabIjGqFLKZK5oz7/O4ShpsB0IpO6I+Tsppsd8jDssaTI41/FYGT5ldlE+bXfaldA9RderIwCzYnJFRSUm0= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1769739732; c=relaxed/simple; bh=y43Lp50OTrgRWlWv6bseXRRLByi+2SLqklJWTij5TAE=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=c9z6UXWvH37v7C+8w3tHShmeT1a8mwSm++qWbSUvvha8RVJo710MTu/5v3lbgkWBS0WAZA1OQ5j6V5Uz+x8v/tZd/Fhq4ddZBr6BJ8g2EFbOFWgBlNobg/kzmB0mKcp4KJVu5Ecv0dffI107zqeGiRjEw5kzXFY1IM8PtOXmSSg= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=189.cn; spf=pass smtp.mailfrom=189.cn; arc=none smtp.client-ip=14.18.100.240 Authentication-Results: smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=189.cn Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=189.cn HMM_SOURCE_IP:10.158.242.145:0.738707711 HMM_ATTACHE_NUM:0000 HMM_SOURCE_TYPE:SMTP Received: from clientip-221.238.56.48 (unknown [10.158.242.145]) by mail.189.cn (HERMES) with SMTP id 995D6400357; Fri, 30 Jan 2026 10:17:54 +0800 (CST) Received: from ([221.238.56.48]) by gateway-153622-dep-76cc7bc9cd-r45x9 with ESMTP id 06410c8c7865490d9a3f4121cbe216e4 for alexei.starovoitov@gmail.com; Fri, 30 Jan 2026 10:17:55 CST X-Transaction-ID: 06410c8c7865490d9a3f4121cbe216e4 X-Real-From: chensong_2000@189.cn X-Receive-IP: 221.238.56.48 X-MEDUSA-Status: 0 Sender: chensong_2000@189.cn Message-ID: Date: Fri, 30 Jan 2026 10:17:53 +0800 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2] kernel/bpf/btf.c: reject to register duplicated kfunc To: Alexei Starovoitov Cc: Martin KaFai Lau , Alexei Starovoitov , Daniel Borkmann , Andrii Nakryiko , Eduard , Song Liu , Yonghong Song , John Fastabend , KP Singh , Stanislav Fomichev , Hao Luo , Jiri Olsa , bpf , LKML References: <20260122090404.15553-1-chensong_2000@189.cn> Content-Language: en-US From: Song Chen In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit hi, my comments are in line, thanks. Song 在 2026/1/28 12:28, Alexei Starovoitov 写道: > On Thu, Jan 22, 2026 at 1:04 AM wrote: >> >> From: Song Chen >> >> I had an ebpf program which calls a kfunc defined and >> implemented in one of my kernel modules, they were working >> fine in 6.16, but was broken by libbpf in 6.19, the error >> message was: >> >> libbpf: extern (func ksym) 'bpf_strstr': func_proto [5] >> incompatible with vmlinux [94389] >> >> yes, the reason is there is a new added kfunc in kernel 6.19 >> which happens to be the same name with my kfunc. However the >> error message is not obvious enough to address problem >> immediately. > > I don't quite understand what you're trying to say. > "broken by libbpf"?! You mean that kernel 6.19 got > new kfunc bpf_strstr() ? > Why libbpf error is relevant? > You mean you had your own custom .h file where > you defined your own kfunc from a custom module > and libbpf complained that your bpf_strstr() kfunc > definition doesn't match the kernel 6.19 ? let me explain: I had a module, defined a kfunc(bpf_strstr) in its c file and register it through register_btf_kfunc_id_set.I also had a ebpf program to use bpf_strstr in this module. They were working fine in kernel 6.16, but kernel 6.19 has its own bpf_strstr, so when i ran my ebpf program in kernel 6.19, libbpf broke it here: bpf_object__resolve_ksym_func_btf_id --bpf_core_types_are_compat --__bpf_core_types_are_compat yes, your understanding is pretty much correct. > > and your proposed solution is ... > >> Therefore, this patches searches duplicated kfunc in >> btf_vmlinux before a kernel module attempts to register kfuncs >> through register_btf_kfunc_id_set, it prints clear error message >> and returns error code if same name kfunc has already implemented >> and registered, then developer knows at the first place. > > Are you saying that the kernel module that supplied bpf_strstr > shouldn't be allowed to register its kfunc if kfunc with > the same name exists in vmlinux. So insmod will fail? yes, two kfuncs of bpf_strstr are registered in the system and one of them is never used, this is a problem. > > This is debatable. I guess we can add such sanity check, agree, even it's not a big deal. > but what about kfunc in module A with the same name as kfunc > in module B? It's in my plan, also go through "list_for_each_entry_safe(btf_mod, tmp, &btf_modules, list)", but i haven't gone that far yet, i can add it. > Currently libbpf tells kernel both btf FD and kfunc btf ID, > though there is a single namespace for all kfuncs from bpf > program pov the kernel and libbpf api-s allow a selection. > > Technically we can hack something in bpf.c to "namespace" kfuncs > and say that the kfunc "foo" is in the module "bar". > It won't be pretty in C, but possible in principle. > > Maybe a kfunc with the same name in the module should be allowed > to override a kfunc in the kernel. > It can be seen as livepatching of kfuncs. > imo that's a more interesting use case than helping > out-of-tree module to produce nicier error. > > pw-bot: cr >