When a specially formatted path is passed to dlopen(), of the form
#number/path
and the number is the valid dirfd file descriptor listed in the
LD_LIBRARY_FDS, interpret it as a relative path name against dirfd
number.
This complements the result returned from dladdr() for such objects
in dli_fname.
Reviewed by: markj
Sponsored by: The FreeBSD Foundation
MFC after: 1 week
Differential revision: https://reviews.freebsd.org/D56152
We currently assert that kn_status is accurate, but there's more room
for error. Neither of these are very likely, but currently we'd blow up
in SLIST*() macros instead of providing more obvious diagnostics. It's
perhaps only worth testing these because knlist_remove() requires
getting logic across both f_attach() and f_detach() correct.
Reviewed by: kib, markj
Differential Revision: https://reviews.freebsd.org/D56211
The influx logic in knote_fdclose() is a little misguided, the resulting
wakeup() call should always be redundant: knote_drop_detached() will
always issue a wakeup before it returns, so anything waiting on *that*
knote that had entered fluxwait should have been woken up then. This is
the obvious divergence from the other influx/wakeup pattern in the
implementation, which will kn_influx-- and then issue the wakeup after
it has processed all of the knotes it can make progress on.
While we're here, the kq_knlist cannot shrink, so we can avoid that
condition in the loop and avoid potentially excessive wakeups from
fluxwait on kqueues that we didn't touch.
Reviewed by: kib, markj
Differential Revision: https://reviews.freebsd.org/D56210
kqueue_fork_copy() is likely to have transitioned at least one knote
through a flux state, so we should check whether we need to wake
anything up on the way out to avoid a possible deadlock.
This was a part of D56210, but we'll close the review with the next
commit.
Fixes: b11289f871 ("kqueuex(2): add KQUEUE_CPONFORK")
Reviewed by: kib, markj
This is a cosmetic change, rather than a functional one: comparing the
knlistsize against the fd requires a little bit of mental gymnastics to
confirm that this is fine and not doing unnecessary work in some cases.
Notably, one must consider that kq_knlistsize only grows in KQEXTENT
chunks, which means that concurrent threads trying to grow the kqueue
to consecutive fds will usually not result in the list being replaced
twice. One can also more clearly rule out classes of arithmetic
problems in the final `else` branch.
Reviewed by: kib, markj
Differential Revision: https://reviews.freebsd.org/D56209
After reading both manual pages, our TCP_MAXUNACKTIME is fairly
similar to the TCP_USER_TIMEOUT, the only considerable difference
is ours is in seconds and linux's in milliseconds.
Round up linux's in setsockopt(2) to a next whole second and
clamp ours getter to UINT_MAX ms.
Reviewed by: tuexen, glebius
Differential Revision: https://reviews.freebsd.org/D56168
MFC after: 2 weeks
Sponsored by: Sippy Software, Inc.
It's a bit silly to have iov_to_buf() and buf_to_iov() return a ssize_t
to begin with, just to be able to return -1 for error. Change this to
size_t and use 0 as an error indicator, which won't require any changes
to the code using these functions.
While here, switch iov_to_buf() to use reallocf() instead of realloc().
Reviewed by: jhb
Fixes: 2a514d377b ("bhyve/virtio-scsi: Preallocate all I/O requests")
Differential Revision: https://reviews.freebsd.org/D55800
* cd9660_rrip_slink() did not check that the lengths of individual
entries do not exceed the length of the overall record.
* cd9660_rrip_altname() did not check that the length of the record
was at least 5 before subtracting 5 from it.
Note that in both cases, a better solution would be to check the length
of the data before calling the handler, or immediately upon entry of
the handler, but this would require significant refactoring.
MFC after: 1 week
Reported by: Calif.io in collaboration with Claude and Anthropic Research
Reported by: Adam Crosser, Praetorian
Reviewed by: markj
Differential Revision: https://reviews.freebsd.org/D56215
For instance, this is used by DRM drivers to declare the EDID property
of an GPU output connector:
sysctl -b sys.device.drmn1.card0.card0-DP-1.edid | edid-decode
...
Block 0, Base EDID:
EDID Structure Version & Revision: 1.4
Vendor & Product Identification:
Manufacturer: SAM
Model: 29814
Serial Number: 810635354 (0x3051505a)
Made in: week 15 of 2025
...
Reviewed by: bz, emaste, wulf
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D55176
We cannot have more than one SPMC device.
Reviewed by: olce
Approved by: olce
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D56062
No functional change since apparently it's fine to compute the size of
a pointer type when the base type is undefined.
Fixes: 0bb9c2b665 ("ip6_mroute: FIBify")
The new PRIV_VMM_CREATE and DESTROY permissions should be allowed by
jails, so need to be added to the list in prison_priv_check(). Then,
modify vmmdev_create() to verify that the jail was created with the
allow.vmm flag. This is already verified when opening /dev/vmmctl, but
checking again doesn't hurt and ensures that one can't pass the
allow.vmm policy by passing a vmmctl fd along a unix domain socket from
outside the jail.
Rename vmm_priv_check() to vmm_jail_priv_check() to make the function's
purpose more clear.
Reported by: novel
Reviewed by: bnovkov
Fixes: d4c05edd41 ("vmm: Add privilege checks to vmmctl operations")
Differential Revision: https://reviews.freebsd.org/D56119
The kernel_pmap lock is a bit special: it does not need the DUPOK flag,
and it really belongs to a different lock class. If it belongs to the
same class as regular pmap locks, then witness may report warnings when
performing UMA allocations under a regular pmap lock, if the allocation
triggers a pmap_growkernel() call.
Replace instances of PMAP_LOCK_INIT(kernel_pmap) with inline mtx_init()
calls to silence some witness warnings for harmless behaviour I see with
some uncommitted test programs.
Reviewed by: alc, kib
MFC after: 2 weeks
Differential Revision: https://reviews.freebsd.org/D56185
The condition after SYSCTL_IN was inverted: success (error == 0) returned
immediately and skipped the NVRAM write path, while failure fell through.
Return only when SYSCTL_IN fails.
Signed-off-by: Weixie Cui <cuiweixie@gmail.com>
Reviewed-by: ngie
Pull-Request: https://github.com/freebsd/freebsd-src/pull/2113
This driver enables bcm2835-virtgpio GPIO controller found on RPi3B and
some CM boards. On which, the ACT (green) LED is connected to this
controller. It is essential for FreeBSD to have this driver to control
this LED.
It will be exposed via gpioled(4).
Reviewed by: mhorne
MFC after: 2 weeks
Differential Revision: https://reviews.freebsd.org/D51456
- add a missing sysctl to the deprecated list
- add a comment to not add new generic sysctls and point to SYSCTL_JAIL_PARAM instead
Reviewed by: jamie
Differential Revision: https://reviews.freebsd.org/D51150
These are not used in our world and kernel build targets. We use the
compiler driver for assembly, and ar adds the archive index (symbol
table) automatically.
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D55964
atexit(3) is one of the cases when _exit(2) must be used instead of
exit(3).
MFC after: 3 days
Reviewed by: mhorne, ziaee
Differential Revision: https://reviews.freebsd.org/D54467
This will fix LINT-NOIP build. This actually adds very little to the
kernel text, e.g. 500 bytes on amd64. A perfect solution would be to
instead declare rss_config.c as 'optional inet | inet6', but that would
fail to build LINT-NOIP in several NIC drivers, that use RSS and
absolutely ignore that both INET and INET6 are optional. It is very
unlikely that vendors who maintain these drivers will will ever chase the
holy grail of a build that doesn't support IPv4 and IPv6.
Fixes: d9c55b2e8c
"Low Power S0 Idle" doesn't mean that much. "System Power Management
Controller" is what "SPMC" stands for in the first place.
Sponsored by: The FreeBSD Foundation
Add support for Cezanne chips. The only real difference vs
Rembrandt/Phoenix is the idlemask register.
Also simplify getting IP block count by having this straight in struct
amdsmu_product and remove Strix Point from the list for now, as that
doesn't support S0ix and our driver can't handle that.
Reviewed by: mckusick
Approved by: mckusick
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D55594
Document the vmgenc(4) ACPI driver which detects virtual machine
cloning and snapshot restoration via the VM Generation ID
specification. The driver reseeds the kernel entropy pool when
a generation change is detected.
MFC after: 3 days
Reviewed by: cem (previous), ziaee
Signed-off-by: Christos Longros <chris.longros@gmail.com>
Differential Revision: https://reviews.freebsd.org/D56011
The 'extern inline' usage is removed.
PR: 277958
Reviewed by: dim
Sponsored by: The FreeBSD Foundation
MFC after: 1 week
Differential revision: https://reviews.freebsd.org/D56139
namely
fegetexceptflag(3)
fetestexcept(3)
fesetround(3)
fegetround(3)
fesetenv(3)
Same as it was done in f39754d51b for feclearexcept(3).
PR: 277958
Reviewed by: dim
Sponsored by: The FreeBSD Foundation
MFC after: 1 week
Differential revision: https://reviews.freebsd.org/D56139
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
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
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
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
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
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
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
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
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
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: a779388f8b if: Protect V_ifnet in vnet_if_return()
MFC after: 1 week
Differential Revision: https://reviews.freebsd.org/D55997
Konstantin Belousov