These system call wrappers call interposed system calls in fairly
trivial ways. Move them over to libsys so all __libsys_interposer
consumers end up in libsys.
Also move recvmmsg and sendmmsg as they are documented with recv and
send.
Reviewed by: kib, emaste, imp
Pull Request: https://github.com/freebsd/freebsd-src/pull/908
Remove core system call implementations and documentation to lib/libsys
and lib/libsys/<arch> from lib/libc/sys and lib/libc/<arch>/<sys>.
Update paths to allow libc to find them in their new home.
Reviewed by: kib, emaste, imp
Pull Request: https://github.com/freebsd/freebsd-src/pull/908
System calls or their wrappers are now interposed by
__libsys_interposing with purely libc entries remaining in
__libc_interposing.
Use __libsys_interposing_slot in libthr to update __libsys_interposing,
but also make __libc_interposing_slot fall back to
__libsys_interposing_slot so an out of date libc has a chance of working
during updates.
Reviewed by: kib, emaste, imp
Pull Request: https://github.com/freebsd/freebsd-src/pull/908
If the caller didn't use jailparam_import() to fetch the parameter
value, an attempt to export it will trigger a segfault. Make it a bit
easier to figure out what's happening in this situation.
PR: 276809
Reviewed by: jamie
MFC after: 1 week
Differential Revision: https://reviews.freebsd.org/D43732
The way the __fp_type_select macro uses the _Generic expression causes
gcc to throw a warning on valid code if the -Wconversion flag is used.
For example, consider the following program:
#include <math.h>
int main()
{
double x = 1.0;
isnan(x);
return 0;
}
which throws a warning:
$ gcc -Wconversion a.c
a.c:5:15: warning: conversion from 'double' to 'float' may change value [-Wfloat-conversion]
5 | isnan(x);
| ^
This happens because the functions are invoked inside of the _Generic.
Looking at the example of _Generic in the C11 specification, one sees
that the parameters are outside of the _Generic expression (see page 79
here: https://www.open-std.org/jtc1/sc22/wg14/www/docs/n1570.pdf).
Reference: https://stackoverflow.com/a/68309379
Signed-off-by: Martin Oliveira <martin.oliveira@eideticom.com>
Reviewed by: imp
Pull Request: https://github.com/freebsd/freebsd-src/pull/841
Add missing documentation for sctp_sendv(3) and sctp_recvv(3).
Add a note that sctp_send(3), sctp_sendx(3) and sctp_recvmsg(3) are
deprecated by RFC 6458.
Add a STANDARDS section to all functions specified in RFC 6458 to
indicate their standards conformance.
MFC after: 2 weeks
Reviewed by: imp, bcr, kp, tuexen
Pull Request: https://github.com/freebsd/freebsd-src/pull/965
computejumps() moves g->charjump to a position relativ to the value of
CHAR_MIN. As such, g->charjump doesn't necessarily point to the address
actually allocated. While regfree() takes that into account, the low
memory handling in regcomp_internal() doesn't. Fix that by free'ing
the actually allocated address, as in regfree().
MFC After: 2 weeks
Reviewed by: imp,jrtc27
Pull Request: https://github.com/freebsd/freebsd-src/pull/692
Add _SYSCALL_BODY() macro which invokes the syscall via _SYCALL() and
calls cerror as required. Use to implement PSEUDO() and RSYSCALL().
Sponsored by: DARPA
Differential Revision: https://reviews.freebsd.org/D43058
Otherwise the lock upgrade performed by rtld's load_filtees() can result
in infinite recursion, wherein:
1. _rtld_bind() acquires the bind read lock,
2. the source DSO's filtees haven't been loaded yet, so the lock upgrade
in load_filtees() cause rtld to jump to _rtld_bind() and release the
bind lock,
3. _thr_rtld_lock_release() calls _thr_ast(), which calls thr_wake(),
which hasn't been resolved yet,
4. _rtld_bind() acquires the bind read lock in order to resolve
thr_wake(),
5. ...
See the linked pull request for an instance of this problem arising with
libsys. That particular instance is also worked around by commit
e7951d0b04.
Reported by: brooks
Reviewed by: kib
Pull Request: https://github.com/freebsd/freebsd-src/pull/908
MFC after: 1 week
Sponsored by: Innovate UK
__FreeBSD_version is recorded in *crt1.o and crti.o via crtbrand.o. Add
an explicit dependency to pick up __FreeBSD_version bumps.
Additional changes are required to fully plumb *crt1.o dependencies
through the build.
Reported by: bapt
Reviewed by: bapt
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D43417
This is an implementation detail which is likely to become irrelevant in
the future, as we move to not resetting the priority if the
corresponding capability is not present in the configuration file
('/etc/login.conf').
GitHub's code search and Google show no use of this public constant, and
it doesn't exist in OpenBSD and NetBSD.
So, remove this definition and its sole use in-tree.
PR: 276570 (exp-run)
Reviewed by: emaste
Approved by: emaste (mentor)
MFC after: 3 days
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D43609
This public constant has not been used in-tree since 1997 (this was
noticed while working on previous commit "setusercontext(): umask: Set
it only once (in the common case)").
Since it was an implementation detail and GitHub's code search and
Google show no use of this symbol today, simply remove it.
PR: 276570 (exp-run)
Reviewed by: emaste, kib (earlier version, then part of D40344)
Approved by: emaste (mentor)
MFC after: 3 days
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D43608
Setting the process priority is done only when the current process'
effective UID corresponds to that for which context is to be set.
Consequently, setting priority is done with appropriate credentials and
will fail if the target user tries to raise it unduly via his
'~/.login_conf'.
PR: 271751
Reviewed by: kib, Andrew Gierth <andrew_tao173.riddles.org.uk>
Approved by: emaste (mentor)
MFC after: 3 days
Relnotes: yes
Sponsored by: Kumacom SAS
Differential Revision: https://reviews.freebsd.org/D40352
It indicates to the login.conf machinery (setusercontext() /
setclasscontext()) to leave priority alone, effectively inheriting it
from the parent process.
PR: 271749
Reviewed by: emaste, yuripv
Approved by: emaste (mentor)
MFC after: 3 days
Relnotes: yes
Sponsored by: Kumacom SAS
Differential Revision: https://reviews.freebsd.org/D40690
In preparation for setting priorities from '~/.login_conf' and to ease
reading of setusercontext().
No functional change.
Reviewed by: emaste
Approved by: emaste (mentor)
MFC after: 3 days
Sponsored by: Kumacom SAS
Differential Revision: https://reviews.freebsd.org/D40350
Priority is reset to 0 if not explicitly specified.
While here, be more explicit about what "Initial priority (nice) level"
means and document that it is possible to set real-time or idle class'
priorities with this capability.
Reviewed by: emaste
Approved by: emaste (mentor)
MFC after: 3 days
Sponsored by: Kumacom SAS
Differential Revision: https://reviews.freebsd.org/D40689
Polish the syslog messages to contain readily useful information.
Behavior of capability 'priority' is inconsistent with what is done for
all other contexts: 'umask', 'cpumask', resource limits, etc., where an
absence of capability means to inherit the value. It is currently
preserved for compatibility, but is subject to change on a future major
release.
Reviewed by: emaste, kib (older version)
Approved by: emaste (mentor)
MFC after: 3 days
Sponsored by: Kumacom SAS
Differential Revision: https://reviews.freebsd.org/D40349
Column "Notes" in fact only contains default values for capabilities, so
make this clear by renaming it to "Default".
Add a small introductory text mentioning it, and what an absence of
default value means (inheritance).
PR: 271748
Reviewed by: emaste
Approved by: emaste (mentor)
MFC after: 3 days
Sponsored by: Kumacom SAS
Differential Revision: https://reviews.freebsd.org/D40347
Remove indentation by inverting the big 'if (lc)' and using 'return'.
Use explicit binary operators to produce booleans.
Reviewed by: emaste, kib, dchagin
Approved by: emaste (mentor)
MFC after: 3 days
Sponsored by: Kumacom SAS
Differential Revision: https://reviews.freebsd.org/D40346
'inherit' explicitly indicates that the umask should not be changed.
Reviewed by: emaste
Approved by: emaste (mentor)
MFC after: 3 days
Relnotes: yes
Sponsored by: Kumacom SAS
Differential Revision: https://reviews.freebsd.org/D40687
The umask is simply left unchanged if no explicit value is specified in
the login class capabilities database.
PR: 271747
Reviewed by: emaste
Approved by: emaste (mentor)
MFC after: 3 days
Sponsored by: Kumacom SAS
Differential Revision: https://reviews.freebsd.org/D40345
Simplify the code and make it more coherent (umask was the only context
setting not modified by setlogincontext() directly).
Preserve the current behavior of not changing the umask if none is
specified in the login class capabilities database, but without the
superfluous umask() dance. (The only exception to this is that
a special value no user is likely to input in the database now stands
for no specification.)
If some user has a 'umask' override in its '~/.login_conf', the umask
will still be set twice as before (as is the case for all other context
settings overriden in '~/.login_conf').
Log a warning in case of an invalid umask specification.
This change makes it apparent that the value of LOGIN_DEFUMASK doesn't
matter. It will be removed in a subsequent commit.
PR: 271747
Reviewed by: emaste, kib (earlier version)
Approved by: emaste
MFC after: 3 days
Sponsored by: Kumacom SAS
Differential Revision: https://reviews.freebsd.org/D40344
and move the BUGS paragraph about dirfd permissions into STANDARDS
section, noting that we provide POSIX-mandated implementation.
Reviewed by: emaste, kevans
Sponsored by: The FreeBSD Foundation
MFC after: 3 days
Differential revision: https://reviews.freebsd.org/D43652
When a temporary/bootonce boot environment is renamed, we need to also
update the bootenv nvlist on-disk to reflect the new name. Additionally,
when a temporary/bootonce boot environment is destroyed, we also need to
clear out the on-disk state.
Reviewed by: kevans
Approved by: kp
MFC after: 1 week
Sponsored by: Rubicon Communications, LLC ("Netgate")
Differential Revision: https://reviews.freebsd.org/D43591
The code in this file runs before the sanitizer can initialize its
shadow map.
Fixes: ad2fac552c ("lib/libc/amd64: add archlevel-based simd dispatch framework")
This is another part of fixing the WITH_ASAN build. Some additional
source files had to be added to libllvm and liblldb, since the ASan
instrumentation causes symbols in those files to be referenced.
Reported by: markj
PR: 276597
MFC after: 3 days
We have s_fabs.c, but fabs(3) is already provided by libc due to
historical reasons, so it is not compiled into libm. When the linker
does not use --undefined-version, this leads to a complaint about the
symbol being nonexistent, so remove it from Symbol.map.
While here, adjust the comment about some functions being supplied by
libc: while it is true that all these are indeed in libc, libm still
includes its own versions of frexp(3), isnan(3), isnanf(3), and
isnanl(3).
Reported by: Steve Kargl <sgk@troutmask.apl.washington.edu>
MFC after: 3 days
The section INTERNET ADDRESSES describes the acceptance of dotted
values with varying number of parts in multiple bases. This applies
to inet_aton and inet_addr, but not to inet_pton. Clarify this
section by listing the functions to which this applies. Move the
description of what inet_pton accepts into this section from STANDARDS,
where it is easily missed. Rename the section to clarify that it
applies only to IPv4. (inet_pton also works with IPv6.)
Reviewed by: imp
Differential Revision: https://reviews.freebsd.org/D43537
In the errno list, add an explicit note and reference to the note in the
STANDARDS section.
When O_NOFOLLOW is specified and the target is a symbolic link FreeBSD
sets errno to a value different than that specified by POSIX. Commit
295159dfa3 added a note to this effect, but I missed it when reading
through the list of errno values.
PR: 214633
Reviewed by: markj
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D43618
Unlike Linux, we do provide libc wrapper. All definitions and
prototypes are available from <unistd.h>
Tested by: manu
Reviewed by: brooks, markj
Sponsored by: The FreeBSD Foundation
MFC after: 1 week
Differential revision: https://reviews.freebsd.org/D43518
Move ncurses_dll.h to GENHDRS to start with; it's been generated from
ncurses_dll.h.in for years, so it's not actually in a different category
than all of the other GENHDRS. Slap an .ORDER on it to ensure that we
build ncurses_dll.h and curses.h before any *.c gets compiled.
This should sufficiently address a build race seen downstream where
ncurses_dll.h is present but not yet populated.
Reviewed by: bapt
Sponsored by: NetApp, Inc.
Sponsored by: Klara, Inc.
Differential Revision: https://reviews.freebsd.org/D43540
