The new function operates similarly to ifconfig_lagg_get_lagg_status and
likewise is accompanied by a function to free the bridge status data structure.
I have included in this patch the relocation of some strings describing STP
parameters and the PV2ID macro from ifconfig into net/if_bridgevar.h as they
are useful for consumers of libifconfig.
Reviewed by: kp, melifaro, mmacy
Approved by: mmacy (mentor)
MFC after: 1 week
Relnotes: yes
Differential Revision: https://reviews.freebsd.org/D25460
When the RISC-V port was initially committed to FreeBSD, GCC would
generate 64-bit long doubles, and the definitions in _fpmath.h reflected
that. This was changed to 128-bit in GCC later that year [1], but the
definitions were never updated, despite the documented workaround. This
causes printf(3) and friends to interpret only the low 64-bits of a long
double in ldtoa, thereby printing incorrect values.
Update the definitions now that both clang and GCC generate 128-bit long
doubles.
[1] 54b21fc5ae
PR: 242067
Reported by: Dennis Clarke <dclarke@blastwave.org>
MFC after: 1 week
Differential Revision: https://reviews.freebsd.org/D25420
This was added in r293648 to pass -mlong-calls for crt1.o and gcrt1.o.
The use of -mlong-calls was removed in r358851 for LLVM 10.0, leaving
STATIC_CFLAGS empty.
Sponsored by: DARPA
Differential Revision: https://reviews.freebsd.org/D25305
llvmorg-10.0.1-rc2-0-g77d76b71d7d.
Also add a few more llvm utilities under WITH_CLANG_EXTRAS:
* llvm-dwp, a utility for merging DWARF 5 Split DWARF .dwo files into
.dwp (DWARF package files)
* llvm-size, a size(1) replacement
* llvm-strings, a strings(1) replacement
MFC after: 3 weeks
Posix says that the interpretation of the locale string is
"implementation-defined", so we ought to document what is
actually recognized.
Also add a cross reference to locale(1).
PR: 247553
MFC after: 1 week
CAP_EVENT was omitted on pidfiles (in
pidfile_open()). There seems no reason why a process that creates
and writes a pidfile cannot monitor events on that file. This mod adds
the capability.
Reviewed by: cem@
MFC after: 2 weeks
Sponsored by: Dell EMC Isilon
Differential Revision: https://reviews.freebsd.org/D25363
It seems this manpage was copied from kvm_getloadavg(3), but the
DIAGNOSTICS section was not updated completely. Update the section with
correct information about a return value of -1.
MFC after: 3 days
clang-format is enabled conditional on either WITH_CLANG_EXTRAS or
WITH_CLANG_FORMAT. Some sources in libclang are build conditional on
either rule, and obviously the clang-format binary itself depends on the
rule.
clang-format could still use a manual page.
Reviewed by: emaste
Differential Revision: https://reviews.freebsd.org/D25427
Some of the NetBSD contributed tests are gated behind the
__HAVE_LONG_DOUBLE flag. This flag seems to be defined only for
platforms whose long double is larger than their double. I could not
find this explicitly documented anywhere, but it is implied by the
definitions in NetBSD's sys/arch/${arch}/include/math.h headers, and the
following assertion from the UBSAN code:
#ifdef __HAVE_LONG_DOUBLE
long double LD;
ASSERT(sizeof(LD) > sizeof(uint64_t));
#endif
RISC-V has 128-bit long doubles, so enable the tests on this platform,
and update the comments to better explain the purpose of this flag.
Reviewed by: ngie
MFC after: 1 week
Differential Revision: https://reviews.freebsd.org/D25419
OpenZFS generates events with a "zio_timestamp" field, which gets mistaken for
"timestamp" by libdevdctl due to imprecise string matching. Then later it is
assumed a "timestamp" field exists when it doesn't and an exception is thrown.
Add a space to the search string so we match exactly "timestamp" rather than
anything with that as a suffix.
Approved by: mav (mentor)
MFC after: 3 days
Sponsored by: iXsystems, Inc.
is used by the IPPROTO_SCTP level socket options SCTP_GET_PEER_ADDRESSES
and SCTP_GET_LOCAL_ADDRESSES, which are used by libc to implement
sctp_getladdrs() and sctp_getpaddrs().
These changes allow an old libc to work on a newer kernel.
for the IPPROTO_SCTP level socket options SCTP_BINDX_ADD_ADDR and
SCTP_BINDX_REM_ADDR. These socket option are intended for internal
use only to implement sctp_bindx().
This is one user of struct sctp_getaddresses less.
struct sctp_getaddresses is strange and will be changed shortly.
Unable to find an editor, vipw would give this error:
# env EDITOR=fnord vipw
vipw: pw_edit(): No such file or directory
vigr or crontab do better:
# env EDITOR=fnord crontab -e
crontab: no crontab for root - using an empty one
crontab: fnord: No such file or directory
crontab: "fnord" exited with status 1
After this change, vipw behaves more like vigr or crontab:
# env EDITOR=fnord vipw
vipw: fnord: No such file or directory
vipw: "fnord" exited with status 1
Reviewed by: rpokala, emaste
MFC after: 1 week
Differential Revision: https://reviews.freebsd.org/D25369
The ELF notes compiled in C were placed in a section with the wrong type
(SHT_PROGBITS instead of SHT_NOTE). Previously, sed was used on the
generated assembly to rewrite the section type. Instead, write the notes
in assembly which permits setting the correct section type directly.
While here, move inline assembly entry points out of C and into assembly
for aarch64, arm, and riscv.
Reviewed by: kib
Tested on: amd64 (cirrus-ci), riscv64
Sponsored by: DARPA
Differential Revision: https://reviews.freebsd.org/D25211
- Add STANDARDS and HISTORY sections within the appropriate manpages
- Mention two USENIX papers within kqueue(2) and strlcpy(3)
Reviewed by: bcr (mentor)
Approved by: bcr (mentor)
Obtained from: NetBSD
MFC after: 7 days
Differential Revision: https://reviews.freebsd.org/D24650
The loader.ve.hashed list can easily exceed KENV_MVALLEN.
If so, bump kenv_mvallen to a multiple of KENV_MVALLEN to
accommodate the value.
Reviewed by: stevek
MFC after: 1 week
libc cannot assume that aligned_alloc and free come from jemalloc, or that
any application providing its own malloc and free is actually providing
aligned_alloc.
Switch back to malloc and just make sure we're passing a properly aligned
stack into rfork_thread, as an application perhaps can't reasonably replace
just malloc or just free without headaches.
This unbreaks ksh93 after r361996, which provides malloc/free but no
aligned_alloc.
Reported by: freqlabs
Diagnosed by: Andrew Gierth <andrew_tao173.riddles.org.uk>
X-MFC-With: r361996
pthread_get_name_np() and pthread_set_name_np().
This re-applies r361770 after compatibility fixes.
Reviewed by: antoine, jkim, markj
Tested by: antoine (exp-run)
Sponsored by: The FreeBSD Foundation
MFC after: 1 week
Differential revision: https://reviews.freebsd.org/D25117
Some environments in which execvPe may be called have a limited amount of
stack available. Currently, it avoidably allocates a segment on the stack
large enough to hold PATH so that it may be mutated and use strsep() for
easy parsing. This logic is now rewritten to just operate on the immutable
string passed in and do the necessary math to extract individual paths,
since it will be copying out those segments to another buffer anyways and
piecing them together with the name for a full path.
Additional size is also needed for the stack in posix_spawnp(), because it
may need to push all of argv to the stack and rebuild the command with sh in
front of it. We'll make sure it's properly aligned for the new thread, but
future work should likely make rfork_thread a little easier to use by
ensuring proper alignment.
Some trivial cleanup has been done with a couple of error writes, moving
strings into char arrays for use with the less fragile sizeof().
Reported by: Andrew Gierth <andrew_tao173.riddles.org.uk>
Reviewed by: jilles, kib, Andrew Gierth
MFC after: 1 week
Differential Revision: https://reviews.freebsd.org/D25038
If execve fails with ENOEXEC, execvp is expected to rebuild the command
with /bin/sh instead and try again.
The previous version did this, but overlooked two details:
argv[0] can conceivably be NULL, in which case memp would never get
terminated. We must allocate no less than three * sizeof(char *) so we can
properly terminate at all times. For the non-NULL argv standard case, we
count all the non-NULL elements and actually skip the first argument, so we
end up capturing the NULL terminator in our bcopy().
The second detail is that the spec is actually worded such that we should
have been preserving argv[0] as passed to execvp:
"[...] executed command shall be as if the process invoked the sh utility
using execl() as follows:
execl(<shell path>, arg0, file, arg1, ..., (char *)0);
where <shell path> is an unspecified pathname for the sh utility, file is
the process image file, and for execvp(), where arg0, arg1, and so on
correspond to the values passed to execvp() in argv[0], argv[1], and so on."
So we make this change at this time as well, while we're already touching
it. We decidedly can't preserve a NULL argv[0] as this would be incredibly,
incredibly fragile, so we retain our legacy behavior of using "sh" for
argv[] in this specific instance.
Some light tests are added to try and detect some components of handling the
ENOEXEC fallback; posix_spawnp_enoexec_fallback_null_argv0 is likely not
100% reliable, but it at least won't raise false-alarms and it did result in
useful failures with pre-change libc on my machine.
This is a secondary change in D25038.
Reported by: Andrew Gierth <andrew_tao173.riddles.org.uk>
Reviewed by: jilles, kib, Andrew Gierth
MFC after: 1 week
