Force AttachXDP to overwrite an already attached program

[FHRNet]

Hi,

Generally when one uses link.AttachXDP the call will error out if there's an XDP program already bound to the interface (for example, if a program was pinned during previous execution)

l, err := link.AttachXDP(link.XDPOptions{
	Program:   objs.Filter,
	Interface: iface.Index,
	Flags:     link.XDPDriverMode,
})

// err => failed to attach link: create link: file exist

Is there a way to make AttachXDP forcibly overwrite the attached program without having to unload it first?

Some network cards/drivers struggle and misbehave if you completely unload an XDP program and load in a new one under load (can cause the device to reset/hang etc), I'm thinking simply updating the program instead would lessen the impact during software updates.

[florianl]

With (*RawLink) Update(..) you should be able to update the eBPF program for an existing link.

// Attach eBPF program to XDP hook.
lnk, err := AttachXDP(XDPOptions{...})

[..]

// Some time later, replace the eBPF program with a new one
err := lnk.Update(&ebpf.Program{..})

[FHRNet]

Thanks! Update is a function that I completely missed somehow.

What I ended up doing is combining it with LoadPinnedLink(...) to be able to restart the process fully and then pick the XDP program back up, seems to work well.

// on fresh start
l, err := link.AttachXDP(...)
l.Pin(...)

// on process restart
l, err := link.LoadPinnedLink(bpfFSPathProgram, &ebpf.LoadPinOptions{})
err = l.Update(&ebpf.Program{..})```

[ti-mo]

@FHRNet That's indeed exactly how it's supposed to be used! Glad you got it to work.

As an aside, the link mechanism was built exactly to prevent multiple tools on the same host from detaching each others' programs. This is/used to be possible using netlink, and was a source of headaches for admins.

With links, you either need to know the pin path of the program you want to replace. Or, if your tool needs exclusivity, don't pin the link at all, but then it'll detach when the application exits.