Without this patch, an all upper case user domain name
(as specified by nfsuserd(8)) would not work.
I believe this was done so that Kerberos realms were
not confused with user domains.
Now, RFC8881 specifies that the user domain name is a
DNS name. As such, all upper case names should work.
This patch fixes this case so that it works. The custom
comparison function is no longer needed.
PR: 282620
Tested by: jmmv
MFC after: 2 weeks
Notable upstream pull request merges:
#16643 -multiple Change rangelock handling in FreeBSD's zfs_getpages()
#1669746c4f2ce0 dsl_dataset: put IO-inducing frees on the pool deadlist
#16740 -multiple BRT: Rework structures and locks to be per-vdev
#16743a60ed3822 L2ARC: Move different stats updates earlier
#167588dc452d90 Fix some nits in zfs_getpages()
#16759534688948 Remove hash_elements_max accounting from DBUF and ARC
#167669a81484e3 ZAP: Reduce leaf array and free chunks fragmentation
#16773457f8b76e BRT: More optimizations after per-vdev splitting
#167820ca82c568 L2ARC: Stop rebuild before setting spa_final_txg
#16785d76d79fd2 zio: Avoid sleeping in the I/O path
#16791ae1d11882 BRT: Clear bv_entcount_dirty on destroy
#16796b3b0ce64d FreeBSD: Lock vnode in zfs_ioctl()
#16797d0a91b9f8 FreeBSD: Reduce copy_file_range() source lock to shared
Obtained from: OpenZFS
OpenZFS commit: d0a91b9f88
These tests try to verify that packet prioritisation works as expected. This is
inherently a statistical process, and is difficuly to measure automatically.
Run the tests more times and accept more failures.
Sponsored by: Rubicon Communications, LLC ("Netgate")
This is a retread of https://reviews.freebsd.org/D34449 which I think
will fix the issue for the remote side not supporting autoneg. We now
attempt an autoneg, and if that fails fall back to the current code
that forces the link speed/duplex.
The original intent of this patch is to inform the remote switch of
duplex settings when we (the client) are specifying a fixed 10 or 100
speed. Otherwise it may get the duplex setting wrong.
The tricky case is when the remote (switch) side is fixing its
speed AND duplex while disabling autoneg and we (client) need to do
the same, which still seems to be common enough at some ISPs.
Original commit message follows:
Currently if an e1000 interface is set to a fixed media configuration,
for gigabit, it will participate in auto-negotiation as required by
IEEE 802.3-2018 Clause 37. However, if set to fixed media configuration
for 100 or 10, it does NOT participate in auto-negotiation.
By my reading of Clauses 28 and 37, while auto-negotiation is optional
for 100 and 10, it is not prohibited and is, in fact, "highly
recommended".
This patch enables auto-negotiation for fixed 100 and 10 media
configuration, in a similar manner to that already performed for 1000.
I.e., the patch enables advertising of just the manually configured
settings with the goal of allowing the remote end to match the manually
configured settings if it has them available.
To be clear, this patch does NOT allow an em(4) interface that has been
manually configured with specific media settings to respond to
auto-negotiation by then configuring different parameters to those that
were manually configured. The intent of this patch is to fully comply
with the requirements of Clause 37, but for 100 and 10.
The need for this has arisen on an em(4) link where the other end is
under a different administrative control and is set to full
auto-negotiation. Due to the cable length GigE is not working well. It
is desired to set the em(4) end to "media 100baseTX mediatype
full-duplex" which does work when both ends are configured that way.
Currently, because em(4) does not participate in autoneg for this
setting, the remote defaults to half-duplex - i.e., there's a duplex
mismatch and things don't work. With this patch, em(4) would inform the
remote that it has only 100baseTX full, the remote would match that and
it will work.
Tested by: Natalino Picone <natalino.picone@nozominetworks.com>
Tested by: Franco Fichtner <franco@opnsense.org>
Tested by: J.R. Oldroyd <fbsd@opal.com> (previous version)
Sponsored by: Nozomi Networks
Sponsored by: BBOX.io
Differential Revision: https://reviews.freebsd.org/D47336
Linux locks copy_file_range() source as shared. FreeBSD was doing
it also, but then was changed to exclusive, partially because KPI
of that time was doing so, and partially seems out of caution.
Considering zfs_clone_range() uses range locks on both source and
destination, neither should require exclusive vnode locks. But one
step at a time, just sync it with Linux for now.
Reviewed-by: Alan Somers <asomers@gmail.com>
Reviewed-by: Brian Behlendorf <behlendorf1@llnl.gov>
Signed-off-by: Alexander Motin <mav@FreeBSD.org>
Sponsored by: iXsystems, Inc.
Closes#16789Closes#16797
Previously vnode was not locked there, unlike Linux. It required
locking it in vn_flush_cached_data(), which recursed on the lock
if called from zfs_clone_range(), having the vnode locked.
Reviewed-by: Alan Somers <asomers@gmail.com>
Reviewed-by: Brian Behlendorf <behlendorf1@llnl.gov>
Signed-off-by: Alexander Motin <mav@FreeBSD.org>
Sponsored by: iXsystems, Inc.
Closes#16789Closes#16796
After commit 3bfbb521fe, -g stopped being a no-op. The -g hasn't
been required for equivalent output since 4.4BSD.
PR: 282901
Fixes: 3bfbb521 ls: Improve POSIX compatibility for -g and -n.
A device can be disabled via a hint after it is probed (but before it
is attached). The initial version of this marked the device disabled,
but left the device "alive" meaning that dev->driver and dev->desc
were untouched and still pointed into the driver that probed the
device. If that driver lives in a kernel module that is later
unloaded, device_detach() called from devclass_delete_driver() doesn't
do anything (the device's state is DS_ALIVE). In particular, it
doesn't call device_set_driver(dev, NULL) to disassociate the device
from the driver that is being unloaded.
There are several places where these stale pointers can be tripped
over. After kldunload, invoking the sysctl to fetch device info can
dereference dev->desc and dev->driver causing panics. Even without
kldunload, a system suspend request will call the device_suspend and
device_resume DEVMETHODs of the driver in question even though the
device is not attached which can cause some excitement.
To clean this up, more fully detach a device that is disabled by a
hint by clearing the driver and setting the state to DS_NOTPRESENT.
However, to keep the device name+unit combination reserved, leave the
device attached to its devclass.
This requires a change to 'devctl enable' handling to deal with this
updated state. It now checks for a non-NULL devclass to determine if
a disabled device is in this state and if so it clears the hint.
However, it also now clears the devclass before attaching the device.
This gives all drivers an opportunity to attach to the now-enabled
device.
Reported by: adrian
Discussed with: imp
Reviewed by: imp
MFC after: 1 week
Differential Revision: https://reviews.freebsd.org/D47691
On a laptop with no other console devices than the screen, things
scroll of the screen faster than eye or camera can capture it.
This tunable slows the console down and makes it update synchronously,
so console output continues when timers or interrupts do not.
Differential Revision: https://reviews.freebsd.org/D47710
Remove the array of port module status and instead save module status
and module number.
At boot, for each PCI function driver get event from fw about module
status. The event contains module number and module status. Driver
stores module number and module status.. When user (ifconfig) ask for
modules information, for each pci function driver first queries fw to
get module number of current pci function, then driver compares the
module number to the module number it stored before and if it matches
and module status is "plugged and enabled" then driver queries fw for
the eprom information of that module number and return it to the
caller.
In fact fw could have concluded that required module number of the
current pci function, but fw is not implemented this way. current
design of PRM/FW is that MCIA register handling is only aware of
modules, not the pci function->module connections. FW is designed to
take the module number written to MCIA and write/read the content
to/from the associated module's EPROM.
So, based on current FW design, we must supply the module num so fw
can find the corresponding I2C interface of the module to write/read.
Sponsored by: NVidia networking
MFC after: 1 week
Ensure all allocated tags have a hardware context associated.
The hardware context allocation is moved into the zone import
routine, as suggested by kib. This is safe because these zone
allocations are always done in a sleepable context.
I have removed the now pointless num_resources tracking,
and added sysctls / tunables to control UMA zone limits
for these tls tags, as well as a tunable to let the
driver pre-allocate tags at boot.
MFC after: 2 weeks
- Don't allow FBT and kinst to instrument the KMSAN runtime.
- When fetching data from the traced thread's stack, mark it as
initialized. It may well be uninitialized, but as dtrace permits
arbitrary inspection of kernel memory, it isn't very useful to raise
KMSAN reports.
- Mark data copied in from userspace as initialized, as we do for
copyin() etc. using interceptors.
MFC after: 2 weeks
Reverse the first if() in pf_dummynet_route() to avoid an unneeded level of
indendation.
No functional change.
Sponsored by: Rubicon Communications, LLC ("Netgate")
It is needed for SSP support.
Reported by: netchild, Shawn Webb
Fixes: 62dab3d016 ("getentropy: Remove fallback code")
Sponsored by: The FreeBSD Foundation
We were previously allocating MAXCPU structures for several purposes,
but this is generally unnecessary and is quite excessive, especially
after MAXCPU was bumped to 1024 on amd64 and arm64. We already are
careful to allocate only as many per-CPU tracing buffers as are needed;
extend this to other allocations.
For example, in a 2-vCPU VM, the size of a consumer state structure
drops from 64KB to 128B. The size of the per-consumer `dts_buffer` and
`dts_aggbuffer` arrays shrink similarly. Ditto for pre-allocations of
local and global D variable storage space.
MFC after: 2 weeks
Differential Revision: https://reviews.freebsd.org/D47667
This function is registered as a ifnet_link_event and so should have the
corresponding argument list.
PR: 282870
Reported by: nakayamakenjiro@gmail.com
MFC after: 1 week
The ioctl DIOCRCLRASTATS provides the functionality of clearing stats
not only for the whole table for for addresses stored in that table. The
functionality was missing from pfctl, though. Add it now.
PR: 282877
Obtained from: OpenBSD, kirill <kirill@openbsd.org>, e496dff3a7
MFC after: 3 weeks
by protecting against sb->s_shrink eviction on umount with newer kernels
deactivate_locked_super calls shrinker_free and only then
sops->kill_sb cb, resulting in UAF on umount when trying
to reach for the shrinker functions in zpl_prune_sb of
in-umount dataset
Reviewed-by: Brian Behlendorf <behlendorf1@llnl.gov>
Reviewed-by: Adam Moss <c@yotes.com>
Signed-off-by: Pavel Snajdr <snajpa@snajpa.net>
Closes#16770
Change cdev_mgtdev_page_free_page to take an iterator, rather than an
object and page, so that removing the page from the object radix tree
can take advantage of locality with iterators. Define a
general-purpose function to free all pages, which can be used in
several places.
Reviewed by: kib
Differential Revision: https://reviews.freebsd.org/D47692
This is an interim robustness improvement; further improvements as
described in the PR and/or Phabricator review are still needed.
PR: 267334
Reported by: Robert Morris <rtm@lcs.mit.edu>
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D37229
All the other libutil section 3 manpages document this, and although
it's heavily implied by the libutil.h header in the synopsis, we should
still be explicit and consistent.
PR: 280078
Reviewed by: jrtc27
MFC after: 1 week
In general, in the direct dispatch case netgraph only enters the net
epoch to send data messages, but this was inconsistent with the netgraph
thread, which also entered the net epoch to send fn and fn2 messages to
nodes. Some handlers, e.g., ng_bridge_newhook(), may sleep, and so
cannot be called in epoch context; the netgraph tests occasionally panic
due to this problem.
Make ngthread() consistent with the direct dispatch path.
Discussed with: afedorov (in D44615)
MFC after: 2 weeks
Sponsored by: Klara, Inc.
The loop doesn't check for overflow of the event buffer, which can
easily happen if other tests are running in parallel (the bectl tests in
particular trigger devd events).
When that overflow occurs, a funny thing can happen: the loop ends up
trying to read 0 bytes from the socket, succeeds, and then prints its
buffer to stdout. It does this as fast as possible, eventually timing
out. Then, because kyua wants to log the test's output, it slurps the
output file into memory so that it can insert it into the test db. This
output file is quite large, usually around 8GB when I see it happen, and
is large enough to trigger an OOM kill in my test suite runner VM.
Fix the test: use a larger buffer and fail the test if we fill it before
both events are observed. Also don't print the output buffer on every
loop iteration, since unlike the seqpacket test that will just print the
same output over and over.
Reviewed by: imp, asomers
MFC after: 2 weeks
Sponsored by: Klara, Inc.
Differential Revision: https://reviews.freebsd.org/D47625
These tests assume exclusive use of one or more FIBs and so can't be run
in parallel. Running them in a VNET jail sidesteps this problem.
MFC after: 1 week
Sponsored by: Klara, Inc.
Sponsored by: Stormshield
embedfs.S needs the right aarch64 features for BTI and/or PAC.
Obtained from: CheriBSD
Fixes: c2e0d56f5e ("arm64: Support BTI checking in most of the kernel")
Sponsored by: AFRL, DARPA
This fixes assertion in brt_sync_table() on debug builds when last
cloned block on the vdev is freed and bv_meta_dirty is cleared,
while bv_entcount_dirty is not. Should not matter in production.
Reviewed-by: Brian Behlendorf <behlendorf1@llnl.gov>
Signed-off-by: Alexander Motin <mav@FreeBSD.org>
Sponsored by: iXsystems, Inc.
Closes#16791
Update the META file to reflect compatibility with the 6.12 kernel.
Reviewed-by: Umer Saleem <usaleem@ixsystems.com>
Signed-off-by: Brian Behlendorf <behlendorf1@llnl.gov>
Closes#16793
