On Mon, Jul 7, 2025 at 5:01 PM Eduard Zingerman <eddyz87@xxxxxxxxx> wrote: > > On Mon, 2025-07-07 at 16:49 -0700, Alexei Starovoitov wrote: > > On Mon, Jul 7, 2025 at 4:45 PM Eduard Zingerman <eddyz87@xxxxxxxxx> wrote: > > > > > > On Wed, 2025-06-18 at 15:08 +0000, Anton Protopopov wrote: > > > > On 25/06/17 08:22PM, Alexei Starovoitov wrote: > > > > > On Sun, Jun 15, 2025 at 1:55 AM Anton Protopopov > > > > > <a.s.protopopov@xxxxxxxxx> wrote: > > > > > > > > > > > > The final line generates an indirect jump. The > > > > > > format of the indirect jump instruction supported by BPF is > > > > > > > > > > > > BPF_JMP|BPF_X|BPF_JA, SRC=0, DST=Rx, off=0, imm=fd(M) > > > > > > > > > > > > and, obviously, the map M must be the same map which was used to > > > > > > init the register rX. This patch implements this in the following, > > > > > > hacky, but so far suitable for all existing use-cases, way. On > > > > > > encountering a `gotox` instruction libbpf tracks back to the > > > > > > previous direct load from map and stores this map file descriptor > > > > > > in the gotox instruction. > > > > > > > > > > ... > > [...] > > > > > > > > > > > This is obviously broken and cannot be made smarter in libbpf. > > > > > It won't be doing data flow analysis. > > > > > > > > > > The only option I see is to teach llvm to tag jmp_table in gotox. > > > > > Probably the simplest way is to add the same relo to gotox insn > > > > > as for ld_imm64. Then libbpf has a direct way to assign > > > > > the same map_fd into both ld_imm64 and gotox. > > > > > > > > This would be nice. > > > > > > I did not implement this is a change for jt section + jt symbols. > > > It can be added, but thinking about it again, are you sure it is > > > necessary to have map fd in the gotox? > > > > > > Verifier should be smart enough already to track what map the rX in > > > the `gotox rX` is a derivative of. It can make use of > > > bpf_insn_aux_data->map_index to enforce that only one map is used with > > > a particular gotox instruction. > > > > How would it associate gotox with map (set of IPs) at check_cfg() stage? > > llvm needs to help. > > check_cfg(), right, thank you. > But still, this feels like an artificial limitation. > Just because we have a check_cfg() pass as a separate thing we need > this hint. and insn_successors(). All of them have to work before the main verifier analysis.
