As nexthops are immutable, some operations such as route attribute changes
require nexthop fetching, forking, modification and route switching.
These operations are not atomic, so they may need to be retried multiple
times in presence of multiple speakers changing the same route.
This change introduces "synchronisation" primitive: route_update_conditional(),
simplifying logic for route changes and upcoming multipath operations.
Differential Revision: https://reviews.freebsd.org/D26216
This changeset introduces the new libnetmap library for writing
netmap applications.
Before libnetmap, applications could either use the kernel API
directly (e.g. NIOCREGIF/NIOCCTRL) or the simple header-only-library
netmap_user.h (e.g. nm_open(), nm_close(), nm_mmap() etc.)
The new library offers more functionalities than netmap_user.h:
- Support for complex netmap options, such as external memory
allocators or per-buffer offsets. This opens the way to future
extensions.
- More flexibility in the netmap port bind options, such as
non-numeric names for pipes, or the ability to specify the netmap
allocator that must be used for a given port.
- Automatic tracking of the netmap memory regions in use across the
open ports.
At the moment there is no man page, but the libnetmap.h header file
has in-depth documentation.
Reviewed by: hrs
MFC after: 2 weeks
Differential Revision: https://reviews.freebsd.org/D26171
Coverity flagged the scaling by sizeof(uzd). That is the type
of the pointer, so the scaling was already done by pointer arithmetic.
However, this was also passing a stack frame pointer to kvm_read,
so it was doubly wrong.
Move ZDOM_GET into the !_KERNEL section and use it in libmemstat.
Reported by: Coverity
Reviewed by: markj
MFC after: 2 weeks
Sponsored by: Dell EMC Isilon
Differential Revision: https://reviews.freebsd.org/D26213
For some unknown reason this seems to fix this function when we printf
the best variable. This isn't a delay problem as doing a printf without
it doesn't solve this problem.
This is way above my pay grade so add some printf that shouldn't be printed
in 99% of the case anyway.
Fix booting on most Allwinner boards as the mmc IP uses a NM clock.
Reported by: Alexander Mishin <mishin@mh.net.ru>
MFC after: 3 days
X-MFC-With: 363887
The boot loader will be growing some (limited) support for some kernel
interfaces for some of the timekeeping routines to support zstd code.
Allow the declarations for them to be visible when compiling for the
boot loader, rather than treating it like a user-space environment
(which stand.h already provides to a limited degree).
Expose the pseudo-errno values in _STANDALONE is defined so that code
in the boot loader can make use of them. Nothing uses them today, but
the zstd support that's coming will need them.
Some external code requires a specific set of include paths to work
properly since it emulates the typical environment the code is used
in. Enable this by creating a CFLAGS_EARLY.file variable that can be
used to build this stack. Otherwise the include stack we build for
stand programs may get in the way. Code that uses this feature has to
tolerate the normal stack of inclues being last on the list (and
presumably unused), though.
Generally, it it should only be used for the specific include
directories. Defines and that sort of thing should be done in the
normal CFLAGS variable. There is a global CFLAGS_EARY hook as well for
everything in a Makefile.
splclock is used in one driver (spkr) to control access to
timer_spkr_* routines. However, nothing else does. So it shows no
useful locking info to someone that would want to lock spkr.
NOTE: I think there's races with timer_spkr_{acquire,release} since
there's no interlock in those routines, despite there being a spin
lock to protect the clock. Current other users appear to use no extra
locking protocol, though they themselves appear to be at least
attempting to make sure that only a single thread calls these
routines. I suspect the right answer is to update these routines to
take/release the clock spin lock since they are short and to the
point, but that's beyond the scope of this commit.
If job control is not enabled, a background job (... &) ignores SIGINT and
SIGQUIT, but this can be reverted using the trap builtin in the same shell
environment.
Using the set builtin to change options would also revert SIGINT and SIGQUIT
to their previous dispositions.
This broke due to r317298. Calling setsignal() reverts the effect of
ignoresig().
Reported by: bdrewery
MFC after: 1 week
splbio and splcan have been completely removed from the tree. We can
now remove their definitions here. They've been nops for a long time
and were only preserved to give hints on how to lock drivers. All
drivers have been deleted or converted, so they can be deleted now.
An Internet Draft titled "Towards Remote Procedure Call Encryption By Default"
(soon to be an RFC I think) describes how Sun RPC is to use TLS with NFS
as a specific application case.
Various commits prepared the NFS code to use KERN_TLS, mainly enabling use
of ext_pgs mbufs for large RPC messages.
r364475 added TLS support to the kernel RPC.
This commit (which is the final one for kernel changes required to do
NFS over TLS) adds support for three export flags:
MNT_EXTLS - Requires a TLS connection.
MNT_EXTLSCERT - Requires a TLS connection where the client presents a valid
X.509 certificate during TLS handshake.
MNT_EXTLSCERTUSER - Requires a TLS connection where the client presents a
valid X.509 certificate with "user@domain" in the otherName
field of the SubjectAltName during TLS handshake.
Without these export options, clients are permitted, but not required, to
use TLS.
For the client, a new nmount(2) option called "tls" makes the client do
a STARTTLS Null RPC and TLS handshake for all TCP connections used for the
mount. The CLSET_TLS client control option is used to indicate to the kernel RPC
that this should be done.
Unless the above export flags or "tls" option is used, semantics should
not change for the NFS client nor server.
For NFS over TLS to work, the userspace daemons rpctlscd(8) { for client }
or rpctlssd(8) daemon { for server } must be running.
This allows building 13.x from Git instead of Subversion.
No MFC to stable branches is planned at this time. [1]
Discussed with: git working group [1]
Sponsored by: Rubicon Communications, LLC (netgate.com)
Previously any residual data in the final block of a compressed kernel
dump would be written unencrypted. Note, such a configuration already
does not work properly when using AES-CBC since the compressed data is
typically not a multiple of the AES block length in size and EKCD does
not implement any padding scheme. However, EKCD more recently gained
support for using the ChaCha20 cipher, which being a stream cipher does
not have this problem.
Submitted by: sigsys@gmail.com
Reviewed by: cem
MFC after: 1 week
Differential Revision: https://reviews.freebsd.org/D26188
clash, or redefining name/jid). The current behvaior, of merely warning
and moving on, can lead to unexpected behavior when a jail is created
without the offending parameter defined at all.
ich_init() returns an errno value or 0, but ich_pci_resume() was
comparing the return value with -1 to determine whether an error had
occurred.
PR: 248941
Submitted by: Tong Zhang <ztong0001@gmail.com>
MFC after: 1 week
fdc_in() returns only 0 and 1, some callers were checking incorrectly
for failure.
PR: 248940
Submitted by: Tong Zhang <ztong0001@gmail.com>
MFC after: 1 week
asmc_key_read() returns only 0 and 1, some callers were checking
incorrectly for failure.
PR: 248939
Submitted by: Tong Zhang <ztong0001@gmail.com>
MFC after: 1 week
Turn FLUSHO on/off with ^O (or whatever VDISCARD is). Honor that to
throw away output quickly. This tries to remain true to 4.4BSD
behavior (since that was the origin of this feature), with any
corrections NetBSD has done. Since the implemenations are a little
different, though, some edge conditions may be handled differently.
Reviewed by: kib, kevans
Differential Review: https://reviews.freebsd.org/D26148
r363210 introduced v_seqc_users to the vnodes. This change requires
a vn_seqc_write_end() to match the vn_seqc_write_begin() in
vfs_cache_root_clear().
mjg@ provided this patch which seems to fix the panic.
Tested for an NFS mount where the VFS_STATFS() call will fail.
Submitted by: mjg
Reviewed by: mjg
Differential Revision: https://reviews.freebsd.org/D26160
