This deliberately breaks the API in preperation for future syscall
revisions which will remove these nonstandard members.
In an exp-run a single port (devel/qemu-user-static) was found to
use them which it did becuase it emulates system calls. This has
been fixed in the ports tree.
PR: 224443 (exp-run)
Reviewed by: kib, jhb (previous version)
Exp-run by: antoine
Sponsored by: DARPA, AFRP
Differential Revision: https://reviews.freebsd.org/D14490
to fix the memory leak that I introduced in r328426. Instead of
trying to clear up the possible memory leak in all the clients, I
ensure that it gets cleaned up in the source (e.g., ffs_sbget ensures
that memory is always freed if it returns an error).
The original change in r328426 was a bit sparse in its description.
So I am expanding on its description here (thanks cem@ and rgrimes@
for your encouragement for my longer commit messages).
In preparation for adding check hashing to superblocks, r328426 is
a refactoring of the code to get the reading/writing of the superblock
into one place. Unlike the cylinder group reading/writing which
ends up in two places (ffs_getcg/ffs_geom_strategy in the kernel
and cgget/cgput in libufs), I have the core superblock functions
just in the kernel (ffs_sbfetch/ffs_sbput in ffs_subr.c which is
already imported into utilities like fsck_ffs as well as libufs to
implement sbget/sbput). The ffs_sbfetch and ffs_sbput functions
take a function pointer to do the actual I/O for which there are
four variants:
ffs_use_bread / ffs_use_bwrite for the in-kernel filesystem
g_use_g_read_data / g_use_g_write_data for kernel geom clients
ufs_use_sa_read for the standalone code (stand/libsa/ufs.c
but not stand/libsa/ufsread.c which is size constrained)
use_pread / use_pwrite for libufs
Uses of these interfaces are in the UFS filesystem, geoms journal &
label, libsa changes, and libufs. They also permeate out into the
filesystem utilities fsck_ffs, newfs, growfs, clri, dump, quotacheck,
fsirand, fstyp, and quot. Some of these utilities should probably be
converted to directly use libufs (like dumpfs was for example), but
there does not seem to be much win in doing so.
Tested by: Peter Holm (pho@)
nothing - it was checking for ENXIO, which, with devfs, is no longer
returned - and was badly placed anyway, and replaces it with similar
one that works, and is done just before starting getty, instead of being
done when rereading ttys(5).
From the practical point of view, this makes init(8) handle disappearing
terminals (eg /dev/ttyU*) gracefully, without unneccessary getty restarts
and resulting error messages.
Reviewed by: imp@
MFC after: 2 weeks
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D14307
Unlike the existing GLA2GPA ioctl, GLA2GPA_NOFAULT does not modify
the guest. In particular, it does not inject any faults or modify
PTEs in the guest when performing an address space translation.
This is used by bhyve's debug server to read and write memory for
the remote debugger.
Reviewed by: grehan
MFC after: 1 month
Differential Revision: https://reviews.freebsd.org/D14075
Added the ability to:
* Create virtual interfaces
* Create vlan interfaces
* Get interface fib
* Get interface groups
* Get interface status
* Get nd6 info
* Get media status
* Get additional ifaddr info in a convenient struct
* Get vhids
* Get carp info
* Get lagg and laggport status
* Iterate over all interfaces and ifaddrs
And add more examples, too.
Note that this is a backwards-incompatible change. But that's ok, because it's
a private library.
MFC after: 3 weeks
Sponsored by: Spectra Logic Corp
Differential Revision: https://reviews.freebsd.org/D14463
According to the getpeereid(3) documentation, on failure the value -1 is
returned and the global variable errno is set to indicate the error. We
were returning the error instead.
Obtained from: Apple's Libc-1244.30.3
MFC after: 5 days
These are a convenience for bhyve's debug server to use a single
ioctl for 'g' and 'G' rather than a loop of individual get/set
ioctl requests.
Reviewed by: grehan
MFC after: 2 months
Differential Revision: https://reviews.freebsd.org/D14074
Instead of passing flags (which describe a type of nvlist)
every send/recv we remember them in channel.
It's enough for use to extract them only during unwrap.
This simplify use of Casper.
Reviewed by: bruffer@, bcr@ (both man page)
Differential Revision: https://reviews.freebsd.org/D14196 (man page)
ffs_sbget() may return a superblock buffer even if it fails, so the
caller must be prepared to free it in this case. Moreover, when tasting
alternate superblock locations in a loop, ffs_sbget()'s readfunc
callback must free the previously allocated buffer.
Reported and tested by: pho
Reviewed by: kib (previous version)
Differential Revision: https://reviews.freebsd.org/D14390
C11 standard (ISO/IEC 9899:2011) K.3.7.4.1 The memset_s function
(p: 621-622)
Fix memset(3) portion of the man page by replacing the first argument
(destination) "b" with "dest", which is more descriptive than "b".
This also makes it consistent with the term used in the memset_s()
portion of the man page.
See also http://en.cppreference.com/w/c/string/byte/memset.
Reviewed by: kib
MFC after: 1 week
Differential Revision: https://reviews.freebsd.org/D13682
cddl/usr.sbin/zfsd/zfsd_event.cc
Remove the check for da and ada devices. This way zfsd can work on md,
geli, glabel, gstripe, etc devices. geli in particular is useful
combined with ZFS. gnop is also useful for simulating drive pulls in
the ZFSD test suite.
Also, eliminate the DevfsEvent class entirely. Move its
responsibilities into GeomEvent. We can get everything we need to know
just from listening to GEOM events.
lib/libdevdctl/event.cc
Fix GeomEvent::DevName for CREATE events. Oddly, the relevant field is
named "cdev" for CREATE events but "devname" for disk events.
MFC after: 3 weeks
Relnotes: Yes (probably worth mentioning the geli part)
Sponsored by: Spectra Logic Corp
As a component of atan2(y, x), the case of x == 1.0 is farmed out to
atan(y). The current implementation of this comparison is vulnerable
to signed integer underflow (that is, undefined behavior), and it's
performed in a somewhat more complicated way than it need be. Change
it to not be quite so cute, rather directly comparing the high/low
bits of x to the specific IEEE-754 bit pattern that encodes 1.0.
Note that while there are three different e_atan* files in the
relevant directory, only this one needs fixing. e_atan2f.c already
compares against the full bit pattern encoding 1.0f, while
e_atan2l.cuses bitwise-ands/ors/nots and so doesn't require a change.
Closes#130
Submitted by: Jeff Walden (@jswalden github PR #130)
Reviewed by: bde
MFC After: 1 month
Introduce WITH_/WITHOUT_LLVM_COV to match GCC's WITH_/WITHOUT_GCOV.
It is intended to provide a superset of the interface and functionality
of gcov.
It is enabled by default when building Clang, similarly to gcov and GCC.
This change moves one file in libllvm to be compiled unconditionally.
Previously it was included only when WITH_CLANG_EXTRAS was set, but the
complexity of a new special case for (CLANG_EXTRAS | LLVM_COV) is not
worth avoiding a tiny increase in build time.
Reviewed by: dim, imp
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D142645
The GP register can be clobbered by the callback, so save it in S1
while invoking the callback function.
While here, add a comment expounding on the treatment of GP for the
various ABIs and the assumptions made.
Reviewed by: jmallett (earlier version)
Sponsored by: DARPA / AFRL
Differential Revision: https://reviews.freebsd.org/D14179
-Wno-error=tautological-constant-compare again (this flag is now out of
-Wextra after upstream https://reviews.llvm.org/rL322901). Otherwise
the MK_SYSTEM_COMPILER logic will not build a cross-tools compiler.
Reported by: jpaetzel, tuexen, Stefan Hagen
objects' init functions instead of doing the setup via a constructor
in libc as the init functions may already depend on these handlers
to be in place. This gets us rid of:
- the undefined order in which libc constructors as __guard_setup()
and jemalloc_constructor() are executed WRT __sparc_utrap_setup(),
- the requirement to link libc last so __sparc_utrap_setup() gets
called prior to constructors in other libraries (see r122883).
For static binaries, crt1.o still sets up the user trap handlers.
o Move misplaced prototypes for MD functions in to the MD prototype
section of rtld.h.
o Sprinkle nitems().
6.0.0 (branches/release_60 r324090).
This introduces retpoline support, with the -mretpoline flag. The
upstream initial commit message (r323155 by Chandler Carruth) contains
quite a bit of explanation. Quoting:
Introduce the "retpoline" x86 mitigation technique for variant #2 of
the speculative execution vulnerabilities disclosed today,
specifically identified by CVE-2017-5715, "Branch Target Injection",
and is one of the two halves to Spectre.
Summary:
First, we need to explain the core of the vulnerability. Note that
this is a very incomplete description, please see the Project Zero
blog post for details:
https://googleprojectzero.blogspot.com/2018/01/reading-privileged-memory-with-side.html
The basis for branch target injection is to direct speculative
execution of the processor to some "gadget" of executable code by
poisoning the prediction of indirect branches with the address of
that gadget. The gadget in turn contains an operation that provides a
side channel for reading data. Most commonly, this will look like a
load of secret data followed by a branch on the loaded value and then
a load of some predictable cache line. The attacker then uses timing
of the processors cache to determine which direction the branch took
*in the speculative execution*, and in turn what one bit of the
loaded value was. Due to the nature of these timing side channels and
the branch predictor on Intel processors, this allows an attacker to
leak data only accessible to a privileged domain (like the kernel)
back into an unprivileged domain.
The goal is simple: avoid generating code which contains an indirect
branch that could have its prediction poisoned by an attacker. In
many cases, the compiler can simply use directed conditional branches
and a small search tree. LLVM already has support for lowering
switches in this way and the first step of this patch is to disable
jump-table lowering of switches and introduce a pass to rewrite
explicit indirectbr sequences into a switch over integers.
However, there is no fully general alternative to indirect calls. We
introduce a new construct we call a "retpoline" to implement indirect
calls in a non-speculatable way. It can be thought of loosely as a
trampoline for indirect calls which uses the RET instruction on x86.
Further, we arrange for a specific call->ret sequence which ensures
the processor predicts the return to go to a controlled, known
location. The retpoline then "smashes" the return address pushed onto
the stack by the call with the desired target of the original
indirect call. The result is a predicted return to the next
instruction after a call (which can be used to trap speculative
execution within an infinite loop) and an actual indirect branch to
an arbitrary address.
On 64-bit x86 ABIs, this is especially easily done in the compiler by
using a guaranteed scratch register to pass the target into this
device. For 32-bit ABIs there isn't a guaranteed scratch register
and so several different retpoline variants are introduced to use a
scratch register if one is available in the calling convention and to
otherwise use direct stack push/pop sequences to pass the target
address.
This "retpoline" mitigation is fully described in the following blog
post: https://support.google.com/faqs/answer/7625886
We also support a target feature that disables emission of the
retpoline thunk by the compiler to allow for custom thunks if users
want them. These are particularly useful in environments like
kernels that routinely do hot-patching on boot and want to hot-patch
their thunk to different code sequences. They can write this custom
thunk and use `-mretpoline-external-thunk` *in addition* to
`-mretpoline`. In this case, on x86-64 thu thunk names must be:
```
__llvm_external_retpoline_r11
```
or on 32-bit:
```
__llvm_external_retpoline_eax
__llvm_external_retpoline_ecx
__llvm_external_retpoline_edx
__llvm_external_retpoline_push
```
And the target of the retpoline is passed in the named register, or in
the case of the `push` suffix on the top of the stack via a `pushl`
instruction.
There is one other important source of indirect branches in x86 ELF
binaries: the PLT. These patches also include support for LLD to
generate PLT entries that perform a retpoline-style indirection.
The only other indirect branches remaining that we are aware of are
from precompiled runtimes (such as crt0.o and similar). The ones we
have found are not really attackable, and so we have not focused on
them here, but eventually these runtimes should also be replicated for
retpoline-ed configurations for completeness.
For kernels or other freestanding or fully static executables, the
compiler switch `-mretpoline` is sufficient to fully mitigate this
particular attack. For dynamic executables, you must compile *all*
libraries with `-mretpoline` and additionally link the dynamic
executable and all shared libraries with LLD and pass `-z
retpolineplt` (or use similar functionality from some other linker).
We strongly recommend also using `-z now` as non-lazy binding allows
the retpoline-mitigated PLT to be substantially smaller.
When manually apply similar transformations to `-mretpoline` to the
Linux kernel we observed very small performance hits to applications
running typic al workloads, and relatively minor hits (approximately
2%) even for extremely syscall-heavy applications. This is largely
due to the small number of indirect branches that occur in
performance sensitive paths of the kernel.
When using these patches on statically linked applications,
especially C++ applications, you should expect to see a much more
dramatic performance hit. For microbenchmarks that are switch,
indirect-, or virtual-call heavy we have seen overheads ranging from
10% to 50%.
However, real-world workloads exhibit substantially lower performance
impact. Notably, techniques such as PGO and ThinLTO dramatically
reduce the impact of hot indirect calls (by speculatively promoting
them to direct calls) and allow optimized search trees to be used to
lower switches. If you need to deploy these techniques in C++
applications, we *strongly* recommend that you ensure all hot call
targets are statically linked (avoiding PLT indirection) and use both
PGO and ThinLTO. Well tuned servers using all of these techniques saw
5% - 10% overhead from the use of retpoline.
We will add detailed documentation covering these components in
subsequent patches, but wanted to make the core functionality
available as soon as possible. Happy for more code review, but we'd
really like to get these patches landed and backported ASAP for
obvious reasons. We're planning to backport this to both 6.0 and 5.0
release streams and get a 5.0 release with just this cherry picked
ASAP for distros and vendors.
This patch is the work of a number of people over the past month:
Eric, Reid, Rui, and myself. I'm mailing it out as a single commit
due to the time sensitive nature of landing this and the need to
backport it. Huge thanks to everyone who helped out here, and
everyone at Intel who helped out in discussions about how to craft
this. Also, credit goes to Paul Turner (at Google, but not an LLVM
contributor) for much of the underlying retpoline design.
Reviewers: echristo, rnk, ruiu, craig.topper, DavidKreitzer
Subscribers: sanjoy, emaste, mcrosier, mgorny, mehdi_amini, hiraditya, llvm-commits
Differential Revision: https://reviews.llvm.org/D41723
MFC after: 3 months
X-MFC-With: r327952
PR: 224669
In contrast to the existing NetBSD setcontext_link test, these tests
verify that passing from 1 to 6 arguments through to the callback function
work correctly which can be useful for testing ABIs which split arguments
between registers and the stack.
Sponsored by: DARPA / AFRL
This implementation spills additional arguments on the stack so works
fine with more than 6 arguments. I believe the check was just copied
over from sparc64 (which doesn't support spilling onto the stack)
Sponsored by: DARPA / AFRL
NCARGS isn't a limit on the number of arguments to pass to a function,
but the number of bytes that can be consumed by arguments to exec. As
such, it is not suitable for a limit on the count of arguments passed
to makecontext().
Sponsored by: DARPA / AFRL
- Add a new <machine/abi.h> header to hold constants shared between C
and assembly such as CALLFRAME_SZ.
- Add a new STACK_ALIGN constant to <machine/abi.h> and use it to
replace hardcoded constants in the kernel and makecontext(). As a
result of this, ensure the stack pointer on N32 and N64 is 16-byte
aligned for N32 and N64 after exec(), after pthread_create(), and
when sending signals rather than 8-byte aligned.
Reviewed by: jmallett
Sponsored by: DARPA / AFRL
Differential Revision: https://reviews.freebsd.org/D13875
NetBSD's libedit has been been cleaned-up considerably so the
non--widecharacter version is no longer an option. Re -sorting the
Makefile should make it easier for some brave soul trying to update it.
No functional change intended.
MFC after: 5 days
The test was added prematurely as a goal to reach with the GNU extension
functionality, but the functionality has not yet been introduced. Mark it as
an expected fail until that point.
- N32 and N64 do not have a $a0-3 gap.
- Use 'sp += 4' to skip over the gap for O32 rather than '+= i'. It
doesn't make a functional change, but makes the code match the comment.
Sponsored by: DARPA / AFRL
Specifically reading is done if ffs_sbget() and writing is done
in ffs_sbput(). These functions are exported to libufs via the
sbget() and sbput() functions which then used in the various
filesystem utilities. This work is in preparation for adding
subperblock check hashes.
No functional change intended.
Reviewed by: kib
r260553 added a number of mangled C++ symbols to Version.map inside of
an existing `extern "C++"` block.
ld.bfd 2.17.50 treats `extern "C++"` permissively and will match both
mangled and demangled symbols against the strings in the version map
block. ld.lld interprets `extern "C++"` strictly, and matches only
demangled symbols.
I believe lld's behaviour is correct. Contemporary versions of ld.bfd
also behave as lld does, so move the mangled symbols out of the
`extern "C++"` block.
PR: 225128, 185663
MFC after: 1 week
Sponsored by: The FreeBSD Foundation
utilities is done by calling gr_addgid() for each group to be
added (usually found by traversing /etc/group) then calling the
setgroups() system call after the group set has been created.
The gr_addgid() function (helpfully?) deduplicates the addition
of group members. So, if you call it to add a group member that
already exists, it is just dropped. Because group[0] is the
effective group-ID and is over-written when a setgid program
is run, The value in group[0] is usually duplicated so that
group value is not lost when a setgid program is run.
Historically this happened because the group value indicated
in the password file also appears in /etc/group (e.g., if you
are group staff in the password file, you will also appear in
the staff line in /etc/group). But, with the addition of the
deduplication, the attempt to add group staff was lost because
it already appeared in group[0]. So, the fix is to deduplicate
starting from group[1] which allows a duplicate of the entry in
group[0], but not in later entries.
There is some confusion about the setgroups system call because in
BSD it has (always) set the entire group including the egid group
(in group[0]). However, in Linux, it skips over group[0] and starts
setting from group[1]. See this comment from linux_setgroups:
/*
* cr_groups[0] holds egid. Setting the whole set from
* the supplied set will cause egid to be changed too.
* Keep cr_groups[0] unchanged to prevent that.
*/
To make it clear what the BSD setgroups system call does, I
added the following paragraph to the setgroups(2) manual page:
The first entry of the group array (gidset[0]) is used as the effective
group-ID for the process. This entry is over-written when a setgid
program is run. To avoid losing access to the privileges of the
gidset[0] entry, it should be duplicated later in the group array.
By convention, this happens because the group value indicated in the
password file also appears in /etc/group. The group value in the
password file is placed in gidset[0] and that value then gets added a
second time when the /etc/group file is scanned to create the group set.
Reported by: Paul McMath paulm at tetrardus.net
Reviewed by: kib
MFC after: 2 weeks
The man page is years out of date regarding errors. Our implementation _does_
allow unaligned addresses, and it _does_not_ check for negative lengths,
because the length is unsigned. It checks for overflow instead.
Update the tests accordingly.
Reviewed by: bcr
MFC after: 3 weeks
Differential Revision: https://reviews.freebsd.org/D13826
kib points out that trying to re-use symbol versioning from libc is dirty
and wrong. The implementation in libregex is incompatible by design with the
implementation in libc. Using the symbol versions from libc can and likely
will cause confusions for linkers and bring unexpected behavior for
consumers that unwillingly (transitively) link against libregex.
Reported by: kib
It's become clear that my armv7 builds didn't catch all of the warnings that
other builds are picking up, drop WARNS to 2 to match libc until they're all
caught.
regcomp uses some libc internal collation bits that are not available in the
libregex context. It's easy enough to bring in the needed parts that can
work in a libregex world, so do so.
Pointy hat to: me
libregex is a regex(3) implementation intended to feature GNU extensions and
any other non-POSIX compliant extensions that are deemed worthy.
These extensions are separated out into a separate library for the sake of
not cluttering up libc further with them as well as not deteriorating the
speed (or lack thereof) of the libc implementation.
libregex is implemented as a build of the libc implementation with LIBREGEX
defined to distinguish this from a libc build. The reasons for
implementation like this are two-fold:
1.) Maintenance- This reduces the overhead induced by adding yet another
regex implementation to base.
2.) Ease of use- Flipping on GNU extensions will be as simple as linking
against libregex, and POSIX-compliant compilations can be guaranteed with a
REG_POSIX cflag that should be ignored by libc/regex and disables extensions
in libregex. It is also easier to keep REG_POSIX sane and POSIX pure when
implemented in this fashion.
Tests are added for future functionality, but left disconnected for the time
being while other testing is done.
Reviewed by: cem (previous version)
Differential Revision: https://reviews.freebsd.org/D12934
break is probably intended and correct,
but has no correctness implications due to is94 => is96
Reviewed by: cem, jilles
Reported by: swildner@DragonFlyBSD.org
MFC After: 1 week
libc is set for WARNS=2, but the incoming libregex will use WARNS=6.
Sprinkle some casts and (void)bc's to alleviate the warnings that come along
with the higher WARNS level.
These 'bc' parameters could be outright removed, but as of right now they
will be used in some parts of libregex land. Silence the warnings instead
rather than flip-flopping.
check-hash after making changes to the cylinder group. The problem
was that the journal-recovery code was calling the libufs bwrite()
function instead of the cgput() function. The cgput() function updates
the cylinder-group check-hash before writing the cylinder group.
This change required the additions of the cgget() and cgput() functions
to the libufs API to avoid a gratuitous bcopy of every cylinder group
to be read or written. These new functions have been added to the
libufs manual pages. This was the first opportunity that I have had
to use and document the use of the EDOOFUS error code.
Reviewed by: kib
Reported by: emaste and others
Allow usage of X86-prefixes as separate instrs.
Differential Revision: https://reviews.llvm.org/D42102
This should fix parse errors when x86 prefixes (such as 'lock' and
'rep') are followed by various non-mnemonic tokens, e.g. comments, .byte
directives and labels.
PR: 224669,225054
pmcstat request for close will generate a close event.
This event will be in turn received by pmcstat to close the file.
Reviewed by: kib
Tested by: pho
MFC after: 1 week
Sponsored by: Stormshield
In order to crossbuild FreeBSD on Mac/Linux I also need to build libnetbsd
and FILE* is not equal to struct __sFILE on those platforms.
Reviewed By: brooks, emaste
Approved By: jhb (mentor)
Differential Revision: https://reviews.freebsd.org/D13305
to the next int position.
Bug was introduced in r324959 ("Extract a set of pmcstat functions and
interfaces to the new internal library -- libpmcstat.")
This fixes pmcstat top mode (-T) operation.
Example: pmcstat -n1 -S clock.hard -T
Reported by: Peter Holm <peter@holm.cc>
Sponsored by: DARPA, AFRL
This should be effectively a nop for all archs, but for some reason the codegen
difference on the PowerPC 970 is such that the struct assignment doesn't work
(unless a printf() using one of the elements in the copied struct follows it),
while the memcpy() succeeds. On all archs the memcpy() should be expanded to an
inline copy, since the copy is bounded to ~16 bytes.
MFC after: 3 weeks
domains can be done by the _domain() API variants. UMA also supports a
first-touch policy via the NUMA zone flag.
The slab layer is now segregated by VM domains and is precise. It handles
iteration for round-robin directly. The per-cpu cache layer remains
a mix of domains according to where memory is allocated and freed. Well
behaved clients can achieve perfect locality with no performance penalty.
The direct domain allocation functions have to visit the slab layer and
so require per-zone locks which come at some expense.
Reviewed by: Attilio (a slightly older version)
Tested by: pho
Sponsored by: Netflix, Dell/EMC Isilon
userspace to control NUMA policy administratively and programmatically.
Implement domainset based iterators in the page layer.
Remove the now legacy numa_* syscalls.
Cleanup some header polution created by having seq.h in proc.h.
Reviewed by: markj, kib
Discussed with: alc
Tested by: pho
Sponsored by: Netflix, Dell/EMC Isilon
Differential Revision: https://reviews.freebsd.org/D13403
would be filesystem type dependent, but that's difficult to accomplish
and it's unclear how the UEFI firmware will cope. Be conservative and
make boot loaders cope instead.
Sponsored by: Netflix
condition. This should prevent a double free. In addition, prevent a
leak by freeing dp each loop and when we're done.
CID: 1383577
Sponsored by: Netflix
Fix for remainder overflow, when in rare cases adding remainder to divider
exceeded 1 and turned the total to 1000 in final formatting, taking up
the space for the unit character.
The fix continues the division of the original number if the above case
happens -- added the appropriate check to the for loop performing
the division. This lowers the value shown, to make it fit into the buffer
space provided (1.0M for 4+1 character buffer, as used by ls).
Add test case for the reported bug and extend test program to support
providing buffer length (ls -lh uses 5, tests hard-coded 4).
PR: 224498
Submitted by: Pawel Biernacki <pawel.biernacki@gmail.com>
Reported by: Masachika Ishizuka <ish@amail.plala.or.jp>
Reviewed by: cem, kib
Approved by: cem, kib
MFC after: 1 week
Sponsored by: Mysterious Code Ltd.
Differential Revision: D13578
The daemonfd function is equivalent to the daemon(3) function expect that
arguments are descriptors. For example dhclient(8) which is sandboxed is
unable to open /dev/null to close stdio instead it's allows to fail
daemon(3) function to close the descriptors and then do it explicit in code.
Instead of such hacks we can use now daemonfd.
This API can be also helpful to migrate system to platforms like CheriBSD.
Reviewed by: brooks@, bcr@, jilles@ (earlier version)
Differential Revision: https://reviews.freebsd.org/D13433
have access to machines that are pushing 400 devices. When 1,000 was
selected, it was rare to get even 40 or 50 devices. Bump the limit by
10x to keep up with the times.
Sponsored by: Netflix
In order to let truss(8) support tracing of 32-bit CloudABI
applications, we need to add a new ABI type to libsysdecode. We can
reuse the existing errno mapping table. Also link in the cloudabi32
system call table to translate system call names.
While there, remove all of the architecture ifdefs. There are not
needed, as the CloudABI data types and system call tables build fine on
any architecture. Building this unconditionally will make it easier to
do tracing for different compat modes, emulation, etc.
Reviewed by: jhb
Differential Revision: https://reviews.freebsd.org/D13516
There are two versions of variant I of TLS
- ARM and aarch64 uses original version of variant I here TP points to
start of TCB followed by aligned TLS segment. Both TCB and TLS must
be aligned to alignment of TLS section. The TCB[0] points to DTV vector
and DTV values are real addresses (without bias).
- MIPS, PowerPC and RISC-V use modified version of variant I,
where TP points (with bias) to TLS and TCB immediately precedes TLS
without any alignment gap. Only TLS should be aligned. The TCB[0]
points to DTV vector and DTV values are biased by constant value (0x8000)
from real addresses.
Take all this in account when allocating memory for TLS structures.
MFC after: 1 month
Reviewed by: kib, mizhka
Tested by: mizhka(on mips)
Differential Revision: https://reviews.freebsd.org/D13378
Now that the POSIX working group is going to require that basename(3)
and dirname(3) are thread-safe in future revisions of the standard,
there is even less of a need to provide basename_r(3). Remove this
function to prevent people from writing code that only builds on
FreeBSD and Bionic.
Removing this function seems to break exactly one port: sbruno@'s
qemu-user-static. I will send him a pull request on GitHub in a bit.
__FreeBSD_version will not be bumped, as any value from 2017 can be used
to test for the presence of a thread-safe basename(3)/dirname(3).
PR: https://bugs.freebsd.org/224016
Currently each call to telldir() requires a malloc and adds an entry to a
linked list which must be traversed on future telldir(), seekdir(),
closedir(), and readdir() calls. Applications that call telldir() for every
directory entry incur O(n^2) behavior in readdir() and O(n) in telldir() and
closedir().
This optimization eliminates the malloc() and linked list in most cases by
packing the relevant information into a single long. On 64-bit architectures
msdosfs, NFS, tmpfs, UFS, and ZFS can all use the packed representation. On
32-bit architectures msdosfs, NFS, and UFS can use the packed
representation, but ZFS and tmpfs can only use it for about the first 128
files per directory. Memory savings is about 50 bytes per telldir(3) call.
Speedup for telldir()-heavy directory traversals is about 20-30x for one
million files per directory.
Reviewed by: kib, mav, mckusick
MFC after: 3 weeks
Sponsored by: Spectra Logic Corp
Differential Revision: https://reviews.freebsd.org/D13385
matching failure.
According to the Open Group documentation for fwscanf:
"Upon successful completion, these functions shall return the number of
successfully matched and assigned input items; this number can be zero in
the event of an early matching failure."
Without this change, fwscanf would return EOF in the case of an early
matching failure, instead of the proper return value of 0.
This change aligns fwscanf(3) with the implementation in fscanf(3).
PR: 202240
Submitted by: rajendra.sy@gmail.com
Reviewed by: jhb, cem
Approved by: sjg (mentor)
MFC after: 2 weeks
Differential Revision: https://reviews.freebsd.org/D13288
Using
.symver foo,foo@@VER
causes foo and foo@@VER to be output to the .o file. This requires foo
to be weak since the linker handles foo@@VER as foo.
Using
.symver foo,foo@@@VER
causes just foo@@ver to be output and avoid the need for making foo
weak. It also reduces the constraint on how exactly a linker has to
handle foo and foo@@VER being present.
Submitted by: Rafael Espíndola
Reviewed by: dim, kib
Differential Revision: https://reviews.freebsd.org/D11653
efivar_device_path_to_unix_path translates from UEFI to Unix
efivar_unix_path_to_device_path translates from Unix to UEFI
At present, only HD() device types are supported (both GPT and
MBR). CdRom and floppy devices aren't supported. ZFS isn't supported
because there's no way in the UEFI standard to specify a ZFS datastore.
Network devices aren't supported either.
Three forms of Unix path are accepted: /path/to/file (for a mounted
filesystem), //path/to/file (uses the EFI partition on the same disk
as /), and dev:/path/to/file (for unmounted filesystem). Two forms are
produced (the first and last).
Sponsored by: Netflix
system calls. Man pages are missing for v2 and v5, so any entries for
those versions were inferred by new implementations of these functions
in libc.
Obtained from: http://www.tuhs.org/cgi-bin/utree.pl
It would previously return negative zero for -0.0 since -0.0 does not
compare less than 0. The issue was discovered when running the libc++
test suite on softfloat MIPS64.
I have verified that both clang and GCC generate sensible code for the
builtin. For soft float they clear the sign bit using integer operations
and in hard float mode they use abs.d.
Reviewed by: #mips, jhb, brooks, imp, emaste
Approved by: jhb (mentor)
Differential Revision: https://reviews.freebsd.org/D13135
Mainly focus on files that use BSD 2-Clause license, however the tool I
was using mis-identified many licenses so this was mostly a manual - error
prone - task.
The Software Package Data Exchange (SPDX) group provides a specification
to make it easier for automated tools to detect and summarize well known
opensource licenses. We are gradually adopting the specification, noting
that the tags are considered only advisory and do not, in any way,
superceed or replace the license texts.
Mainly focus on files that use BSD 2-Clause license, however the tool I
was using mis-identified many licenses so this was mostly a manual - error
prone - task.
The Software Package Data Exchange (SPDX) group provides a specification
to make it easier for automated tools to detect and summarize well known
opensource licenses. We are gradually adopting the specification, noting
that the tags are considered only advisory and do not, in any way,
superceed or replace the license texts.
- Add a new KTR_STRUCT_ARRAY ktrace record type which dumps an array of
structures.
The structure name in the record payload is preceded by a size_t
containing the size of the individual structures. Use this to
replace the previous code that dumped the kevent arrays dumped for
kevent(). kdump is now able to decode the kevent structures rather
than dumping their contents via a hexdump.
One change from before is that the 'changes' and 'events' arrays are
not marked with separate 'read' and 'write' annotations in kdump
output. Instead, the first array is the 'changes' array, and the
second array (only present if kevent doesn't fail with an error) is
the 'events' array. For kevent(), empty arrays are denoted by an
entry with an array containing zero entries rather than no record.
- Move kevent decoding tables from truss to libsysdecode.
This adds three new functions to decode members of struct kevent:
sysdecode_kevent_filter, sysdecode_kevent_flags, and
sysdecode_kevent_fflags.
kdump uses these helper functions to pretty-print kevent fields.
- Move structure definitions for freebsd11 and freebsd32 kevent
structures to <sys/event.h> so that they can be shared with userland.
The 32-bit structures are only exposed if _WANT_KEVENT32 is defined.
The freebsd11 structures are only exposed if _WANT_FREEBSD11_KEVENT is
defined. The 32-bit freebsd11 structure requires both.
- Decode freebsd11 kevent structures in truss for the compat11.kevent()
system call.
- Log 32-bit kevent structures via ktrace for 32-bit compat kevent()
system calls.
- While here, constify the 'void *data' argument to ktrstruct().
Reviewed by: kib (earlier version)
MFC after: 1 month
Differential Revision: https://reviews.freebsd.org/D12470
sa(4) has some unique behavior that is special-cased in cam_get_device. The
existing tests don't provide coverage for this special case.
Reviewed by: ken
MFC after: 3 weeks
Sponsored by: Spectra Logic Corp
Differential Revision: https://reviews.freebsd.org/D13185
Add some rules to more closely match what illumos does when an address
resolves to multiple symbols:
- prefer non-local symbols
- prefer symbols with fewer leading underscores and no leading '$'
Add some regression tests to verify these rules.
* Wrongly matches strings that are shorter than the pattern
* Fails to match negative character sets
* Fails to match character sets that aren't at the end of the pattern
* Fails to match character ranges
Reviewed by: imp
MFC after: 3 weeks
Sponsored by: Spectra Logic Corp
Differential Revision: https://reviews.freebsd.org/D13173
Previously it was enabled by WITH_/WITHOUT_TOOLCHAIN, but it is commonly
expected to be available and may have non-toolchain consumers. As it
is now taken from the BSD-licensed ELF Tool Chain project, just install
it unconditionally.
PR: 213665, 223725
Reviewed by: bdrewery
MFC after: 1 month
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D8398
Mainly focus on files that use BSD 3-Clause license.
The Software Package Data Exchange (SPDX) group provides a specification
to make it easier for automated tools to detect and summarize well known
opensource licenses. We are gradually adopting the specification, noting
that the tags are considered only advisory and do not, in any way,
superceed or replace the license texts.
Special thanks to Wind River for providing access to "The Duke of
Highlander" tool: an older (2014) run over FreeBSD tree was useful as a
starting point.
The Software Package Data Exchange (SPDX) group provides a specification
to make it easier for automated tools to detect and summarize well known
opensource licenses. We are gradually adopting the specification, noting
that the tags are considered only advisory and do not, in any way,
superceed or replace the license texts.
Special thanks to Wind River for providing access to "The Duke of
Highlander" tool: an older (2014) run over FreeBSD tree was useful as a
starting point.
Initially, only tag files that use BSD 4-Clause "Original" license.
RelNotes: yes
Differential Revision: https://reviews.freebsd.org/D13133
Do not use macros in the -width of a .Bl, since mandoc does not support them.
Fix issues reported by igor and mandoc -Tlint.
Use a .Bl for list of clock IDs instead of a comma list.
MFC after: 3 days
Sponsored by: Dell EMC
Add notes to each of these that specifically state that results are
undefined if the strings overlap. In the case of memcpy, we document
the overlapping behavior on FreeBSD (pre-existing). For str*, it is
left unspecified, however, since the default (and x86) implementations
do not handle overlapping strings properly.
PR: 223653
Sponsored by: Netflix
syslog in libc secretly reconnects to the daemon.
Another issue is that we don't have any information from openlog(3) if we
succeeded to open log or not so we don't know if we are ready
to enter cabability mode.
Because all of that we decided we need a syslog service for Caspser.
Reviewed by: bapt@
Differential Revision: https://reviews.freebsd.org/D12824
function, so check if cap_chanel_t is NULL is not enough.
Casper with a normal libc will still fail in capability mote so let's not
enter capability mode without casper support when we need to resolve DNS.
Reviewed by: cem
Differential Revision: https://reviews.freebsd.org/D12823
This API allows callers to enumerate all known pages, including any
direct map & kernel map virtual addresses, physical addresses, size,
offset into the core, & protection configured.
For architectures that support direct map addresses, also generate pages
for any direct map only addresses that are not associated with kernel
map addresses.
Fix page size portability issue left behind from previous kvm page table
lookup interface.
Reviewed by: jhb
Sponsored by: Backtrace I/O
Differential Revision: https://reviews.freebsd.org/D12279
We started out having Linux compatible libefivar interfaces. This was
in anticipation of porting the GPL'd efibootmgr to FreeBSD via a
port. However, since we need that functionality in the base, that port
isn't going to happened. It also appears that efivar is a private
library that's not used much outside a command line util and
efibootmgr. Reduce compatibility with the Linux version a little by
removing the mode parameter to efi_set_variable (which was unused on
FreeBSD, and not set to something useful in the code we'd
written). Also remove some efi error routines that were never
implemented and existed only to placate early GPL efibootmgr porting
experiments.
Suggested by: Matt Williams
Sponsored by: Netflix
This allows the _SKIP_DEPEND optimization to work, avoiding reading
the files when not needed. It also fixes META_MODE incorrectly
reading these files when not needed.
Sponsored by: Dell EMC Isilon
* Don't test MACHINE, it's irrelevant to userland and should never be
used in userland Makefiles.
* If we match armv[67] and CPUTYPE is undefined OR it doesn't have
'soft' in it, choose armhf.
* Add a note that the soft float on armv[67] may be broken.
Sponsored by: Netflix
:U:Mfoo expands to :Mfoo, apparently. Explicit check for CPUTYPE being
defined, and test for it's value not containing *soft* before calling CRTARCH
armhf.
Tested, somewhat. Unfortunately recent changes appear to have affected
cross-builds where it no longer works, per my tests after universe12a being
upgraded from 07/2017 to 11/2017 sources (DESTDIR isn't being used in WORLDTMP;
MK_SYSTEM_COMPILER might be causing issues right now).
MFC after: 1 week
MFC with: r325502
Reported by: imp
CPUTYPE (apparently) isn't defined in non-cross-builds, which caused
arm/armv[67] hosted/targeted builds to fail when evaluating CPUTYPE.
Add the :U modifier to CPUTYPE so it evaluates to "". This allows armv[67] to
get past the conditional successfully.
MFC after: 1 week
Reported by: bob prohaska <fbsd@www.zefox.net>
- MK_PROFILE is controlled in bsd.opts.mk, which is pulled in via bsd.own.mk,
which is pulled in via bsd.init.mk . All upstream Makefiles which build off
of this one use bsd.init.mk.
- COMPILER_{TYPE,VERSION} is set via bsd.compiler.mk .
This reduces the namespace pollution/complexity somewhat.
MFC after: 1 week
Despite the fact that it's a working solution, it doesn't follow the design
philosophy of only doing TARGET_* in Makefile.inc1 and special locations in
the source tree.
PR: 222925
Requested by: imp
- Define TARGET_CPUARCH and use in libclang_rt as the basis for CRTARCH
When cross-compiling, the wrong architecture was being embedded in the
libclang_rt binary filenames. It should be based on TARGET_ARCH (target), not
MACHINE_ARCH (host).
If TARGET_ARCH isn't defined (host-builds), fallback to MACHINE_ARCH.
- Define CRTARCH to armhf when TARGET/TARGET_ARCH are set to arm/armv[67]
TARGET_ABI/TARGET_CPU in Makefile.inc1 sets the ABI to gnueabihf, which
affects the clang lookup path per `getArchNameForCompilerRTLib(..)` in
contrib/llvm/tools/clang/lib/Driver/ToolChain.cpp, so chase clang and
Linux's assumed naming convention for hard-float arm architectures.
CROSSENV (in Makefile.inc1) sets CPUTYPE/MACHINE(_ARCH)? to the
TARGET*-relevant values when building the `libraries` target, so test
those variables instead.
- Add OLD_FILES/OLD_LIBS entries for TARGET/TARGET_ARCH == arm/armv[67]. This
impacts only arm/armv6 and arm/armv7.
PR: 222925
Several of the flags were being treated as CFLAGS, when they were actually
technically CXXFLAGS. Move them there.
Only apply -fno-sanitize=safe-stack with clang.
PR: 223179
TARGET_ABI/TARGET_CPU in Makefile.inc1 sets the ABI to gnueabihf, which affects
the clang lookup path per getArchNameForCompilerRTLib(..) in
contrib/llvm/tools/clang/lib/Driver/ToolChain.cpp .
This is a follow up to r324873.
PR: 222925
