This is a display of mostly-automatically-classified git commits from 2026-03-30 to 2026-04-05.
This report is still in progress.
DEBUG: This version of the report is primarily for checking the classifiers, and therefore contains extra information (in this colour).
Table of contents and commits per category:
| (0) | Highlighted commits (these are copies, not in stats) | |
| 0 | 0.0% | Userland programs |
| 0 | 0.0% | Documentation |
| 4 | 14.8% | Hardware support |
| 10 | 37.0% | Networking |
| 2 | 7.4% | System administration |
| 6 | 22.2% | Libraries |
| 0 | 0.0% | Filesystems |
| 2 | 7.4% | Kernel |
| 1 | 3.7% | Build system |
| 0 | 0.0% | Internal organizational stuff |
| 2 | 7.4% | Testing |
| 0 | 0.0% | Style, typos, and comments |
| 0 | 0.0% | Contrib code |
| 0 | 0.0% | Reverted commits |
| 0 | 0.0% | Unclassified commits |
| 27 | 100% | total |
| Technical notes about this page |
debug: info about the automatic classification
| num | % | num changed | stage |
|---|---|---|---|
| 1 | 3.7% | 0 | 02-filenames_wildcards |
| 1 | 3.7% | 0 | 02b-filenames_wildcards2 |
| 16 | 59.3% | 0 | 03-filenames_plain1 |
| 8 | 29.6% | 0 | 04-filenames_plain2 |
| 1 | 3.7% | 0 | Manually-classified commits |
| 0 | 0.0% | 0 | Unclassified commits |
debug: more stats
| num | % | stage |
|---|---|---|
| 0 | 0.0% | Misclassified commits |
| 26 | 96.3% | Classified commits, no corrections |
debug: groups
| 0 | 0.0% | num in revert |
| 0 | 0.0% | num in fixes |
| 0 | 0.0% | num in consecutive |
| 0 | 0.0% | Commits in groups |
For extra visibility, these are copies of commits found in
other sections. Most (if not all) come from the commit message
containing "Relnotes:", or commits modifying
UPDATING.
-- no commits in this category this week --
Commits about commands found in man section 1 (other than networking).
-- no commits in this category this week --
Man pages, release notes, etc.
-- no commits in this category this week --
Hardware drivers and architecture-specific code.
Reported by: Tom <freebsd@fizz.buzz> Reviewed by: markj Tested by: Tom <freebsd@fizz.buzz> MFC after: 2 weeks Sponsored by: The FreeBSD Foundation Differential Revision: https://reviews.freebsd.org/D56021
debug: classified in
03-filenames_plain1 by
'sys/amd64/'
MFC after: 1 week Fixes: https://cgit.freebsd.org/src/commit/?id=1e39b5d4833e ("nvme_sim: Attach as a child of nvme") Sponsored by: The FreeBSD Foundation
debug: classified in
03-filenames_plain1 by
'sys/dev/'
This lock doesn't need to be held across seldrain/knlist_destroy. It is also redundant (and a bug) to hold it across knlist_add and knlist_remove since it is the mutex for the knlist. PR: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=293901 Reported by: Jiaming Zhang <r772577952@gmail.com> Reviewed by: markj MFC after: 1 week Differential Revision: https://reviews.freebsd.org/D55994
debug: classified in
03-filenames_plain1 by
'sys/x86/'
This is effectively a no-op, as it does not make use of the sndcard_func->varinfo field, so eventually ua_probe() always succeeds. Also change ua_probe()'s value to 0. There is no need to return BUS_PROBE_DEFAULT, because snd_uaudio() attaches the sound(4)'s children with bus_attach_children(). Sponsored by: The FreeBSD Foundation MFC after: 1 week Reviewed by: markj Differential Revision: https://reviews.freebsd.org/D56160
debug: classified in
03-filenames_plain1 by
'sys/dev/'
Network-related commands, library, and kernel.
The thread running if_vmove_reclaim() may race with other threads those
running if_detach(), if_vmove_loan() or if_vmove_reclaim(). In case the
current thread loses race, two issues arise,
1. It is unstable and unsafe to access ifp->if_vnet,
2. The interface is removed from "active" list, hence if_unlink_ifnet()
can fail.
For the first case, check against source prison's vnet instead, given
the interface is obtained from that vnet.
For the second one, return ENODEV to indicate the interface was on the
list but the current thread loses race, to distinguish from ENXIO, which
means the interface or child prison is not found. This is the same with
if_vmove_loan().
Reviewed by: kp, pouria
Fixes: https://cgit.freebsd.org/src/commit/?id=a779388f8bb3 if: Protect V_ifnet in vnet_if_return()
MFC after: 1 week
Differential Revision: https://reviews.freebsd.org/D55997
debug: classified in
03-filenames_plain1 by
'sys/net/'
I would like to support per-FIB multicast routing tables, such that one can run a routing daemon per-FIB, with each daemon oblivious to the existence of others. Currently the multicast routing code is completely unaware of FIBs. To that end, start collecting various global variables in ip_mroute.c into a per-VNET struct mfctable. In a future patch this will be expanded into an array of mfctable structures, one per FIB. For now, all of the state is collected into V_mfctables[0]. Each mfctable contains, among other things: - a pointer to the routing socket, if routing is enabled, - a hash table of routing cache entries, - an table of network interfaces participating in the routing configuration This change has no functional effect, it is just factoring out these global variables to make the subsequent patches simpler. MFC after: 2 weeks Sponsored by: Stormshield Sponsored by: Klara, Inc. Differential Revision: https://reviews.freebsd.org/D55237
debug: classified in
03-filenames_plain1 by
'sys/netinet/'
As in the IPv4 version of this change, I added a struct mf6ctable structure which holds all global routing table state, soon to become per-FIB state. Note that much of the v6 multicast routing code was not VNETified; this change fixes that too. MFC after: 2 weeks Sponsored by: Stormshield Sponsored by: Klara, Inc. Differential Revision: https://reviews.freebsd.org/D55238
debug: classified in
03-filenames_plain1 by
'sys/netinet6/'
The multicast routing code will start implementing per-FIB routing tables. As a part of this, it needs to be notified when the number of FIBs changes, so that it can expand its tables. Add an eventhandler for this purpose. MFC after: 2 weeks Sponsored by: Stormshield Sponsored by: Klara, Inc. Differential Revision: https://reviews.freebsd.org/D55239
debug: classified in
03-filenames_plain1 by
'sys/net/'
Use the new rtnumfibs_change event to expand the mfctable array when the number of FIBs increases. MFC after: 2 weeks Sponsored by: Stormshield Sponsored by: Klara, Inc. Differential Revision: https://reviews.freebsd.org/D55240
debug: classified in
03-filenames_plain1 by '['sys/netinet/',
'sys/netinet6/']'
Modify the control plane (ioctl and socket option handlers) to use the routing socket FIB to index into the mfctable array. Modify the forwarding plane to use the mbuf's FIB to determine which routing table to use. MFC after: 2 weeks Sponsored by: Stormshield Sponsored by: Klara, Inc. Differential Revision: https://reviews.freebsd.org/D55241
debug: classified in
03-filenames_plain1 by
'sys/netinet/'
Modify the control plane (ioctl and socket option handlers) to use the routing socket FIB to index into the mfctable array. Modify the forwarding plane to use the mbuf's FIB to determine which routing table to use. MFC after: 2 weeks Sponsored by: Stormshield Sponsored by: Klara, Inc. Differential Revision: https://reviews.freebsd.org/D55242
debug: classified in
03-filenames_plain1 by
'sys/netinet6/'
MFC after: 2 weeks Sponsored by: Stormshield Sponsored by: Klara, Inc. Differential Revision: https://reviews.freebsd.org/D55243
debug: classified in
03-filenames_plain1 by
'sys/netinet6/'
There's no need to pass a pointer to the interface number. No functional change intended. MFC after: 2 weeks Sponsored by: Stormshield Sponsored by: Klara, Inc. Differential Revision: https://reviews.freebsd.org/D55245
debug: classified in
03-filenames_plain1 by
'sys/netinet6/'
When an interface goes away we need to make sure the v6 multicast routing tables don't carry any dangling references to the ifnet. The v4 code handles this already. Copy the approach there and use an eventhandler to purge the corresponding MIF, if one exists, and further go through all routes in the FIB and remove references to the interface. MFC after: 2 weeks Sponsored by: Stormshield Sponsored by: Klara, Inc. Differential Revision: https://reviews.freebsd.org/D55246
debug: classified in
03-filenames_plain1 by
'sys/netinet6/'
Stuff in man section 8 (other than networking).
Some Kyua directories were improperly tagged as belonging to the tests package. Move them to the kyua package, which contains all of the files found in these directories. PR: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=294129 MFC after: 1 week Reviewed by: ivy, emaste Differential Revision: https://reviews.freebsd.org/D56159
debug: classified in
03-filenames_plain1 by 'etc/'
Reviewed by: dim, emaste, markj Sponsored by: The FreeBSD Foundation MFC after: 1 week Differential revision: https://reviews.freebsd.org/D56151
debug: classified in
03-filenames_plain1 by
'libexec/'
namely
fegetexceptflag(3)
fetestexcept(3)
fesetround(3)
fegetround(3)
fesetenv(3)
Same as it was done in f39754d51b7dc65c4cf9f for feclearexcept(3).
PR: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=277958
Reviewed by: dim
Sponsored by: The FreeBSD Foundation
MFC after: 1 week
Differential revision: https://reviews.freebsd.org/D56139
debug: classified in
04-filenames_plain2 by 'lib/'
namely
fegetexceptflag(3)
fesetexceptflag(3)
feraiseexcept(3)
fetestexcept(3)
fegetround(3)
fesetround(3)
fegetenv(3)
feholdexcept(3)
fesetenv(3)
feupdateenv(3)
feenableexcept(3)
fedisableexcept(3)
fegetexcept(3)
PR: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=277958
Reviewed by: dim
Sponsored by: The FreeBSD Foundation
MFC after: 1 week
Differential revision: https://reviews.freebsd.org/D56139
debug: classified in
04-filenames_plain2 by 'lib/'
namely
fegetexceptflag(3)
fesetexceptflag(3)
feraiseexcept(3)
fetestexcept(3)
fegetround(3)
fesetround(3)
fegetenv(3)
feholdexcept(3)
fesetenv(3)
feupdateenv(3)
feenableexcept(3)
fedisableexcept(3)
fegetexcept(3)
PR: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=277958
Reviewed by: dim
Sponsored by: The FreeBSD Foundation
MFC after: 1 week
Differential revision: https://reviews.freebsd.org/D56139
debug: classified in
04-filenames_plain2 by 'lib/'
namely
fegetexceptflag(3)
fesetexceptflag(3)
feraiseexcept(3)
fetestexcept(3)
fegetround(3)
fesetround(3)
fegetenv(3)
feholdexcept(3)
fesetenv(3)
feupdateenv(3)
feenableexcept(3)
fedisableexcept(3)
fegetexcept(3)
PR: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=277958
Reviewed by: dim
Sponsored by: The FreeBSD Foundation
MFC after: 1 week
Differential revision: https://reviews.freebsd.org/D56139
debug: classified in
04-filenames_plain2 by 'lib/'
namely
fegetexceptflag(3)
fesetexceptflag(3)
feraiseexcept(3)
fetestexcept(3)
fegetround(3)
fesetround(3)
fegetenv(3)
feholdexcept(3)
fesetenv(3)
feupdateenv(3)
feenableexcept(3)
fedisableexcept(3)
fegetexcept(3)
PR: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=277958
Reviewed by: dim
Sponsored by: The FreeBSD Foundation
MFC after: 1 week
Differential revision: https://reviews.freebsd.org/D56139
debug: classified in
04-filenames_plain2 by 'lib/'
The 'extern inline' usage is removed. PR: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=277958 Reviewed by: dim Sponsored by: The FreeBSD Foundation MFC after: 1 week Differential revision: https://reviews.freebsd.org/D56139
debug: classified in
04-filenames_plain2 by 'lib/'
-- no commits in this category this week --
Kernel stuff (other than networking, filesystems, and drivers).
The call to vn_start_write_refed() from vfs_write_resume() with
'mplocked' set to 'true' exactly boils down to doing an increment of
'mnt_writeopcount', albeit with lots of unnecessary verifications.
Replace it with an inline incrementation. As the original call was the
last with 'mplocked' with 'true', remove the 'mplocked' parameter from
vfs_write_resume(), simplifying its code accordingly ('mplocked' always
false).
While here, in vfs_write_resume(), initialize 'error' out of the mount
lock.
Reviewed by: kib
MFC after: 1 week
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D56108
debug: classified in
04-filenames_plain2 by 'sys/'
Approved by: ziaee Differential Revision: https://reviews.freebsd.org/D56015
debug: classified in
04-filenames_plain2 by 'sys/'
Up to now the LinuxKPI wlan drivers were using local variables starting with a WITH_ prefix in their Makefiles. That is likely to collide with other mechanisms like WITH_ and WITHOUT_ from src.conf. Adjust the local variables to use a driver name prefix for now to control what is built and what is not. These variables are mainly for the time of development so we can turn off/on a feature or bus attachment while working on it. Otherwise they are there for documentation purposes. The only reason one would change them locally would be if someone was to build a very custom image and not want certain bits (e.g., USB support) being compiled into the modules. While here, try to harmonize some parts of the Makefiles. Suggested by: imp Discussed with: imp Reviewed by: imp Sponsored by: The FreeBSD Foundation MFC after: 3 days Differential Revision: https://reviews.freebsd.org/D55977
debug: classified in
02-filenames_wildcards by
'.*Makefile'
-- no commits in this category this week --
Parts of ATF (including the licence and some of the documentation) were for some reason part of the tests package instead of the atf package. Moving them to where they logically belong poses no problem since tests already depends on atf. PR: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=294129 MFC after: 1 week Reviewed by: ivy Differential Revision: https://reviews.freebsd.org/D56158
debug: Commit manually moved from "unknown" to "tests".
These use atf_python to create a number of hosts linked to a router. The router runs pimd (for IPv4) or ip6_mrouter (simplistic IPv6 multicast router that I wrote since I couldn't find one in the ports tree). The vnet_host*_handler() methods are invoked in different VNET jails connected to the router; they register the connected epair with a multicast group and verify that they can send messages to each other. The tests are synchronized by sending messages over a unix domain socket. The flow is something like: 1) test startup_method() is called, the unix socket is created, 2) the superclass creates jails and links them together using the declared topology, 3) we wait for all child jails to start up and send a message on the unix socket indicating that they are ready 4) we start the routing daemon in the main jail, 5) the test actually starts; starttest() kicks off the vnet_host*_handlers(), which mostly just verify that they can send messages to each other using multicast packets 6) once they finish running, they signal their completion, and waittest() returns once they're all done There are two tests, repeated for v4 and v6. One just exchanges packets between two hosts, and the other has four hosts divided across two FIBs. MFC after: 2 weeks Sponsored by: Stormshield Sponsored by: Klara, Inc. Differential Revision: https://reviews.freebsd.org/D55244
debug: classified in
02b-filenames_wildcards2 by
'tests\/.*'
These could go in other categories, but it's more clear if they're here instead.
-- no commits in this category this week --
-- no commits in this category this week --
-- no commits in this category this week --
Not classified automatically, and waiting for manual attention.
-- no commits in this category this week --
Dates:
cgit.freebsd.org/src. Git accurately records the
order of commits, but not their dates.Automatic grouping:
This reverts commit \\b([0-9a-fA-F]{40})\\b
and the hash was found in this week's commits.
Automatic categories:
Source code:
Generated with commits-periodical 0.20 at 2026-03-30 17:58:28+00:00.
This work is supported by Tarsnap Backup Inc.
Alternate version: 2026-03-30 (release)