Page MenuHomeFreeBSD

if_gre: Add netlink support with tests
Needs ReviewPublic

Authored by pouria on Jan 1 2026, 6:11 PM.
Tags
None
Referenced Files
Unknown Object (File)
Tue, Jan 20, 3:18 AM
Unknown Object (File)
Sun, Jan 18, 7:48 AM
Unknown Object (File)
Mon, Jan 12, 4:41 PM
Unknown Object (File)
Mon, Jan 12, 4:28 PM
Unknown Object (File)
Sat, Jan 10, 4:48 PM
Unknown Object (File)
Sat, Jan 10, 4:49 AM
Unknown Object (File)
Jan 8 2026, 8:06 PM
Unknown Object (File)
Jan 8 2026, 3:42 PM
Subscribers

Details

Reviewers
glebius
zlei
melifaro
Group Reviewers
network
Summary

Add netlink support to if_gre

Test Plan

I also wrote tests for gre, since it doesn't have it before.

# kyua test -k /usr/tests/sys/netlink/Kyuafile test_rtnl_gre:test_rtnl_gre
test_rtnl_gre:test_rtnl_gre  ->  passed  [0.002s]
Results file id is usr_tests_sys_netlink.20260101-180800-774463
Results saved to /root/.kyua/store/results.usr_tests_sys_netlink.20260101-180800-774463.db
1/1 passed (0 failed)

Diff Detail

Repository
rG FreeBSD src repository
Lint
Lint Passed
Unit
No Test Coverage
Build Status
Buildable 70395
Build 67278: arc lint + arc unit

Event Timeline

pouria requested review of this revision.Jan 1 2026, 6:11 PM

There're three tasks in this change,

  1. Migrate to new if_clone KPI
  2. Refactor some ioctls, say GRESKEY
  3. Add netlink support

The first two are simple and easy to review, I expect them can be landed quickly. I'd support you to split the change.

There're three tasks in this change,

  1. Migrate to new if_clone KPI
  2. Refactor some ioctls, say GRESKEY
  3. Add netlink support

The first two are simple and easy to review, I expect them can be landed quickly. I'd support you to split the change.

I understand your perspective, however, migrating directly to the new if_clone_addreq_v2 without netlink support is not possible.
I could migrate to if_clone_addreq without netlink support first, but then transition to v2 to support netlink would ultimately be redundant.
The same reasoning applies to the GRESKEY ioctl.
Refactoring that ioctl is intended to reuse those configuration functions through netlink.
Therefore, without netlink support, refactoring the ioctl interface is pointless.

sys/netlink/route/interface.h
252

Maybe IFLA_TUNNEL_GRE_UDP?

tests/sys/netlink/test_rtnl_gre.c
2

Please add BSD license and you authorship.

  • Add types in if_gre.h to fix world build
  • Add copyright to test_rtnl_gre.c
  • Rebase to main and fix cleanup in test_rtnl_gre.

@glebius done.

Approved, but please address comment in the module event switch statement.

sys/net/if_gre.c
1146

See note about /* FALLTHROUGH */ in style(9). This actually is not only about style. Some linters may complain on this function unless this special comment is added. Adding break; instead will also work. So add either of them, depending on how would you expect gremodevent() change in the future. IMHO, break; is more likely to stay here in future.

This revision is now accepted and ready to land.Wed, Feb 4, 5:16 PM

Add break to MOD_LOAD to address @glebius comment.

This revision now requires review to proceed.Thu, Feb 5, 12:22 PM

Can you take a look at this patch? Maybe you can reuse some pieces, it should fix 275474 and also make access to softc in a safer way.

In D54443#1259973, @ae wrote:

Can you take a look at this patch? Maybe you can reuse some pieces, it should fix 275474 and also make access to softc in a safer way.

I will, tonight. Thank you!

This revision is now accepted and ready to land.Thu, Feb 5, 5:36 PM
This comment was removed by pouria.
This revision now requires review to proceed.Thu, Feb 5, 10:11 PM

Rollback. wrong revision. sorry for noise!

In D54443#1259973, @ae wrote:

Can you take a look at this patch? Maybe you can reuse some pieces, it should fix 275474 and also make access to softc in a safer way.

I see no problems with this patch alongside my changes.
We have a minor conflict, which I resolved at github.
Also, AFAICU, I don't need to use priv instead of softc for netlink because I didn't touch the data plane.
Your code will synchronize priv and softc together so there should be no problem to directly using the softc.

