On 8/25/25 10:00 AM, Roman Gushchin wrote:
Martin KaFai Lau <martin.lau@xxxxxxxxx> writes:
On 8/20/25 5:24 PM, Roman Gushchin wrote:
How is it decided who gets to run before the other? Is it based on
order of attachment (which can be non-deterministic)?
Yeah, now it's the order of attachment.
There was a lot of discussion on something similar for tc progs, and
we went with specific flags that capture partial ordering constraints
(instead of priorities that may collide).
https://lore.kernel.org/all/20230719140858.13224-2-daniel@xxxxxxxxxxxxx
It would be nice if we can find a way of making this consistent.
+1
The cgroup bpf prog has recently added the mprog api support also. If
the simple order of attachment is not enough and needs to have
specific ordering, we should make the bpf struct_ops support the same
mprog api instead of asking each subsystem creating its own.
fyi, another need for struct_ops ordering is to upgrade the
BPF_PROG_TYPE_SOCK_OPS api to struct_ops for easier extension in the
future. Slide 13 in
https://drive.google.com/file/d/1wjKZth6T0llLJ_ONPAL_6Q_jbxbAjByp/view
Does it mean it's better now to keep it simple in the context of oom
patches with the plan to later reuse the generic struct_ops
infrastructure?
Honestly, I believe that the simple order of attachment should be
good enough for quite a while, so I'd not over-complicate this,
unless it's not fixable later.
I think the simple attachment ordering is fine. Presumably the current link list
in patch 1 can be replaced by the mprog in the future. Other experts can chime
in if I have missed things.
Once it needs to have an ordering api in the future, it should probably stay
with mprog instead of each subsystem creating its own. The inspection tool
(likely a subcmd in bpftool) can also be created to inspect the struct_ops order
of a subsystem.
