summaryrefslogtreecommitdiff
path: root/lib/libc
Commit message (Collapse)AuthorAgeFilesLines
* MFC r355940:Dimitry Andric2020-05-051-1/+1
| | | | | | | | | | | | | | | Move all sources from the llvm project into contrib/llvm-project. This uses the new layout of the upstream repository, which was recently migrated to GitHub, and converted into a "monorepo". That is, most of the earlier separate sub-projects with their own branches and tags were consolidated into one top-level directory, and are now branched and tagged together. Updating the vendor area to match this layout is next. Notes: svn path=/stable/11/; revision=360660
* MFC r359118: Fix race condition in catopen(3).Xin LI2020-05-011-20/+37
| | | | Notes: svn path=/stable/11/; revision=360522
* MFC r359978:Brooks Davis2020-04-277-41/+41
| | | | | | | | | | | | | | | | | | Fix -Wvoid-pointer-to-enum-cast warnings. This pattern is used in callbacks with void * data arguments and seems both relatively uncommon and relatively harmless. Silence the warning by casting through uintptr_t. This warning is on by default in Clang 11. Reviewed by: arichardson Obtained from: CheriBSD (partial) Sponsored by: DARPA Differential Revision: https://reviews.freebsd.org/D24425 Notes: svn path=/stable/11/; revision=360415
* MFC r360182-r360183: kqueue(2): add note about EV_RECEIPTKyle Evans2020-04-271-1/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | r360182: kqueue(2): add a note about EV_RECEIPT In the below-referenced PR, a case is attached of a simple reproducer that exhibits suboptimal behavior: EVFILT_READ and EVFILT_WRITE being set in the same kevent(2) call will only honor the first one. This is, in-fact, how it's supposed to work. A read of the manpage leads me to believe we could be more clear about this; right now there's a logical leap to make in the relevant statement: "When passed as input, it forces EV_ERROR to always be returned." -- the logical leap being that this indicates the caller should have allocated space for the change to be returned with EV_ERROR indicated in the events, or subsequent filters will get dropped on the floor. Another possible workaround that accomplishes similar effect without needing space for all events is just setting EV_RECEIPT on the final change being passed in; if any errored before it, the kqueue would not be drained. If we made it to the final change with EV_RECEIPT set, then we would return that one with EV_ERROR and still not drain the kqueue. This would seem to not be all that advisable. r360183: kqueue(2): de-vandalize the random sentence in the middle A last minute change appears to have inadvertently vandalized unrelated parts of the manpage with the date. =-( PR: 229741 Notes: svn path=/stable/11/; revision=360406
* MFC 360284:Mateusz Piotrowski2020-04-271-2/+2
| | | | | | | | | Fix a typo Reported by: pstef Notes: svn path=/stable/11/; revision=360370
* MFC r359183:Mark Johnston2020-04-031-1/+1
| | | | | | | | | Fix uselocale(3) to not leak a reference to the old locale. PR: 239520 Notes: svn path=/stable/11/; revision=359584
* MFC r355488-r355489Alan Somers2020-03-222-2/+15
| | | | | | | | | | | r355488: lio_listio(2): add a HISTORY section r355489: clock_gettime(2): add a HISTORY section Notes: svn path=/stable/11/; revision=359206
* MFC r352231:Alan Somers2020-03-211-2/+3
| | | | | | | | | | | | | | | getsockopt.2: clarify that SO_TIMESTAMP is not 100% reliable 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 Differential Revision: https://reviews.freebsd.org/D21607 Notes: svn path=/stable/11/; revision=359196
* MFC 358674, 358916:Mateusz Piotrowski2020-03-191-1/+61
| | | | | | | | | | | | | | | | | | | ftw.3: Add examples PR: 173448 [1] Submitted by: fernape@ (previous version) [1] Reviewed by: jilles Approved by: bcr (mentor) Differential Revision: https://reviews.freebsd.org/D21750 ftw.3: Follow style(9) in the example Reported by: oshogbo Approved by: bcr (mentor) Differential Revision: https://reviews.freebsd.org/D24043 Notes: svn path=/stable/11/; revision=359128
* MFC r358675: umtx_op.2: correct typoEd Maste2020-03-081-1/+1
| | | | | | | PR: 244611 Notes: svn path=/stable/11/; revision=358743
* MFC r358046:Dimitry Andric2020-02-219-17/+17
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Merge r358042 from the clang1000-import branch: Add casts and L suffixes to libc quad support, to work around various -Werror warnings from clang 10.0.0, such as: lib/libc/quad/fixdfdi.c:57:12: error: implicit conversion from 'long long' to 'double' changes value from 9223372036854775807 to 9223372036854775808 [-Werror,-Wimplicit-int-float-conversion] if (x >= QUAD_MAX) ~~ ^~~~~~~~ /usr/obj/usr/src/powerpc.powerpc/tmp/usr/include/sys/limits.h:89:19: note: expanded from macro 'QUAD_MAX' #define QUAD_MAX (__QUAD_MAX) /* max value for a quad_t */ ^~~~~~~~~~ /usr/obj/usr/src/powerpc.powerpc/tmp/usr/include/machine/_limits.h:91:20: note: expanded from macro '__QUAD_MAX' #define __QUAD_MAX __LLONG_MAX /* max value for a quad_t */ ^~~~~~~~~~~ /usr/obj/usr/src/powerpc.powerpc/tmp/usr/include/machine/_limits.h:75:21: note: expanded from macro '__LLONG_MAX' #define __LLONG_MAX 0x7fffffffffffffffLL /* max value for a long long */ ^~~~~~~~~~~~~~~~~~~~ and many instances of: lib/libc/quad/fixunsdfdi.c:73:17: error: shift count >= width of type [-Werror,-Wshift-count-overflow] toppart = (x - ONE_HALF) / ONE; ^~~~~~~~ lib/libc/quad/fixunsdfdi.c:45:19: note: expanded from macro 'ONE_HALF' #define ONE_HALF (ONE_FOURTH * 2.0) ^~~~~~~~~~ lib/libc/quad/fixunsdfdi.c:44:23: note: expanded from macro 'ONE_FOURTH' #define ONE_FOURTH (1 << (LONG_BITS - 2)) ^ ~~~~~~~~~~~~~~~ lib/libc/quad/fixunsdfdi.c:73:29: error: shift count >= width of type [-Werror,-Wshift-count-overflow] toppart = (x - ONE_HALF) / ONE; ^~~ lib/libc/quad/fixunsdfdi.c:46:15: note: expanded from macro 'ONE' #define ONE (ONE_FOURTH * 4.0) ^~~~~~~~~~ lib/libc/quad/fixunsdfdi.c:44:23: note: expanded from macro 'ONE_FOURTH' #define ONE_FOURTH (1 << (LONG_BITS - 2)) ^ ~~~~~~~~~~~~~~~ Notes: svn path=/stable/11/; revision=358230
* MFC r357576:Mark Johnston2020-02-191-80/+79
| | | | | | | | | Fix a use of an uninitialized pointer in xdr_rpcbs_rmtcalllist(). PR: 243759 Notes: svn path=/stable/11/; revision=358122
* MFC r357284, r357419: stdio unlockedKyle Evans2020-02-1311-19/+117
| | | | | | | | | | | | | | | | | | | | | | | r357284: stdio: provide _unlocked variants of fflush, fputc, fputs, fread, fwrite fflush_unlocked is currently desired in ports by sysutils/metalog, and redefined as the locked fflush. fputc_unlocked, fputs_unlocked, fread_unlocked, and fwrite_unlocked are currently desired in ports by devel/elfutils, and redefined as the locked fputs, fread, and fwrite respectively. r357419: libc: provide fputc_unlocked Among the same justification as the other stdio _unlocked; in addition to an inline version in <stdio.h>, we must provide a function in libc as well for the functionality. This fixes the lang/gcc* builds, which want to use the symbol from libc. Notes: svn path=/stable/11/; revision=357852
* MFC r327181: fsync(3): correctly document return valuesKyle Evans2020-02-131-5/+8
| | | | | | | | In r268924 the behavior of fflush was changed to return success on read only streams. Document this. Notes: svn path=/stable/11/; revision=357851
* MFC r356942:Brooks Davis2020-02-121-2/+1
| | | | | | | | | | | Correct a misleading indent. This dates to before the beginning of our repo and was found by clang 10. Sponsored by: DARPA Notes: svn path=/stable/11/; revision=357837
* MFC O_SEARCH: r357412, r357461, r357580, r357584, r357636, r357671, r357688Kyle Evans2020-02-092-5/+21
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | r357412: Provide O_SEARCH O_SEARCH is defined by POSIX [0] to open a directory for searching, skipping permissions checks on the directory itself after the initial open(). This is close to the semantics we've historically applied for O_EXEC on a directory, which is UB according to POSIX. Conveniently, O_SEARCH on a file is also explicitly undefined behavior according to POSIX, so O_EXEC would be a fine choice. The spec goes on to state that O_SEARCH and O_EXEC need not be distinct values, but they're not defined to be the same value. This was pointed out as an incompatibility with other systems that had made its way into libarchive, which had assumed that O_EXEC was an alias for O_SEARCH. This defines compatibility O_SEARCH/FSEARCH (equivalent to O_EXEC and FEXEC respectively) and expands our UB for O_EXEC on a directory. O_EXEC on a directory is checked in vn_open_vnode already, so for completeness we add a NOEXECCHECK when O_SEARCH has been specified on the top-level fd and do not re-check that when descending in namei. [0] https://pubs.opengroup.org/onlinepubs/9699919799/ r357461: namei: preserve errors from fget_cap_locked Most notably, we want to make sure we don't clobber any capabilities-related errors. This is a regression from r357412 (O_SEARCH) that was picked up by the capsicum tests. r357580: O_SEARCH test: drop O_SEARCH|O_RDWR local diff In FreeBSD's O_SEARCH implementation, O_SEARCH in conjunction with O_RDWR or O_WRONLY is explicitly rejected. In this case, O_RDWR was not necessary anyways as the file will get created with or without it. This was submitted upstream as misc/54940 and committed in rev 1.8 of the file. r357584: Record-only MFV of r357583: netbsd-tests: import upstreamed changes The changes in question originated in FreeBSD/head; no further action is required. r357636: MFV r357635: imnport v1.9 of the O_SEARCH tests The RCSID data was wrong, so this is effectively a record-only merge with correction of said data. No further changes should be needed in this area, as we've now upstreamed our local changes to this specific test. r357671: O_SEARCH test: mark revokex an expected fail on NFS The revokex test does not work when the scratch directory is created on NFS. Given the nature of NFS, it likely can never work without looking like a security hole since O_SEARCH would rely on the server knowing that the directory did have +x at the time of open and that it's OK for it to have been revoked based on POSIX specification for O_SEARCH. This does mean that O_SEARCH is only partially functional on NFS in general, but I suspect the execute bit getting revoked in the process is likely not common. r357688: MFV r357687: Import NFS fix for O_SEARCH tests The version that ended upstream was ultimately slightly different than the version committed here; notably, statvfs() is used but it's redefined appropriately to statfs() on FreeBSD since we don't provide the fstypename for the former interface. Notes: svn path=/stable/11/; revision=357706
* MFC 356951: posix_spawn: mark error as volatileKyle Evans2020-01-241-1/+1
| | | | | | | | | | | | | | | | In the case of an error, the RFSPAWN'd thread will write back to psa->error with the correct exit code. Mark this as volatile as the return value is being actively dorked up for erroneous exits on !x86. This fixes the following tests, tested on aarch64 (only under qemu, at the moment): - posix_spawn/spawn_test:t_spawn_missing - posix_spawn/spawn_test:t_spawn_nonexec - posix_spawn/spawn_test:t_spawn_zero Notes: svn path=/stable/11/; revision=357089
* MFC r324815: Make elf_aux_info() as public libc function.Kyle Evans2020-01-132-1/+30
| | | | | | | | | | | | | | | | | - Teach elf aux vector functions about newly added AT_HWCAP and AT_HWCAP2 vectors. - Export _elf_aux_info() as new public libc function elf_aux_info(3) The elf_aux_info(3) should be considered as FreeBSD counterpart of glibc getauxval() with more robust interface. Note: We cannot name this new function as getauxval(), with glibc compatible interface. Some ports autodetect its existence and then expects that all Linux specific AT_<*> vectors are defined and implemented. Notes: svn path=/stable/11/; revision=356674
* MFC r356355: ssp: knock out some trivial warnings that come up with WARNS=6Kyle Evans2020-01-111-3/+5
| | | | | | | | | | | A future commit will rebuild this as part of libssp. The exact warnings are fairly trivially fixed: - No previous declaration for __stack_chk_guard - idx is the wrong type, nitems yields a size_t - Casting away volatile on the tmp_stack_chk_guard directly is a no-no. Notes: svn path=/stable/11/; revision=356626
* MFC r336746, r336779Ian Lepore2020-01-074-26/+23
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | r336746: Make pw_scan(3) more compatible with getpwent(3) et. al. when processing data from /etc/passwd rather than /etc/master.passwd. The libc getpwent(3) and related functions automatically read master.passwd when run by root, or passwd when run by a non-root user. When run by non- root, getpwent() copes with the missing data by setting the corresponding fields in the passwd struct to known values (zeroes for numbers, or a pointer to an empty string for literals). When libutil's pw_scan(3) was used to parse a line without the root-accessible data, it was leaving garbage in the corresponding fields. These changes rename the static pw_init() function used by getpwent() and friends to __pw_initpwd(), and move it into pw_scan.c so that common init code can be shared between libc and libutil. pw_scan(3) now calls __pw_initpwd() before __pw_scan(), just like the getpwent() family does, so that reading an arbitrary passwd file in either format and parsing it with pw_scan(3) returns the same results as getpwent(3) would. This also adds a new pw_initpwd(3) function to libutil, so that code which creates passwd structs from scratch in some manner that doesn't involve pw_scan() can initialize the struct to the values expected by lots of existing code, which doesn't expect to encounter NULL pointers or garbage values in some fields. r336779: Stop exporting __pw_scan and __pw_initpwd as freebsd-private libc functions for use in libutil, and instead compile the small amount of common code directly into libutil with a .PATH reachover. Notes: svn path=/stable/11/; revision=356461
* MFC r340383: Create namespace for the symbols added during 13-CURRENT cycle.Kyle Evans2019-12-191-1/+4
| | | | | | | Pointy hat to: kevans Notes: svn path=/stable/11/; revision=355901
* Add sigsetop extensions commonly found in musl libc and glibcKyle Evans2019-12-196-4/+285
| | | | | | | | | | These functions (sigandset, sigisemptyset, sigorset) are commonly available in at least musl libc and glibc; sigorset, at least, has proven quite useful in qemu-bsd-user work for tracking the current process signal mask in a more self-documenting/aesthetically pleasing manner. Notes: svn path=/stable/11/; revision=355898
* MFC r354669, r354672, r354689: move __stack_chk_guard constructorKyle Evans2019-11-251-1/+19
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | r354669: ssp: add a priority to the __stack_chk_guard constructor First, this commit is a NOP on GCC <= 4.x; this decidedly doesn't work cleanly on GCC 4.2, and it will be gone soon anyways so I chose not to dump time into figuring out if there's a way to make it work. xtoolchain-gcc, clocking in as GCC6, can cope with it just fine and later versions are also generally ok with the syntax. I suspect very few users are running GCC4.2 built worlds and also experiencing potential fallout from the status quo. For dynamically linked applications, this change also means very little. rtld will run libc ctors before most others, so the situation is approximately a NOP for these as well. The real cause for this change is statically linked applications doing almost questionable things in their constructors. qemu-user-static, for instance, creates a thread in a global constructor for their async rcu callbacks. In general, this works in other places- - On OpenBSD, __stack_chk_guard is stored in an .openbsd.randomdata section that's initialized by the kernel in the static case, or ld.so in the dynamic case - On Linux, __stack_chk_guard is apparently stored in TLS and such a problem is circumvented there because the value is presumed stable in the new thread. On FreeBSD, the rcu thread creation ctor and __guard_setup are both unmarked priority. qemu-user-static spins up the rcu thread prior to __guard_setup which starts making function calls- some of these are sprinkled with the canary. In the middle of one of these functions, __guard_setup is invoked in the main thread and __stack_chk_guard changes- qemu-user-static is promptly terminated for an SSP violation that didn't actually happen. This is not an all-too-common problem. We circumvent it here by giving the __stack_chk_guard constructor a solid priority. 200 was chosen because that gives static applications ample range (down to 101) for working around it if they really need to. I suspect most applications will "just work" as expected- the default/non-prioritized flavor of __constructor__ functions run last, and the canary is generally not expected to change as of this point at the very least. This took approximately three weeks of spare time debugging to pin down. r354672: ssp: rework the logic to use priority=200 on clang builds The preproc logic was added at the last minute to appease GCC 4.2, and kevans@ did clearly not go back and double-check that the logic worked out for clang builds to use the new variant. It turns out that clang defines __GNUC__ == 4. Flip it around and check __clang__ as well, leaving a note to remove it later. r354689: ssp: further refine the conditional used for constructor priority __has_attribute(__constructor__) is a better test for clang than defined(__clang__). Switch to it instead. While we're already here and touching it, pfg@ nailed down when GCC actually introduced the priority argument -- 4.3. Use that instead of our hammer-guess of GCC >= 5 for the sake of correctness. PR: 241905 Notes: svn path=/stable/11/; revision=355080
* MFC r354255:Dimitry Andric2019-11-101-0/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Add __isnan()/__isnanf() aliases for compatibility with glibc and CUDA 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 Notes: svn path=/stable/11/; revision=354596
* MFC r352711-r352712: Address posix_spawn(3) signal issuesKyle Evans2019-10-212-30/+115
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | r352711: rfork(2): add RFSPAWN flag 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 r352712: posix_spawn(3): handle potential signal issues with vfork 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 Notes: svn path=/stable/11/; revision=353789
* MFC r353326:Brooks Davis2019-10-154-8/+8
| | | | | | | | | | | | | | | | | | | | | | Fix various -Wpointer-compare warnings 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 Notes: svn path=/stable/11/; revision=353589
* MFC r352315:Li-Wen Hsu2019-09-271-2/+9
| | | | | | | | | | | | | | | | | Improve the description of big5(5) - 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> Sponsored by: The FreeBSD Foundation Differential Revision: https://reviews.freebsd.org/D21622 Notes: svn path=/stable/11/; revision=352794
* MFC r352455:Konstantin Belousov2019-09-241-1/+6
| | | | | | | | | Return EISDIR when directory is opened with O_CREAT without O_DIRECTORY. PR: 240452 Notes: svn path=/stable/11/; revision=352645
* MFC r352384:Konstantin Belousov2019-09-231-1/+1
| | | | | | | | | | Increase the size of the send and receive buffers for YP client rpc calls to max allowed UDP datagram size. Sponsored by: Mellanox Technologies Notes: svn path=/stable/11/; revision=352616
* MFC r352048:Mitchell Horne2019-09-161-1/+1
| | | | | | | Fix cpuwhich_t column width Notes: svn path=/stable/11/; revision=352429
* MFC r352127:Baptiste Daroussin2019-09-133-8/+7
| | | | | | | | In FreeBSD 11 localedef(1) has replaced the mklocale(1) and colldef(1) tools to generate the locales data. state it in the libc manpages. Notes: svn path=/stable/11/; revision=352283
* MFC r351773:Konstantin Belousov2019-09-101-1/+62
| | | | | | | | | Add procctl(PROC_STACKGAP_CTL). PR: 239894 Notes: svn path=/stable/11/; revision=352125
* MFC r351681: mips: fix some mcount nitsKyle Evans2019-09-091-0/+1
| | | | | | | | | | | | | | | | | | | | 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 (and since committed) and an agreement has been made that the mips backend should switch to .text following .mdebug.abiNN for compatibility. Notes: svn path=/stable/11/; revision=352083
* MFC r351889:Cy Schubert2019-09-081-2/+2
| | | | | | | | | | | | | | | | | | Bounds check again after advancing cp, otherwise we have a possible 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 Notes: svn path=/stable/11/; revision=352027
* MFC r351408-r351410: reduce pollution from mips machine/regnum.hKyle Evans2019-09-034-3/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | r351408: libsa: mips: use _JB_* from machine/asm.h, remove regnum dep This brings the libsa/mips _setjmp implementation closer to parity with the libc version. r351409: mips: hide regnum definitions behind _KERNEL/_WANT_MIPS_REGNUM 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. r351410: libsa: mips: fix typo that had slipped into the diff on local machine Notes: svn path=/stable/11/; revision=351792
* MFC r351407: libc: mips: remove unused longjmp.cKyle Evans2019-09-031-103/+0
| | | | Notes: svn path=/stable/11/; revision=351791
* MFC r350957:Konstantin Belousov2019-09-024-13/+30
| | | | | | | | | Increase YPMAXRECORD to 16M to be compatible with Linux. Sponsored by: Mellanox Technologies Notes: svn path=/stable/11/; revision=351694
* MFC r350697:Dimitry Andric2019-08-141-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | Fix a possible segfault in wcsxfrm(3) and wcsxfrm_l(3). 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. Notes: svn path=/stable/11/; revision=351041
* MFC r350861:Konstantin Belousov2019-08-141-3/+8
| | | | | | | wait(2): clarify reparenting of children of the exiting process. Notes: svn path=/stable/11/; revision=351016
* MFC r350860:Konstantin Belousov2019-08-141-1/+7
| | | | | | | wait(2): split long line by using .Fo/.Fa instead of .Ft. Notes: svn path=/stable/11/; revision=351014
* MFC r350160:Brooks Davis2019-08-021-1/+1
| | | | | | | | | | | | | | | Avoid copying too much from the input string. This avoids reading past the end of the static strings. On a system with bounds checking these tests fault. Reviewed by: asomers Obtained from: CheriBSD Sponsored by: DARPA, AFRL Differential Revision: https://reviews.freebsd.org/D21004 Notes: svn path=/stable/11/; revision=350539
* MFC r350117:Brooks Davis2019-07-251-2/+2
| | | | | | | | | | | | Include a mode when creating files with openat(). Reviewed by: asomers Obtained from: CheriBSD Sponsored by: DARPA, AFRL Differential Revision: https://reviews.freebsd.org/D20989 Notes: svn path=/stable/11/; revision=350334
* MFC r350116:Brooks Davis2019-07-251-1/+8
| | | | | | | | | | | | | | | Document that setmode(3) is not thread safe. In some circumstances, setmode(3) may call umask(2) twice to retrieve the current mode and then restore it. Between calls, the process will have a umask of 0. Reviewed by: markj Sponsored by: DARPA, AFRL Differential Revision: https://reviews.freebsd.org/D20982 Notes: svn path=/stable/11/; revision=350330
* MFC r350102:Brooks Davis2019-07-241-1/+0
| | | | | | | | | | Remove redundent decleration of __elf_phdr_match_addr(). Obtained from: CheriBSD Sponsored by: DARPA, AFRL Notes: svn path=/stable/11/; revision=350305
* MFC r347617 (by bcr), r350091:Konstantin Belousov2019-07-241-1/+65
| | | | | | | Add an example to bsearch.3. Notes: svn path=/stable/11/; revision=350273
* MFC r349041:Alan Somers2019-07-191-5/+2
| | | | | | | | | | | | | | | | | | | | | open(2): fix the description of O_FSYNC The man page claims that with O_FSYNC (aka O_SYNC) the kernel will not cache written data. However, that's not true. Nor does POSIX require it. Perhaps it was true when that section of the man page was written in r69336 (I haven't checked). But it's not true now. Now the effect is simply that writes are sent to disk immediately and synchronously, but they're still cached. See also: https://pubs.opengroup.org/onlinepubs/9699919799/ See also: ffs_write in sys/ufs/ffs/ffs_vnops.c Reviewed by: cem Sponsored by: The FreeBSD Foundation Differential Revision: https://reviews.freebsd.org/D20641 Notes: svn path=/stable/11/; revision=350125
* MFC r349794:Konstantin Belousov2019-07-091-1/+20
| | | | | | | Document atomicity for read(2) and write(2). Notes: svn path=/stable/11/; revision=349855
* MFC r349299:Konstantin Belousov2019-07-033-0/+4
| | | | | | | | | Add libc stub for pthread_getthreadid_np(3). PR: 238650 Notes: svn path=/stable/11/; revision=349688
* MFC r349297:Konstantin Belousov2019-07-031-3/+2
| | | | | | | Remove redundand 'else' and 'return'. Notes: svn path=/stable/11/; revision=349678
* MFC r349619: libc: correct iconv buffer overflowEd Maste2019-07-031-1/+1
| | | | | | | | | | | | admbugs: 920 Submitted by: Andrea Venturoli, gabor Reported by: Andrea Venturoli <security@netfence.it>, NetFence Approved by: so Security: CVE-2019-5600 Security: FreeBSD-SA-19:09.iconv Notes: svn path=/stable/11/; revision=349624
generated by cgit v1.2.3 (git 2.25.1) at 2025-08-21 18:19:53 +0000