Even though clang comes with a number of internal CUDA wrapper headers,
compiling sample CUDA programs will result in errors similar to:
In file included from <built-in>:1:
In file included from /usr/lib/clang/9.0.0/include/__clang_cuda_runtime_wrapper.h:204:
/usr/home/arr/cuda/var/cuda-repo-10-0-local-10.0.130-410.48/usr/local/cuda-10.0//include/crt/math_functions.hpp:2910:7: error: no matching function for call to '__isnan'
if (__isnan(a)) {
^~~~~~~
/usr/lib/clang/9.0.0/include/__clang_cuda_device_functions.h:460:16: note: candidate function not viable: call to __device__ function from __host__ function
__DEVICE__ int __isnan(double __a) { return __nv_isnand(__a); }
^
CUDA expects __isnan() and __isnanf() declarations to be available,
which are glibc specific extensions, equivalent to the regular isnan()
and isnanf().
To provide these, define __isnan() and __isnanf() as aliases of the
already existing static inline functions __inline_isnan() and
__inline_isnanf() from math.h.
Reported by: arrowd
PR: 241550
MFC after: 1 week
This warning (comparing a pointer against a zero character literal
rather than NULL) has existed since GCC 7.1.0, and was recently added to
Clang trunk.
Almost all of these are harmless, except for fwcontrol's str2node, which
needs to both guard against dereferencing a NULL pointer (though in
practice it appears none of the callers will ever pass one in), as well
as ensure it doesn't parse the empty string as node 0 due to strtol's
awkward interface.
Submitted by: James Clarke <jtrc27@jrtc27.com>
Obtained from: CheriBSD
Sponsored by: DARPA, AFRL
Differential Revision: https://reviews.freebsd.org/D21914
While FreeBSD's implementation of these expect an int inside of libc, that's an
implementation detail that we can hide from the user as it's the natural
promotion of the current mode_t type and before it is used in the kernel, it's
converted back to the narrower type that's the current definition of mode_t. As
such, documenting int is at best confusing and at worst misleading. Instead add
a note that these args are variadic and as such calling conventions may differ
from non-variadic arguments.
promoted to ints).
- `mode_t` is `uint16_t` (`sys/sys/_types.h`)
- `openat` takes variadic args
- variadic args cannot be 16-bit, and indeed the code uses int
- the manpage currently kinda implies the argument is 16-bit by saying `mode_t`
Prompted by Rust things: https://github.com/tailhook/openat/issues/21
Submitted by: Greg V at unrelenting
Differential Revision: https://reviews.freebsd.org/D21816
Add an atomic shm rename operation, similar in spirit to a file
rename. Atomically unlink an shm from a source path and link it to a
destination path. If an existing shm is linked at the destination
path, unlink it as part of the same atomic operation. The caller needs
the same permissions as shm_unlink to the shm being renamed, and the
same permissions for the shm at the destination which is being
unlinked, if it exists. If those fail, EACCES is returned, as with the
other shm_* syscalls.
truss support is included; audit support will come later.
This commit includes only the implementation; the sysent-generated
bits will come in a follow-on commit.
Submitted by: Matthew Bryan <matthew.bryan@isilon.com>
Reviewed by: jilles (earlier revision)
Reviewed by: brueffer (manpages, earlier revision)
Relnotes: yes
Sponsored by: Dell EMC Isilon
Differential Revision: https://reviews.freebsd.org/D21423
Described in [1], signal handlers running in a vfork child have
opportunities to corrupt the parent's state. Address this by adding a new
rfork(2) flag, RFSPAWN, that has vfork(2) semantics but also resets signal
handlers in the child during creation.
x86 uses rfork_thread(3) instead of a direct rfork(2) because rfork with
RFMEM/RFSPAWN cannot work when the return address is stored on the stack --
further information about this problem is described under RFMEM in the
rfork(2) man page.
Addressing this has been identified as a prerequisite to using posix_spawn
in subprocess on FreeBSD [2].
[1] https://ewontfix.com/7/
[2] https://bugs.python.org/issue35823
Reviewed by: jilles, kib
Differential Revision: https://reviews.freebsd.org/D19058
When RFSPAWN is passed, rfork exhibits vfork(2) semantics but also resets
signal handlers in the child during creation to avoid a point of corruption
of parent state from the child.
This flag will be used by posix_spawn(3) to handle potential signal issues.
Reviewed by: jilles, kib
Differential Revision: https://reviews.freebsd.org/D19058
memfd_create is effectively a SHM_ANON shm_open(2) mapping with optional
CLOEXEC and file sealing support. This is used by some mesa parts, some
linux libs, and qemu can also take advantage of it and uses the sealing to
prevent resizing the region.
This reimplements shm_open in terms of shm_open2(2) at the same time.
shm_open(2) will be moved to COMPAT12 shortly.
Reviewed by: markj, kib
Differential Revision: https://reviews.freebsd.org/D21393
bde reports (in a reply to r351700 commit mail):
This uses scasb, which was last optimal on the 8086, or perhaps the
original i386. On freefall, it is several times slower than the
naive translation of the naive C code.
Reported by: bde
Reviewed by: kib, markj
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D21785
The two options are
* nocover/cover: Prevent/allow mounting over an existing root mountpoint.
E.g., "mount -t ufs -o nocover /dev/sd1a /usr/local" will fail if /usr/local
is already a mountpoint.
* emptydir/noemptydir: Prevent/allow mounting on a non-empty directory.
E.g., "mount -t ufs -o emptydir /dev/sd1a /usr" will fail.
Neither of these options is intended to be a default, for historical and
compatibility reasons.
Reviewed by: allanjude, kib
Differential Revision: https://reviews.freebsd.org/D21458
calls to max allowed UDP datagram size.
Since max allowed size both for keys and values where increased, the
old sizes of around 1K cause ypmatch(3) failures, while plain maps
fetches work.
The buffers were reduced in r34146 from default UDP rpcclient values
to 1024/2304 due to the key and value size being 1K.
Reviewed by: slavash
Sponsored by: Mellanox Technologies
MFC after: 1 week
Differential revision: https://reviews.freebsd.org/D21586
- Fix the statement that big5 is a de facto standard of Traditional Chinese
text [1]
- Add a BUGS section describes the problem of big5 and suggests use utf8
PR: 189095
Submitted by: Brennan Vincent <brennan@umanwizard.com> [1]
Reviewed by: Ting-Wei Lan <lantw44@gmail.com>
MFC after: 3 days
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D21622
When SO_TIMESTAMP is set, the kernel will attempt to attach a timestamp as
ancillary data to each IP datagram that is received on the socket. However,
it may fail, for example due to insufficient memory. In that case the
packet will still be received but not timestamp will be attached.
Reviewed by: kib
MFC after: 3 days
Differential Revision: https://reviews.freebsd.org/D21607
heap buffer overflow. This was discovered by a Google fuzzer test.
This can lead to remote denial of service. User interaction and
execution privileges are not a prerequisite for exploitation.
Reported by: enh at Google, to FreeBSD by maya@NetBSD.org
Obtained from: enh at Google
See also: NetBSD ns_name.c r1.12
Reviewed by: delphij, ume
MFC after: 3 days
https://android-review.googlesource.com/c/platform/bionic/+/1093130
Differential Revision: https://reviews.freebsd.org/D21523
It allows a process to request that stack gap was not applied to its
stacks, retroactively. Also it is possible to control the gaps in the
process after exec.
PR: 239894
Reviewed by: alc
Sponsored by: The FreeBSD Foundation
Differential revision: https://reviews.freebsd.org/D21352
Previously userspace would issue one syscall to resolve the sysctl and then
another one to actually use it. Do it all in one trip.
Fallback is provided in case newer libc happens to be running on an older
kernel.
Submitted by: Pawel Biernacki
Reported by: kib, brooks
Differential Revision: https://reviews.freebsd.org/D17282
Parentheses added to HASZERO macro to avoid a GCC warning.
Reviewed by: kib, mjg
Obtained from: musl (snapshot at commit 4d0a82170a)
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D17631
The symbol version for _mcount was removed 12 years ago in r169525 from
gmon/Symbol.map, to be added to the per-arch Symbol.map. mips was overlooked
in this, so _mcount has no symver. Add it back to where it should have been,
rather than where it would go if it were added today, since we're correcting
a historical mistake.
Additionally, _mcount is getting thrown into .mdebug.abi32 in the llvm80/90
world as it's not getting explicitly thrown into .text, so do this now. This
fixes the libc build that was previously failing due to relocations in
.mdebug.abi32. This is specifically due to the way clang's integrated AS
works and that they emit the .mdebug.abiNN section early in the process. An
LLVM bug has been submitted[0] and an agreement has been made that the
mips backend should switch to .text following .mdebug.abiNN for
compatibility.
[0] https://bugs.llvm.org/show_bug.cgi?id=43119
Reviewed by: imp, arichardson
MFC after: 1 week
Differential Revision: https://reviews.freebsd.org/D21435
gets is unsafe and shouldn't be used (for many years now). Leave it in
the existing symbol version so anything that previously linked aginst it
still runs, but do not allow new software to link against it.
(The compatability/legacy implementation must not be static so that
the symbol and in particular the compat sym gets@FBSD_1.0 make it
into libc.)
PR: 222796 (exp-run)
Reported by: Paul Vixie
Reviewed by: allanjude, cy, eadler, gnn, jhb, kib, ngie (some earlier)
Relnotes: Yes
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D12298
This unskips:
- lib.libc.stdlib.strtod_test.strtod_round
- lib.msun.fe_round_test.t_nofe_round
In lib/msun/tests/Makefile only define on fe_round_test.c because
lib.msun.ilogb_test.ilogb will get wrong results and needs more examination.
MFC after: 1 week
Sponsored by: The FreeBSD Foundation
machine/regnum.h ends up being included by sys/procfs.h and sys/ptrace.h via
machine/reg.h. Many of the regnum definitions are too short and too generic
to be exposing to any userland application including one of these two
headers. Moreover, these actively cause build failures in googletest
(template <typename T1 ...> expanding to template <typename 9 ...>).
Hide the definitions behind _KERNEL or _WANT_MIPS_REGNUM, and patch all of
the userland consumers to define as needed.
Discussed with: imp, jhb
Reviewed by: imp, jhb
MFC after: 1 week
Differential Revision: https://reviews.freebsd.org/D21330
Although libc syscall wrappers do not get checked in this can aid in
finding the source of generated files when spelunking in the objdir.
Multiple tools use @generated to identify generated files (for example,
in a review Phabricator will by default hide diffs in generated files).
For consistency use the @generated tag in makesyscalls.sh as we've done
for other generated files, even though these wrappers aren't checked in
to the tree.
Use quad.h from libc instead for the time being. This reduces the number of
nearly-identical-quad.h we have in tree to two with only minor changes.
Prototypes for some *sh*di3 have been added to match the copy in libkern.
The differences between the two are likely few enough that they can perhaps
be merged with little additional effort to bring us down to 1.
MFC after: 3 days
Since YP protocol definition uses the constant to declare
variable-size opaque byte strings, the change should be binary
compatible with existing installations which do not expose keys or
values larger than 1024 bytes.
All uses of local variables with YPMAXRECORD sizes were removed to
avoid insane stack use. On the other hand, variables with static
lifetime should be fine and only result in increased VA use.
Glibc made same change, increasing the allowed length for keys and
values in YP to 16M, in 2013.
Reviewed by: markj
Discussed with: ian
Sponsored by: Mellanox Technologies
MFC after: 3 weeks
Differential revision: https://reviews.freebsd.org/D20900
If the length of the source wide character string, passed in via the
"size_t n" parameter, is set to zero, the function should only return
the required length for the destination wide character string. In this
case, it should *not* attempt to write to the destination, so the "dst"
parameter is permitted to be NULL.
However, when the internally called _collate_wxfrm() function returns an
error, such as when using the "C" locale, as a fallback wcscpy(3) or
wcsncpy(3) are used. But if the input length is zero, wcsncpy(3) will
be called with a length of -1! If the "dst" parameter is NULL, this
will immediately result in a segfault, or if "dst" is a valid pointer,
it will most likely result in unexpectedly overwritten memory.
Fix this by explicitly checking for an input length greater than zero,
before calling wcsncpy(3).
Note that a similar situation does not occur in strxfrm(3), the plain
character version of this function, as it uses strlcpy(3) for the error
case. The strlcpy(3) function does not write to the destination if the
input length is zero.
MFC after: 1 week