Should I do anything else?

I see no problems with this patch alongside my changes.
We have a minor conflict, which I resolved at github.
Also, AFAICU, I don't need to use priv instead of softc for netlink because I didn't touch the data plane.
Your code will synchronize priv and softc together so there should be no problem to directly using the softc.

Should I do anything else?

Thanks! Then I will rebase the patch after your commit.

@zlei
Can I have your opinion on this review, too?
I'm ready to commit it, but I'd prefer to wait for your feedback as well.

Except for the tests, do you have real usage of the netlink protocol ? The commit message does not mention it. So it is better to explain, otherwise would confuse people.

I'm still learning netlink. @melifaro introduced netlink to FreeBSD and I believe he has better insight over the design.

sys/net/if_gre.c
408

Naming is hard. I'd personally prefer to use prefix, say gre_nl_set_addr() other than suffix gre_set_addr_nl(), so that it will be easier to grep all netlink related function.

408

Probably you do not want to interleave netlink related functions with domain specific functions.

I'd suggest you move all netlink related functions down to the end of if_gre.c, just before gremodevent().

sys/net/if_gre.h
165

Naming. I think nl_gre_parsed reads more fluently than nl_parsed_gre. Well I'm not a native speaker, just my personal opinion.

Will this be public KPI ? Probably this should be in sys/net/if_gre.c ?

sys/netlink/route/interface.h
251

It appears these will be public KPI. Will we want to sync with Linux about the naming ? ( I have not looked at Linux sources about them, just presume it has. )

If roll our own types, what's the policy to assign type to existing tunnels ( me, gif, vxlan, etc ) ?

Probably @melifaro had thoughts on this ( ever ).

tests/sys/netlink/test_rtnl_gre.c
70

Small nits. Probably test_gre_nl or test_nl_gre is better ? test_rtnl_gre reads "test route netlink gre" to me. Get a little confused by the naming rt.

sys/net/if_gre.c
408

Naming is hard. I'd personally prefer to use prefix, say gre_nl_set_addr() other than suffix gre_set_addr_nl(), so that it will be easier to grep all netlink related function.

This suffix is already widely used inside the kernel.
fgrep -r '_nl(' sys/net*: if_vlan, if_clone, the netlink itself...

408

Probably you do not want to interleave netlink related functions with domain specific functions.

I'd suggest you move all netlink related functions down to the end of if_gre.c, just before gremodevent().

Good point, I will. Thanks!

sys/net/if_gre.h
165

Naming. I think nl_gre_parsed reads more fluently than nl_parsed_gre. Well I'm not a native speaker, just my personal opinion.

The reason for this is trying to match naming of other netlink parsers.
for example we have nl_parsed_link.

Will this be public KPI ? Probably this should be in sys/net/if_gre.c ?

Yes it's, I'll add the support for ifconfig netlink implementation of gre interface in another review.
however, it needs to know what kind of data is available to it.
I will mention you for the example implementation in geneve.

sys/netlink/route/interface.h
251

It appears these will be public KPI. Will we want to sync with Linux about the naming ? ( I have not looked at Linux sources about them, just presume it has. )

I have tried to find a middle ground between melifaro implementation and linux naming!
For example, I used the _GUE suffix for GRE over UDP even though I don't like it! However, Glebius noticed that part too.
So I decided to change it.
FYI, this part is defined in include/uapi/linux/if_tunnel.h of linux.

If roll our own types, what's the policy to assign type to existing tunnels ( me, gif, vxlan, etc ) ?

Currently, there is no policy.
we can write a policy for it.
however that needs @melifaro input as you said before.
I think he's busy, so we have to go on for now.

tests/sys/netlink/test_rtnl_gre.c
70

Small nits. Probably test_gre_nl or test_nl_gre is better ? test_rtnl_gre reads "test route netlink gre" to me. Get a little confused by the naming rt.

I tried to match the current naming, especially test_rtnl_iface since it already has another test interface (if_vlan) inside it.
gre and other interfaces are part of rtnetlink. So I thought it would be reasonable to use that prefix.

Move netlink related functions to the end of file.
@zlei done.

@zlei
Did my answer resolve you comments?
Do you have any other input?

Make nl_parsed_gre private.
@zlei done.
After doing my research, If find out you were right.
Dictating netlink data structure to userland defeats
the purpose of using netlink in first place.