On Thu, Jun 08, 2023 at 10:38:12AM -0700, Yonghong Song wrote: > > > On 6/7/23 2:04 PM, Krister Johansen wrote: > > When bpf subprograms are in use, the main program is not jit'd after the > > subprograms because jit_subprogs sets a value for prog->bpf_func upon > > success. Subsequent calls to the JIT are bypassed when this value is > > non-NULL. This leads to a situation where the main program and its > > func[0] counterpart are both in the bpf kallsyms tree, but only func[0] > > has an extable. Extables are only created during JIT. Now there are > > two nearly identical program ksym entries in the tree, but only one has > > an extable. Depending upon how the entries are placed, there's a chance > > that a fault will call search_extable on the aux with the NULL entry. > > > > Since jit_subprogs already copies state from func[0] to the main > > program, include the extable pointer in this state duplication. The > > alternative is to skip adding the main program to the bpf_kallsyms > > table, but that would mean adding a check for subprograms into the > > middle of bpf_prog_load. > > I think having two early identical program ksym entries is bad. > When people 'cat /proc/kallsyms | grep <their program name>', > they will find two programs with identical kernel address but different > hash value. This is just very confusing. I think removing the > duplicate in kallsyms is better from user's perspective. Thanks for all the feedback. In terms of resolving this confusion my inclination is to use the main program. That way users see in kallsyms the same tag that is reported by bpftool. On the other hand, the tag in kallsyms won't match the sha1 of that actual chunk of code. Is anything relying on the hash in the tag and the digest of the code agreeing? -K