If one of two pointers refers to a forward declaration, let the pointers
be compatible so long as the referred types have the same name.
Otherwise we can get spurious errors.
To give a specific example, this can happen when ipfw_nat.ko is loaded
before ipfw.ko and /usr/lib/dtrace/ipfw.d is processed. Currently,
ipfw_nat.ko does not have a definition for struct inpcb (i.e., none of
its files include in_pcb.h), so in the CTF type graph, struct
ip_fw_args' "inp" member refers to a forward declaration, represented in
CTF with CTF_K_FORWARD.
Then, when libdtrace processes the ipfw_match_info_t translator in
ipfw.d, it decides that the "inp" field assignment is incorrect because
the two pointers are incompatible. However, there's no harm in allowing
this assignment. Add some logic to dt_node_is_ptrcompat() to detect
this case and declare the pointers as compatible so long as the name of
the thing they refer to is the same, similar to how any pointer is
compatible with a void *.
Reported by: marck
Reviewed by: Domagoj Stolfa <domagoj.stolfa@gmail.com>
MFC after: 2 weeks
Differential Revision: https://reviews.freebsd.org/D48254
The firmware version isn't enough; different firmware is loaded
for different revisions of a given chip. So print out the file too;
it'll make handling reports much easier.
Differential Revision: https://reviews.freebsd.org/D48067
Reviewed by: emaste
Indicate that the missing of the break is intentionally.
Reviewed by: rrs
CID: 1523782
MFC after: 1 week
Sponsored by: Netflix, Inc.
Differential Revision: https://reviews.freebsd.org/D48273
This change brings the descriptor for target "elf64-riscv-freebsd"
in line with its documentation.
I missed this somehow when reviewing https://reviews.freebsd.org/D20768.
Reported by: Haowu Ge (on elftoolchain-developers)
Reviewed by: emaste, imp
Differential Revision: https://reviews.freebsd.org/D48271
* remove the hard-coded ridx values in rate2ridx(), use the RIDX
defines for CCK/OFDM rates
* Add a placeholder rtwn_ctl_vhtrate() which returns the dot11rate
control rate to use for the given VHT rate index. Since net80211
currently doesn't have any VHT PHY tables, there's no mapping for
us to leverage so just return OFDM 12M for now.
* Use the new macro to convert rate index to MCS rate
* Add a printf() in rate2ridx if it's passed a HT/VHT rate.
Differential Revision: https://reviews.freebsd.org/D48098
Reviewed by: bz
This register (array) controls the initial rate to use for each
MACID. There's no need to set it if firmware rate control is enabled -
it'll actually be under firmware control (and we can read it back to
see what choices the firmware is making.)
Locally tested:
* RTL8188EU, STA
* RTL8192CU, STA
* RTL8192EU, STA
Differential Revision: https://reviews.freebsd.org/D48094
Reviewed by: bz
The RTL8188E firmware doesn't have the "full" offload firmware
rate control. Instead, the vendor driver has a bunch of logic
in the driver for rate probing and selection.
Part of this is the periodic TX report - which uploads a summary
of multi-rate retries and drops per MAC. Using it drastically
cuts down on the TX notifications - it's fired from a timer
(defaulting to ~ 1.6 seconds) and is a single receive frame in
the normal bulk RX path.
I've not ported / reimplemented the whole vendor driver rate adaption
code - instead, I'm just using the normal net80211 rate control APIs.
It seems to behave OK - I get 25-30mbit down and 20mbit up using TCP/
speedtest.
Locally tested:
* RTL8188EU, STA mode
Differential Revision: https://reviews.freebsd.org/D48088
Reviewed by: fuz, bz
Obtained from: https://github.com/lwfinger/rtl8188eu/blob/master/hal/Hal8188ERateAdaptive.c
Add support to read/write the MAC/PHY registers.
Hide it behind RTWN_DEBUG.
This doesn't cover the RF registers as they require a different
IO path, but I haven't yet debugged the RF paths.
Locally tested:
* RTL8192CU, STA
* RTL8188EU, STA
* RTL8812AU / RTL8821AU, STA
Differential Revision: https://reviews.freebsd.org/D48084
Reviewed by: bz
When storing the old beta values in rack_swap_beta_values(),
ensure that the newreno_flags field is initialized appropriately
instead of using an uninitialized value.
Since the stored newreno_flags aren't actually used, this fix
should not have any functional change.
Reviewed by: rrs
CID: 1523796
MFC after: 1 week
Sponsored by: Netflix, Inc.
Differential Revision: https://reviews.freebsd.org/D48260
Instead of dealing with ifp == NULL, which should never happen,
assume that this is not true. Use KASSERT to make this clear.
No functional change intended.
Reviewed by: glebius, rrs
CID: 1523767
MFC after: 1 week
Sponsored by: Netflix, Inc.
Differential Revision: https://reviews.freebsd.org/D48258
The stack has never limited use of addresses in these ranges as an
endpoint. The relatively recent sysctls control only forwarding of,
and ICMP response to, these addresses.
Reviewed by: bz
Fixes: efe58855f3 ("IPv4: experimental changes to allow net 0/8, 240/4, part of 127/8")
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D48262
This commit implements the missing capability set handlers for
setting the transmit and receive chainmasks. I did this for the
AR5416 and later chips years ago, but not for these.
This is especially useful when you're only hooking up one or two
antennas on a 3 antenna device - or you just want to test it like
that.
It also requires updating the number of supported transmit/receive
streams, so also add them here.
Locally Tested:
* AR9300, STA mode, 1, 2 and 3 stream TX/RX configuration
Differential Revision: https://reviews.freebsd.org/D48240
I've reviewed all of the linux vendor and upstream drivers.
This SEQ_SEL field isn't a mask and doesn't ever look like it
it was; instead this bit is set to tag QoS data frames.
In fact, it effectively was set to 0 for STA frames and potentially 1
for broadcast/multicast frames as the STA macid of 0 and broadcast/
multicast macid of 1 maps to that. In AP modes it would be tagged
based on bit 0.
So, bring it in line with the vendor and linux drivers.
Locally tested:
* RTL8192CU, STA, hostap
* RTL8188EU, STA
* RTL8192EU, STA
Differential Revision: https://reviews.freebsd.org/D48092
There's no need to account for pd->af == pd->naf in this section of
pf_state_key_setup() because we only get here if pd->af != pd->naf (i.e. nat64).
Pointed out by: markj
Sponsored by: Rubicon Communications, LLC ("Netgate")
Previously we could create cd9660 images with duplicate short (level 2)
names.
cd9660_level2_convert_filename used a 30-character limit (for files and
directories), not including the '.' separator. cd9660_rename_filename
used a 31-character limit, including the '.'. Directory names 31
characters or longer (without '.') were shortened to 30 characters, and
if a collision occurred cd9660_rename_filename uniquified them starting
with the 31st character. Unfortunately the directory record's name_len
was already set, so the unique part of the name was stripped off.
Directories are up to 31 d-characters (i.e., A-Z 0-9 and _); there is no
provision for a '.' in a directory name. Increase the name length limit
to 31 for directories, and exclude '.'s.
This name mapping and deduplication code is still fragile and convoluted
and would beenfit from a more holistic effort.
PR: 283238, 283112
Reviewed by: imp
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D48251
- Use consistent language to describe user values unchanged by the
kernel.
- Replace passive language with active in a few places.
- Add a history note for kqueuex() and kqueue1().
- Add an MLINK and synopsis for kqueue1().
- Various wording and markup tweaks.
Reviewed by: emaste
Differential Revision: https://reviews.freebsd.org/D48203
For requests that handoff queues from userspace to the kernel as well
as the request to fetch reconnect parameters from the kernel, switch
from using flat structures to nvlists. In particular, this will
permit adding support for additional transports in the future without
breaking the ABI of the structures.
Note that this is an ABI break for the ioctls used by nvmf(4) and
nvmft(4). Since this is only present in main I did not bother
implementing compatability shims.
Inspired by: imp (suggestion on a different review)
Reviewed by: imp
Sponsored by: Chelsio Communications
Differential Revision: https://reviews.freebsd.org/D48230
This can be useful for headers that wish to use nvlist_t pointers in a
structure or function argument without pulling in all of the headers
from <sys/nv.h>.
Reviewed by: imp
Sponsored by: Chelsio Communications
Differential Revision: https://reviews.freebsd.org/D48229
Do not return an uninitialized value from ctf_do_queued_segments()
in case no packets are actually processed (all are skipped).
Reviewed by: rrs
CID: 1523774
MFC after: 1 week
Sponsored by: Netflix, Inc.
Differential Revision: https://reviews.freebsd.org/D48217
When displaying unionfs mounts in fstab format (`mount -p`), mount(8)
currently uses strlcpy to remove the disposition prefix from the mount
name returned by getmntinfo(3). But strlcpy, like strcpy before it,
does not guarantee correct behavior if the source and destination
buffers overlap.
Just offset the buffer and avoid the destructive copy in the first
place.
PR: 283420
Reviewed by: imp (previous version), olce
MFC after: 1 week
Differential Revision: https://reviews.freebsd.org/D48177
This test is inside the else block for `if (*oldname == '.')`, so
*oldname cannot be '.' here.
Reviewed by: kevans
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D48243
Most pci controllers will just have a single reg for the config space,
but others (e.g., on Apple Silicon) may have more following that to
describe, e.g., controller port space. Bump the "ranges" rid space up
to avoid overriding these other memory resources.
Reviewed by: jhb
Differential Revision: https://reviews.freebsd.org/D43921
The -gGh flags are used for sweep ping to specify minimal,
maximum and increment sizes for the ICMP payload, not the packet
size. Adjust the error messages and comments accordingly.
Reviewed by: glebius
Differential Revision: https://reviews.freebsd.org/D48232
The -g flag specifies a minimal payload size for the sweep ping
and its default is zero. Make it possible to do ping -g 0 ...,
i.e., start with no payload.
Reviewed by: glebius
Differential Revision: https://reviews.freebsd.org/D48231
Commit 07cd69e272 adds a new "-a" mountd option,
which changes the behavior of mountd when file systems
are exported via -alldirs.
This patch updates the man page to reflect the actual
behavior when -alldirs is used when mountd is started
with/without -a. Prior to the above commit, exports(5)
documented that, when -alldirs was specified, the exports
line would fail unless the directory was a server file
system mount point. This behavior was only documented
in the Examples section and has not been implemented
since a change between FreeBSD 1 and FreeBSD 2 was done.
This is a contents change.
PR: 282995
Reviewed by: markj
MFC after: 2 weeks
Differential Revision: https://reviews.freebsd.org/D48139
Commit 07cd69e272 adds a new "-a" mountd option.
This patch updates the man page for it.
This is a content change.
PR: 282995
Reviewed by: gbe (manpages)
MFC after: 2 weeks
Differential Revision: https://reviews.freebsd.org/D48138
Bugzilla PR#282995 reported that, when a file system was
exported with the "-alldirs" flag, the export succeeded even
if the directory path was not a server file system mount point.
This behaviour for "-alldirs" was only documented in the
Example section of exports(5) and had not been enforced
since FreeBSD2. (A patch applied between FreeBSD1 and
FreeBSD2 broke the check for file system mount point.)
Since the behaviour of allowing the export has existed since
FreeBSD2, the concensus on a mailing list was that it would
be a POLA violation to change it now.
Therefore, this patch adds a new "-a" mountd command line
option to enforce a check for the exported directory being a
server file system mount point.
PR: 282995
MFC after: 2 weeks
Differential Revision: https://reviews.freebsd.org/D48137
Some programs depend on these symbols, when they are compiled for armv6
or armv7. Closes#1560 (slightly changed due to sorting of the symbols).
PR: 271087
Reported by: fuz
Submitted by: jfc@mit.edu
MFC after: 1 week
Michael Tuexen