fspacectl(2) is a system call to provide space management support to
userspace applications. VOP_DEALLOCATE(9) is a VOP call to perform the
deallocation. vn_deallocate(9) is a public KPI for kmods' use.
The purpose of proposing a new system call, a KPI and a VOP call is to
allow bhyve or other hypervisor monitors to emulate the behavior of SCSI
UNMAP/NVMe DEALLOCATE on a plain file.
fspacectl(2) comprises of cmd and flags parameters to specify the
space management operation to be performed. Currently cmd has to be
SPACECTL_DEALLOC, and flags has to be 0.
fo_fspacectl is added to fileops.
VOP_DEALLOCATE(9) is added as a new VOP call. A trivial implementation
of VOP_DEALLOCATE(9) is provided.
Sponsored by: The FreeBSD Foundation
Reviewed by: kib
Differential Revision: https://reviews.freebsd.org/D28347
It is more idiomatic. CFLAGS is only augmented with $SSP_CFLAGS when
$MK_SSP != "no".
Reviewed by: imp
MFC after: 1 week
Differential Revision: https://reviews.freebsd.org/D31401
Current POSIX standard requires fork() to be async-signal safe. Neither
our implementation, nor implementations in other operating systems are,
and practically it is impossible to make fork() async-signal safe without
too much efforts. Also, that would put undue requirement that all atfork
handlers should be async-signal safe as well, which contradicts its main
use.
As result, Austin Group dropped the requirement, and added a new function
_Fork() that should be async-signal safe, but it does not call atfork
handlers. Basically, _Fork() can be implemented as a raw syscall.
Release of glibc 2.34 added _Fork(), do the same for FreeBSD.
Clarify threading behavior for fork() in the manpage.
Reviewed by: markj
Sponsored by: The FreeBSD Foundation
MFC after: 2 weeks
Differential revision: https://reviews.freebsd.org/D31378
This is needed in order to build various LLVM binutils (e.g. addr2line)
as well as clang/lld/lldb.
Co-authored-by: Jessica Clarke <jrtc27@FreeBSD.org>
Test Plan: Compiles on ubuntu 18.04 and macOS 11.4
Reviewed By: dim
Differential Revision: https://reviews.freebsd.org/D31057
They deliberately read out-of-bounds values to avoid byte-by-byte
loads and check multiple bytes at once. While this will work on x86,
it is flagged as an out-of-bounds read with ASAN, so we have to
disable instrumentation here. This also causes bounds errors for CHERI,
so in CheriBSD we use implementations that avoid OOB reads.
Differential Revision: https://reviews.freebsd.org/D31045
The ifunc resolver is called before the sanitizer runtime is initialized,
so any instrumentation results in an immediate crash.
Reviewed By: kib
Differential Revision: https://reviews.freebsd.org/D31046
I got the following error with an ASAN-instrument libthr:
==803==ERROR: AddressSanitizer: stack-buffer-overflow on address 0x7fffffffcdb0 at pc 0x000801863396 bp 0x7ff8
READ of size 4 at 0x7fffffffcdb0 thread T0
#0 0x801863395 in handle_signal /local/scratch/alr48/cheri/freebsd/lib/libthr/thread/thr_sig.c:262:2
#1 0x801860da2 in thr_sighandler /local/scratch/alr48/cheri/freebsd/lib/libthr/thread/thr_sig.c:246:2
Address 0x7fffffffcdb0 is located in stack of thread T0 at offset 208 in frame
#0 0x80186080f in thr_sighandler /local/scratch/alr48/cheri/freebsd/lib/libthr/thread/thr_sig.c:213
This frame has 1 object(s):
[32, 64) 'act' (line 216) <== Memory access at offset 208 overflows this variable
HINT: this may be a false positive if your program uses some custom stack
This seems like a false-positive since the line in question is
`SIGSETOR(actp->sa_mask, ucp->uc_sigmask);` and it complains about a read
operation (from the ucontext_t argument) so this indicates to me that ASAN
does not understand that thr_sighandler() is a signal handler.
Differential Revision: https://reviews.freebsd.org/D31074
This adds two new options WITH_ASAN/WITH_UBSAN that can be set to
enable instrumentation of all binaries with AddressSanitizer and/or
UndefinedBehaviourSanitizer. This current patch is almost sufficient
to get a complete buildworld with sanitizer instrumentation but in
order to actually build and boot a system it depends on a few more
follow-up commits.
Reviewed By: brooks, kib, markj
Differential Revision: https://reviews.freebsd.org/D31043
This is needed to bootstrap llvm-tblgen on Linux since LLVM calls
`::open(...)` which does not work if open is a statement macro.
Also stop defining O_SHLOCK/O_EXLOCK and update the only bootstrap tools
user of those flags to deal with missing definitions.
Reviewed By: jrtc27
MFC after: 1 week
Differential Revision: https://reviews.freebsd.org/D31226
Linux standardized what we call CLOCK_{REALTIME,MONOTONIC}_FAST as
CLOCK_{REALTIME,MONOTONIC}_COARSE. In addition, Linux spells
CLOCK_UPTIME as CLOCK_BOOTTIME.
Add aliases to time.h and document these new aliases in
clock_gettime(2).
Reviewed by: vangyzen, kib (prior), dchagin (prior)
Sponsored by: Netflix
Differential Revision: https://reviews.freebsd.org/D30988
After b48a2770d4, static POWER8 definitions became unnecessary,
as all of them (and much more) are already present in libpmc's
PMU events.
Submitted by: Leonardo Bianconi <leonardo.bianconi@eldorado.org.br> (initial version)
Reviewed by: kbowling, mhorne
Sponsored by: Instituto de Pesquisas Eldorado (eldorado.org.br)
Differential Revision: https://reviews.freebsd.org/D31334
of the /dev/hpet and /dev/hv_tsc devices, to not leak internal libc
filedescriptors on exec.
Reviewed by: markj
Sponsored by: The FreeBSD Foundation
MFC after: 1 week
Differential revision: https://reviews.freebsd.org/D31344
The left side of the MIN() expression is the (signed) result of pointer
subtraction (ptrdiff_t). The right hand side is the also the (signed)
result of pointer subtraction, additionally subtracting the element size
('es'), which is unsigned size_t. This coerces the right-hand
expression into an unsigned value. MIN(signed, unsigned) triggers
-Wsign-compare.
Sorting elements of size greater than SSIZE_MAX is nonsensical, so we
can instead treat the element size as ssize_t, leaving the right-hand
result the same signedness as the left.
Reviewed by: arichardson, kib
Differential Revision: https://reviews.freebsd.org/D31292
Both clang >= 12 and gcc >= 10.1 now default to -moutline-atomics for
aarch64. This requires a bunch of helper functions in libcompiler_rt.a,
to avoid link errors like "undefined symbol: __aarch64_ldadd8_acq_rel".
(Note: of course you can use -mno-outline-atomics as a workaround too,
but this would negate the potential performance benefit of the faster
LSE instructions.)
Bump __FreeBSD_version so ports maintainers can easily detect this.
PR: 257392
MFC after: 2 weeks
SO_RERROR indicates that receive buffer overflows should be handled as
errors. Historically receive buffer overflows have been ignored and
programs could not tell if they missed messages or messages had been
truncated because of overflows. Since programs historically do not
expect to get receive overflow errors, this behavior is not the
default.
This is really really important for programs that use route(4) to keep
in sync with the system. If we loose a message then we need to reload
the full system state, otherwise the behaviour from that point is
undefined and can lead to chasing bogus bug reports.
Reviewed by: philip (network), kbowling (transport), gbe (manpages)
MFC after: 2 weeks
Differential Revision: https://reviews.freebsd.org/D26652
Due to a mis-merge, the changes committed to libpmc never called
pmu_parse_event(), or set pm->pm_ev. However, this field shouldn't be
used to carry the actual pmc event code anyway, as it is expected to
contain the index into the pmu event array (otherwise, it breaks event
name lookup in pmclog_get_event()). Add a new MD field,
pm_md.pm_md_config, to pass the raw event code to arm64_allocate_pmc().
Additionally, the change made to pmc_md_op_pmcallocate was incorrect, as
this is a union, not a struct. Restore the proper padding size.
Reviewed by: luporl, ray, andrew
Fixes: 28dd6730a5 ("libpmc: enable pmu_utils on arm64")
Fixes: 8cc3815f02 ("hwpmc_arm64: accept raw event codes...")
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D31221
Before this patch there was a chance for thread that called rand(3)
slightly later to see rand3_state already allocated, but not yet
initialized. While this API is not expected to be thread-safe, it
is not expected to crash. ztest on 64-thread system reproduced it
reliably for me.
Submitted by: avg@
MFC after: 1 month
Before this patch there was a chance for thread that called rand(3)
slightly later to see rand3_state already allocated, but not yet
initialized. While this API is not expected to be thread-safe, it
is not expected to crash. ztest on 64-thread system reproduced it
reliably for me.
MFC after: 1 month
The early environment is typically cleared, so these new options
need the PRESERVE_EARLY_KENV kernel config(8) option. These environments
are reported as missing by kenv(1) if the option is not present in the
running kernel.
Reviewed by: imp
Differential Revision: https://reviews.freebsd.org/D30835
The syscall number is stored in the same register as the syscall return
on amd64 (and possibly other architectures) and so it is impossible to
recover in the signal handler after the call has returned. This small
tweak delivers it in the `si_value` field of the signal, which is
sufficient to catch capability violations and emulate them with a call
to a more-privileged process in the signal handler.
This reapplies 3a522ba1bc with a fix for
the static assertion failure on i386.
Approved by: markj (mentor)
Reviewed by: kib, bcr (manpages)
Differential Revision: https://reviews.freebsd.org/D29185
This permits more efficient accesses of thread-local variables, which
are heavily used at least by jemalloc and locale-aware code. Note that
on amd64 and i386, jemalloc's thread-local variables already have their
TLS model overridden by defining JEMALLOC_TLS_MODEL.
For now the change is applied only to tested platforms, but should in
principle be enabled everywhere.
PR: 255840
Suggested by: jrtc27
Reviewed by: kib
MFC after: 2 months
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D31070
- new sentence, new line
- tab in filled text
- unusual Xr order
- skipping paragraph macro: Pp before Ss
Reviewed by: bcr
MFC after: 1 week
Differential Revision: https://reviews.freebsd.org/D31143
- inserting missing end of block: Sh breaks Bl
- moving content out of list: Pp
- missing comma before name: Nm cap_*
- comma in function argument: cap_*
- skipping paragraph macro: Pp after Sh
- sections out of conventional order: Sh AUTHORS
Reviewed by: bcr
MFC after: 1 week
Differential Revision: https://reviews.freebsd.org/D31144
The syscall number is stored in the same register as the syscall return
on amd64 (and possibly other architectures) and so it is impossible to
recover in the signal handler after the call has returned. This small
tweak delivers it in the `si_value` field of the signal, which is
sufficient to catch capability violations and emulate them with a call
to a more-privileged process in the signal handler.
Approved by: markj (mentor)
Reviewed by: kib, bcr (manpages)
Differential Revision: https://reviews.freebsd.org/D29185
.Fa is the suitable macro for functions in comparsion to the
.Ar macro, which should be used for commandline arguments.
While here, fix some mandoc warnings.
Reviewed by: imp (earlier version)
Obtained from: OpenBSD (in partial)
MFC after: 3 days
Differential Revision: https://reviews.freebsd.org/D31090
Stop using the *NV version to retrieve states, as its performance is
unacceptably bad.
For 1,000,000 states the nvlist version needed ~100 seconds to retrieve
the states, the new version needs ~3 seconds.
Reviewed by: mjg
MFC after: 1 week
Sponsored by: Rubicon Communications, LLC ("Netgate")
Differential Revision: https://reviews.freebsd.org/D31098
These were all incorrectly labeled as 2-clause BSD licenses by a
semi-automated process, when in fact they are 3-clause.
Discussed with: pfg, imp
MFC after: 2 weeks
Sponsored by: Axcient
We must remember to free the nvlist we create from the kernel's response
to DIOCGETSTATESNV, on every iteration.
Reviewed by: donner
MFC after: 1 week
Sponsored by: Rubicon Communications, LLC ("Netgate")
Differential Revision: https://reviews.freebsd.org/D30957
This call is particularly slow due to the large amount of data it
returns. Remove all fields pfctl does not use. There is no functional
impact to pfctl, but it somewhat speeds up the call.
It might affect other (i.e. non-FreeBSD) code that uses the new
interface, but this call is very new, so there's unlikely to be any. No
releases contained the previous version, so we choose to live with the
ABI modification.
Reviewed by: donner
MFC after: 1 week
Sponsored by: Rubicon Communications, LLC ("Netgate")
Differential Revision: https://reviews.freebsd.org/D30944
I forgot to include this line in 2eb9ad4274.
Reported by: Jenkins CI
MFC after: 1 week
Fixes: 2eb9ad427475190ei ("Simplify and speed up the kyua build")
Instead of having multiple kyua libraries, just include the files as part
of usr.bin/kyua. Previously, we would build each kyua source up to four
times: once as a .o file and once as a .pieo. Additionally, the kyua
libraries might be built again for compat32. As all the kyua libraries
amount to 102 C++ sources the build time is significant (especially when
using an assertions enabled compiler). This change ensures that we build
306 fewer .cpp source files as part of buildworld.
Reviewed By: brooks
MFC after: 1 week
Differential Revision: https://reviews.freebsd.org/D30967
This introduces a new, per-process flag, "NO_NEW_PRIVS", which
is inherited, preserved on exec, and cannot be cleared. The flag,
when set, makes subsequent execs ignore any SUID and SGID bits,
instead executing those binaries as if they not set.
The main purpose of the flag is implementation of Linux
PROC_SET_NO_NEW_PRIVS prctl(2), and possibly also unpriviledged
chroot.
Reviewed By: kib
Sponsored By: EPSRC
Differential Revision: https://reviews.freebsd.org/D30939
