usbconfig: add -l option to dump_device_desc for single line output
Like pciconf -l add a -l to dump_device_desc for usbconfig which will
fold most fields into a single line. We do filter out some we think
will not be interesting in this case.
While mangling with string output in ways not always anticipated when
the program was initially written this should help to parse the
available devices for programs like fwget(8). While I had this in
mind for other bits for a while I got prompted by D48678 to finally
do it.
Sponsored by: The FreebSD Foundation
MFC after: 3 days
Reviewed by: bapt (LGTM), ziaee (man)
Differential Revision: https://reviews.freebsd.org/D48974
if_infininband: Support BPF write for broadcast frames
To support DHCP for IPoIB links, DHCP clients and servers require the
ability to transmit link-layer broadcasts on the IB interfaces. BPF
provides the mechanism for doing this.
This change updates the if_infiniband driver to be capable of accepting
link-layer broadcast requests via BPF using Ethernet formatted frames
(the driver currently registers with BPF as DLT_EN10MB). Only Broadcast
frames can reliably be interpreted using the Ethernet header format so
detect unicast and multicast frames are rejected if passed in using the
Ethernet format. This doesn't impact the ability to support native
unicast, broadcast or multicast frames if native infiniband header
support is added to BPF at a later date.
Further the above, this commit also addresses an issue in the existing
code that can result in separation of part of the packet header from the
rest of the payload if a BPF write was attempted. This was caused by
mbuf preallocation of the infiniband header length regardless of length
[7 lines not shown]
LinuxKPI: skbuff: add synchronization primitives and missing bits
Make a pass over skbuff.h:
- implement some missing bits,
- sprinkle some const,
- add locking and read/write_once calls as needed to provide
synchronization as expected by Linux,
- fix some typos,
- remove return from void functions,
- adjust tracing macros.
Sponsored by: The FreeBSD Foundation
MFC after: 3 days
PR: 283903 (rtw88 skb leak)
Tested by: Guillaume Outters (guillaume-freebsd outters.eu)
Differential Revision: https://reviews.freebsd.org/D49101
inpcb: Fix reuseport lbgroup array resizing
in_pcblisten() moves an inpcb from the per-group list into the array, at
which point it becomes visible to inpcb lookups in the datapath. It
assumes that there is space in the array for this, but that's not
guaranteed, since in_pcbinslbgrouphash() doesn't reserve space in the
array if the inpcb isn't associated with a listening socket.
We could resize the array in in_pcblisten(), but that would introduce a
failure case where there currently is none. Instead, keep track of the
number of pending inpcbs as well, and modify in_pcbinslbgrouphash() to
reserve space for each pending (i.e., not-yet-listening) inpcb.
Add a regression test.
Reviewed by: glebius
Reported by: netchild
Fixes: 7cbb6b6e28db ("inpcb: Close some SO_REUSEPORT_LB races, part 2")
Differential Revision: https://reviews.freebsd.org/D49100
kyua: Pass unprivileged user config prop to ATF using all known names
Kyua and ATF speak different naming styles. In this case, the
unprivileged user property can be named with underscore on the Kyua
side, and with a hyphen on the ATF side. Sometimes it is not obvious
which style should be used in which situation. For instance, a test case
may require this configuration property being set using require.config.
Also, a test case may want to read the property using something like
atf_tc_get_config_var(). Which names should be used in these cases?
From the perspective of the original code, it is expected to be this:
require.config unprivileged-user
atf_tc_get_config_var(tc, "unprivileged-user")
But, as long as Kyua is the main interface, its users expect to work
with kyua.conf(5), which says that it must be named as unprivileged_user
(with underscore). As a result, test authors tend to do this instead:
require.config unprivileged_user
atf_tc_get_config_var(tc, "unprivileged_user")
[8 lines not shown]
LinuxKPI: 802.11: fix locking in lkpi_ic_ampdu_rx_stop()
net80211 has inconsistent locking when calling into (*ic_ampdu_rx_stop)().
Make use of 054c5ddf587a7 and conditionally check if the caller
locked or not and if locked temporary drop the lock to avoid sleeping
on a non-sleepaable lock during the downcall into the driver.
Sponsored by: The FreeBSD Foundation
MFC after: 3 days
LinuxKPI: 802.11: add condition to TODO in ieee80211_sta_recalc_aggregates
ieee80211_sta_recalc_aggregates() shows up in TODO traces but there is
nothing we have to do there until we have active links (MLO support).
Make the TODO conditional for a time when we will get there.
Sponsored by: The FreeBSD Foundation
MFC after: 3 days
LinuxKPI: rather than manually defining a value use the net80211 define
Define cfg80211 IEEE80211_VHT_CAP_SUPP_CHAN_WIDTH_MASK to
net80211 IEEE80211_VHTCAP_SUPP_CHAN_WIDTH_MASK.
We should likely at some point make a sweep and replace all the
values with the defines from the comments for the matching net80211
version.
Sponsored by: The FreeBSD Foundation
MFC after: 3 days
LinuxKPI: 802.11: add further checks for deflink.supp_rates[]
When setting the per-band supp_rates bitfield check for mandatory
rates only. We cannot easily say at that point for 2Ghz whether
11g is supported so assume these days it is not pure-b.
Sponsored by: The FreeBSD Foundation
MFC after: 3 days
LinuxKPI: 802.11: use net80211 macro instead of manual check
Use IEEE80211_CONF_VHT() instead of manually checking if hardware
supports VHT.
Sponsored by: The FreeBSD Foundation
MFC after: 3 days
LinuxKPI: 802.11: improve cfg80211_chandef_create()
Implement cfg80211_chandef_create() to work with HT. Update enum
with HT channel types. When calling the function from LinuxKPI 802.11
code, pass in NL80211_CHAN_HT20 if HT is supported rather than NO_HT.
Sponsored by: The FreeBSD Foundation
MFC after: 3 days
tests: carp: Update test case unicast_v4 to catch PR 284872
In the current test case unicast_v4, host one acts as a router, but it
uses if_bridge(4) to verify the reachability to CARP master.
Unfortunately, if_bridge(4) brings the two CARP hosts into the same
broadcast domain, thus with an unusual (undocumented) setup, one host
is in unicast mode but another one in multicast, or two hosts are both
in multicast mode, the test case can falsely report success.
Fix that by propagating route via routed(8).
PR 284872 shows that CARP(4) happens to send packets with multicast
destination when the unicast peer address is in the range x.x.x.224 ~
x.x.x.239. Update the peer address in test case to catch that bug.
PR: 284872
Reviewed by: kp
MFC after: 3 days
Differential Revision: https://reviews.freebsd.org/D49076
