Florian Westphal fw@strlen.de writes:
Toke Høiland-Jørgensen toke@redhat.com wrote:
Florian Westphal fw@strlen.de writes:
For bpf a flag during link attachment seemed like the best way to go.
Right, I wasn't disputing that having a flag to load a module was a good idea. On the contrary, I was thinking we'd need many more of these if/when BPF wants to take advantage of more netfilter code. Say, if a BPF module wants to call into TPROXY, that module would also need go be loaded and kept around, no?
That seems to be a different topic that has nothing to do with either bpf_link or netfilter?
If the program calls into say, TPROXY, then I'd expect that this needs to be handled via kfuncs, no? Or if I misunderstand, what do you mean by "call into TPROXY"?
And if so, thats already handled at bpf_prog load time, not at link creation time, or do I miss something here?
AFAIU, if prog uses such kfuncs, verifier will grab needed module ref and if module isn't loaded the kfuncs won't be found and program load fails.
...
Or we are talking about implicit dependencies, where program doesn't call function X but needs functionality handled earlier in the pipeline?
The only two instances I know where this is the case for netfilter is defrag + conntrack.
Well, I was kinda mixing the two cases above, sorry about that. The "kfuncs locking the module" was not present in my mind when starting to talk about that bit...
As for the original question, that's answered by your point above: If those two modules are the only ones that are likely to need this, then a flag for each is fine by me - that was the key piece I was missing (I'm not a netfilter expert, as you well know).
Thanks for clarifying, and apologies for the muddled thinking! :)
-Toke