Page MenuHomeFreeBSD

net/wireguard-kmod: Tie kernel module to a specific release branch
Needs ReviewPublic

Authored by decke on May 28 2022, 11:00 AM.
Tags
None
Referenced Files
Unknown Object (File)
Mon, Oct 28, 9:34 AM
Unknown Object (File)
Sat, Oct 26, 11:24 AM
Unknown Object (File)
Fri, Oct 25, 10:12 PM
Unknown Object (File)
Oct 5 2024, 6:13 PM
Unknown Object (File)
Oct 3 2024, 12:04 AM
Unknown Object (File)
Aug 30 2024, 10:42 AM
Unknown Object (File)
Aug 28 2024, 10:42 AM
Unknown Object (File)
Aug 18 2024, 2:22 AM
Subscribers

Details

Reviewers
kevans
jhb
Group Reviewers
portmgr
Summary

In the spirit of D16119 we really want to have the same safetynet also for net/wireguard-kmod.

Shamelessly copied from D16119:

Use a more restricted range of supported __FreeBSD_version values for
the if_wg kernel module since it uses internal KPIs for which KBI
stability is not guaranteed.  DECLARE_MODULE_TIED would tie the module
to a specific __FreeBSD_version which would cause the module to stop
loading when an SA or EN is pushed on a release branch.  Instead, use
DECLARE_MODULE_MAXVER with an upper bound that is limited to the range
of a releng branch so that a module built on X.Y will load on X.Y with
SAs or ENs applied but will fail to load on X.Y-1 or X.Y+1.
Test Plan
  • poudriere tests successful
  • portlint tests successful

https://ports.bluelife.at/builds/20220528-10:45:21.25598/

Diff Detail

Repository
R11 FreeBSD ports repository
Lint
Lint Skipped
Unit
Tests Skipped

Event Timeline

decke created this revision.
decke edited the summary of this revision. (Show Details)
decke added reviewers: kevans, jhb.

I really don't think wg uses volatile enough underlying KPIs to decide this is warranted just yet

I really don't think wg uses volatile enough underlying KPIs to decide this is warranted just yet

In theory probably not but in practice 13.0 -> 13.1 caused panics because of that. I have at least
PR264114, PR264111 and two private reports.

I really don't think wg uses volatile enough underlying KPIs to decide this is warranted just yet

In theory probably not but in practice 13.0 -> 13.1 caused panics because of that. I have at least
PR264114, PR264111 and two private reports.

Right, but if anyone had tested and reported this during the 13.1 process, we probably could have fixed the KBI break if we had actually known about it. These other ports tend to have more involved breakage

It seems we do not have any working procedure in place to avoid KBI breaks so it's working by pure luck/risk. Let's see what portmgr discussion reveals.

Hmm, I didn't really think wg used enough unstable APIs, but if it broke in 13.1 then it's probably fine to just do this in the port.