[lldb] Report missing debug map object files once per module (#237285)
eb5f248268fb reports an error for each debug map object file that does
not exist. A binary that keeps its N_OSO entries but not its object
files, like one built elsewhere and left unstripped, gets one error per
object file.
Report the count once per module instead. A module missing a single
object file still gets the message naming that file, and the per-file
errors remain available through "image dump separate-debug-info".
rdar://189926934
e1000: clear VFTA when last VLAN is removed
The conventional VLAN filter update skipped zero shadow words. Removing
the final VLAN represented by a VFTA word therefore left the hardware
bit programmed even though the software shadow was clear.
Pass the changed word to em_if_vlan_filter_write() and write it even
when its new value is zero. Retained nonzero words continue to be
replayed as before.
(cherry picked from commit a9305a6f50be89f22c7a469aeee4c3bea2086ace)
[lldb] Remove ConstString from DataFormatters interfaces (#237013)
We're now at the point where almost all remaining ConstStrings can be
removed from the DataFormatters library. There are 2 left, both of which
are still required because of calls into ValueObject.
netgraph/ng_ksocket: Enter epoch on NG_SEND_DATA_ONLY
The work queued by ng_send_fn() is intentionally processed
outside of the epoch in ngthread().
It is ng_ksocket's responsibility to enter epoch if it decides
to send data from such work.
Reviewed by: glebius
Fixes: 104827151e2a ("ng_iface: don't recursively enter epoch ...")
Differential Revision: https://reviews.freebsd.org/D60589
(cherry picked from commit 67be955f6bd5d5b51fdee407969d1a7cde156f65)
netgraph/ng_ksocket: Enter epoch on NG_SEND_DATA_ONLY
The work queued by ng_send_fn() is intentionally processed
outside of the epoch in ngthread().
It is ng_ksocket's responsibility to enter epoch if it decides
to send data from such work.
Reviewed by: glebius
Fixes: 104827151e2a ("ng_iface: don't recursively enter epoch ...")
Differential Revision: https://reviews.freebsd.org/D60589
(cherry picked from commit 67be955f6bd5d5b51fdee407969d1a7cde156f65)
ng_socket: plug node reference leak
There is no need to reference node in its constructor, the framework
already granted us a reference. This extraneous reference was later given
back on socket detach. However, if node is destroyed before the socket,
the node was leaked. This leak was harmless until VIMAGE, where
vnet_netgraph_uninit() would cycle through all nodes and shut them down
expecting them to not exist after the shutdown.
Fixes: 19284374970533e1aa04020d4f840e8877ed6266
(cherry picked from commit 4d3cbeb7b407e127a5364f86039745068fbfc61f)
ng_socket: plug node reference leak
There is no need to reference node in its constructor, the framework
already granted us a reference. This extraneous reference was later given
back on socket detach. However, if node is destroyed before the socket,
the node was leaked. This leak was harmless until VIMAGE, where
vnet_netgraph_uninit() would cycle through all nodes and shut them down
expecting them to not exist after the shutdown.
Fixes: 19284374970533e1aa04020d4f840e8877ed6266
(cherry picked from commit 4d3cbeb7b407e127a5364f86039745068fbfc61f)
ipfw/nat64: Fix type confusion panic when using wrong NAT64 instance type
Add etlv type validation to ipfw_nat64clat() and ipfw_nat64stl() to
verify that the retrieved instance is actually a nat64clat instance
before use.
All NAT64 instance types share the same srvstate[] array but have
different struct layouts.
Without type validation, using the wrong instance type with
a handler causes type confusion and kernel panic.
Signed-off-by: Teddy Engel <engel.teddy at gmail.com>
PR: 292023
Reviewed by: pouria
Pull Request: https://github.com/freebsd/freebsd-src/pull/2259
(cherry picked from commit 2e6b22abf44d99b84abf17fe25ca2e8f89716c04)
ipfw/nat64: Fix type confusion panic when using wrong NAT64 instance type
Add etlv type validation to ipfw_nat64clat() and ipfw_nat64stl() to
verify that the retrieved instance is actually a nat64clat instance
before use.
All NAT64 instance types share the same srvstate[] array but have
different struct layouts.
Without type validation, using the wrong instance type with
a handler causes type confusion and kernel panic.
Signed-off-by: Teddy Engel <engel.teddy at gmail.com>
PR: 292023
Reviewed by: pouria
Pull Request: https://github.com/freebsd/freebsd-src/pull/2259
(cherry picked from commit 2e6b22abf44d99b84abf17fe25ca2e8f89716c04)
nat64lsn: Fix type confusion panic when using wrong NAT64 instance type
When an ipfw rule references a NAT64 instance by name using
'nat64lsn', the kernel looks up the instance in the shared
srvstate[] array without verifying the instance type.
If the named instance is actually a nat64clat or nat64stl
instance (created with 'nat64clat' or 'nat64stl'), the code
incorrectly casts the instance to nat64lsn_instance and
dereferences the ->cfg pointer, which causes a kernel panic.
The root cause is that all NAT64 instance types share the same
srvstate[] array but have different struct layouts.
For nat64lsn_instance, the field after 'no' is a pointer to nat64lsn_cfg.
For nat64clat_cfg, the same offset contains an embedded nat64_config struct.
Fix by adding a type check after NAT64_LOOKUP() to verify that the
instance's etlv matches IPFW_TLV_NAT64LSN_NAME before proceeding.
If the type doesn't match, return IP_FW_DENY to reject the packet
safely rather than crashing.
[8 lines not shown]
nat64lsn: Fix type confusion panic when using wrong NAT64 instance type
When an ipfw rule references a NAT64 instance by name using
'nat64lsn', the kernel looks up the instance in the shared
srvstate[] array without verifying the instance type.
If the named instance is actually a nat64clat or nat64stl
instance (created with 'nat64clat' or 'nat64stl'), the code
incorrectly casts the instance to nat64lsn_instance and
dereferences the ->cfg pointer, which causes a kernel panic.
The root cause is that all NAT64 instance types share the same
srvstate[] array but have different struct layouts.
For nat64lsn_instance, the field after 'no' is a pointer to nat64lsn_cfg.
For nat64clat_cfg, the same offset contains an embedded nat64_config struct.
Fix by adding a type check after NAT64_LOOKUP() to verify that the
instance's etlv matches IPFW_TLV_NAT64LSN_NAME before proceeding.
If the type doesn't match, return IP_FW_DENY to reject the packet
safely rather than crashing.
[8 lines not shown]
carp: fix global demotion counter to VRRP advertisements
When net.inet.carp.preempt=1 and a physical interface goes down, the global
V_carp_demotion counter is incremented. For CARP this was already reflected in
outgoing advertisements via DEMOTE_ADVSKEW(), but VRRP sent the raw
sc_vrrp_prio unchanged, so demotion had no effect.
Add DEMOTE_VRRP_PRIO(), a macro analogous to DEMOTE_ADVSKEW():
It subtracts V_carp_demotion from the configured priority and clamps the result
to [0, 254]. Priority 0 is VRRPv3's "resign" signal and causes backups to
preempt immediately. Priority 255 (IP address owner) is never demoted.
Reviewed by: kp
Approved by: kp
Sponsored by: Netflix
Differential Revision: https://reviews.freebsd.org/D55558
(cherry picked from commit 9f71153aec0cb455cd49af6d4ca7e4c16fd45d7a)
carp: fix global demotion counter to VRRP advertisements
When net.inet.carp.preempt=1 and a physical interface goes down, the global
V_carp_demotion counter is incremented. For CARP this was already reflected in
outgoing advertisements via DEMOTE_ADVSKEW(), but VRRP sent the raw
sc_vrrp_prio unchanged, so demotion had no effect.
Add DEMOTE_VRRP_PRIO(), a macro analogous to DEMOTE_ADVSKEW():
It subtracts V_carp_demotion from the configured priority and clamps the result
to [0, 254]. Priority 0 is VRRPv3's "resign" signal and causes backups to
preempt immediately. Priority 255 (IP address owner) is never demoted.
Reviewed by: kp
Approved by: kp
Sponsored by: Netflix
Differential Revision: https://reviews.freebsd.org/D55558
(cherry picked from commit 9f71153aec0cb455cd49af6d4ca7e4c16fd45d7a)
pfil: Avoid potential mbuf tag leak
In '398254f9999e mbuf: simplify m_free' we removed tag processing
on m_free() of M_NOFREE mbufs. It is possible that a packet filter
could attach a tag to this stack mbuf and call m_free()
on it, meaning that 398254f9999e may have introduced a tag leak.
However,if a tag is attached without anyone calling m_free(), then
this leak was pre-existing.
Reviewed by: glebius
Differential Revision: https://reviews.freebsd.org/D60686
Fixes: 398254f9999e
Sponsored by: Netflix
(cherry picked from commit f4ff995e361fa72cea240c4dbac2d0931965c80f)
pfil: Avoid potential mbuf tag leak
In '398254f9999e mbuf: simplify m_free' we removed tag processing
on m_free() of M_NOFREE mbufs. It is possible that a packet filter
could attach a tag to this stack mbuf and call m_free()
on it, meaning that 398254f9999e may have introduced a tag leak.
However,if a tag is attached without anyone calling m_free(), then
this leak was pre-existing.
Reviewed by: glebius
Differential Revision: https://reviews.freebsd.org/D60686
Fixes: 398254f9999e
Sponsored by: Netflix
(cherry picked from commit f4ff995e361fa72cea240c4dbac2d0931965c80f)
mbuf: simplify m_free
The check for (M_PKTHDR|M_NOFREE) was added by np@ in
"91d1b03d3617 Merge r254736 from user/np/cxl_tuning."
in order to support a clever rx mode optimization used
by cxgbe at the time. That optimization was removed in
46e1e307edb6 several years ago. This check is otherwise
unneeded and adds an extraneous test to every mbuf free,
so let's remove it.
Reviewed by: glebius, np
Differential Revision: https://reviews.freebsd.org/D60686
Sponsored by: Netflix
(cherry picked from commit 398254f9999eb1af5f0842570111d584aaf8d01a)
mbuf: simplify m_free
The check for (M_PKTHDR|M_NOFREE) was added by np@ in
"91d1b03d3617 Merge r254736 from user/np/cxl_tuning."
in order to support a clever rx mode optimization used
by cxgbe at the time. That optimization was removed in
46e1e307edb6 several years ago. This check is otherwise
unneeded and adds an extraneous test to every mbuf free,
so let's remove it.
Reviewed by: glebius, np
Differential Revision: https://reviews.freebsd.org/D60686
Sponsored by: Netflix
(cherry picked from commit 398254f9999eb1af5f0842570111d584aaf8d01a)
[libc] Clean up redundant libc_errno includes and dependencies. (#237273)
- Replace `src/__support/libc_errno.h` with `hdr/errno_macros.h` in
pthread, spawn, stdio, threads, time, and test files that only use errno
constants.
- Remove unused `libc_errno.h` includes and
`libc.src.__support.libc_errno` dependencies from err, stdio,
syscall_wrappers, and tests.
- Remove redundant `libc.src.errno.errno` / `:errno` dependencies from
math, unistd, mman, test, and fuzzer targets in CMake and Bazel.
Assisted-by: Gemini
