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
- Make session handling always use the CIOGSESSION2 structure.
CIOGSESSION requests use a thunk similar to COMPAT_FREEBSD32 session
requests. This permits the ioctl handler to use the 'crid' field
unconditionally.
- Move COMPAT_FREEBSD32 handling out of the main ioctl handler body
and instead do conversions in/out of thunk structures in dedicated
blocks at the start and end of the ioctl function.
Reviewed by: markj (earlier version)
Sponsored by: Netflix
Differential Revision: https://reviews.freebsd.org/D26178
These flags are not currently used, but will be used by future commits to
implement export(5) requirements for the use of NFS over TLS by clients.
Reviewed by: kib
Differential Revision: https://reviews.freebsd.org/D26180
It's rare for there to be two updating entries on the same day (once a
decade or so), but we have that here. Add the date to the second one
since devd and zfs are unrelated.
By default, lockf(1) opens its lock file O_RDONLY|O_EXLOCK. On NFS, if the
file already exists, this is split into opening the file read-only and then
requesting an exclusive lock -- and the second step fails because NFS does
not permit exclusive locking on files which are opened read-only.
The new -w option changes the open flags to O_WRONLY|O_EXLOCK, allowing it
to work on NFS -- at the cost of not working if the file cannot be opened
for writing.
(Whether the traditional BSD behaviour of allowing exclusive locks to be
obtained on a file which cannot be opened for writing is a good idea is
perhaps questionable since it may allow less-privileged users to perform
a local denial of service; however this behaviour has been present for a
long time and changing it now seems like it would cause problems.)
Reviewed by: rmacklem
Differential Revision: https://reviews.freebsd.org/D26005
zstd is kernel code that was not supposed to be in libzfs.
libzpool provides userland shims for kernel code and is where the
zstd code needs to be included.
Reported by: John Kennedy
Discussed with: mmacy
Sponsored by: iXsystems, Inc.
