On success gnu libc sched_getaffinity() should return 0, unlike underlying
Linux syscall which returns the size of CPU mask copied to user.
PR: 263939
MFC after: 2 weeks
Linux has more tolerant checks of the user supplied cpuset_t's.
Minimum cpuset_t size that the Linux kernel permits in case of
getaffinity() is the maximum CPU id, present in the system / NBBY,
the maximum size is not limited.
For setaffinity(), Linux does not limit the size of the user-provided
cpuset_t, internally using only the meaningful part of the set, where
the upper bound is the maximum CPU id, present in the system, no larger
than the size of the kernel cpuset_t.
Unlike FreeBSD, Linux ignores high bits if set in the setaffinity(),
so clear it in the sched_setaffinity() and Linuxulator itself.
Reviewed by: Pau Amma (man pages)
In collaboration with: jhb
Differential revision: https://reviews.freebsd.org/D34849
MFC after: 2 weeks
There are some sections which could be improved
and work to do so is on going. The work will be
covered via 'X-MFC-WITH' commits.
Obtained from: OpenBSD
MFC after: 1 month
Differential Revision: https://reviews.freebsd.org/D34759
The time() system call first appeared in Version 1 AT&T UNIX. Through
the Version 3 AT&T UNIX, it returned 60 Hz ticks since an epoch that
changed occasionally, because it was a 32-bit value that overflowed in a
little over 2 years.
In Version 4 AT&T UNIX the granularity of the return value was reduced to
whole seconds, delaying the aforementioned overflow until 2038.
Version 7 AT&T UNIX introduced the ftime() system call, which returned
time at a millisecond level, though retained the gtime() system call
(exposed as time() in userland). time() could have been implemented as a
wrapper around ftime(), but that wasn't done.
4.1cBSD implemented a higher-precision time function gettimeofday() to
replace ftime() and reimplemented time() in terms of that.
Since FreeBSD 9 the implementation of time() uses
clock_gettime(CLOCK_SECOND) instead of gettimeofday() for performance
reasons.
With most valuable input from Warner (imp@).
Reviewed by: 0mp, jilles, imp
MFC after: 1 week
Differential Revision: https://reviews.freebsd.org/D34751
Previously, such errors were not distinguished from the end-of-directory
condition.
With improvements from Mahmoud Abumandour <ma.mandourr@gmail.com>.
Reviewed by: markj
PR: 262038
MFC after: 2 weeks
time() is now implemented using clock_gettime(2) instead of
gettimeofday(2).
Reviewed by: debdrup
Fixes: 358ed16f75 Use clock_gettime(CLOCK_SECOND)
MFC after: 1 week
Differential Revision: https://reviews.freebsd.org/D34438
During distributeworld we call distribute on subdirectories, which in
turn calls installconfig. However, this recursive installconfig call
appends the distribution name (in these cases, "base") to DESTDIR. For
install(1) this works fine as its -D argument comes from the top-level
Makefile.inc1, which passes the original DESTDIR, thereby resulting in
the METALOG entry having the distribution name as a prefix representing
its true installed path relative to the root, but for the hand-rolled
entries they do not use install(1) and thus do not have access to what
the original DESTDIR was, resulting in the METALOG missing this prefix.
Thus, pass down the name of the distribution via a new variable DISTBASE
(chosen as Makefile.inc1 already uses that to convey this exact same
information to etc's distrib-dirs during distributeworld) and prepend
this to the handful of manually-generated METALOG entries. For the
installworld case this variable will be empty and so this behaves as
before.
Note that we need to be careful to avoid double slashes in the METALOG;
distributeworld uses find | awk to split the single METALOG up into
multiple dist.meta files, and this relies on the paths in the METALOG
having the exact prefix ./dist (or ./dist/usr/lib/debug).
Reviewed by: brooks, emaste
Differential Revision: https://reviews.freebsd.org/D33997
The optimization of sysctlbyname() in commit d05b53e0ba had the
side-effect of not going through the fix-up for the user.* variables
in the previously called sysctl() function.
This lead to 0 or an empty strings being returned by sysctlbyname()
for all user.* variables.
An alternate implementation would store the user variables in the
kernel during system start-up. That would allow to remove the fix-up
code in the C library that is currently required to provide the actual
values.
This update restores the previous code path for the user.* variables
and keeps the performance optimization intact for all other variables.
Approved by: mjg
Reviewed by: kaktus
Differential Revision: https://reviews.freebsd.org/D34171
Testing had revealed that trying to retrieve the user.localbase
variable into to small a buffer would return the correct error code,
but would not fill the available buffer space with a partial result.
A partial result is of no use, but this is still a violation of the
documented behavior, which has been fixed in the previous commit to
this function.
I just checked the code for "user.cs_path" and found that it had the
same issue.
Instead of fixing the logic for each user.* sysctl string variable
individually, this commit adds a helper function set_user_str() that
implements the semantics specified in the sysctl() man page.
It is currently only used for "user.cs_path" and "user.localbase",
but it will offer a significant simplification when further such
variables will be added (as I intend to do).
MFC after: 3 days
Testing of a new feature revealed that calling sysctl() to retrieve
the value of the user.localbase variable passing too low a buffer size
could leave the result buffer unchanged.
The behavior in the normal case of a sufficiently large buffer was
correct.
All known callers pass a sufficiently large buffer and have thus not
been affected by this issue. If a non-default value had been assigned
to this variable, the result was as documented, too.
Fix the function to fill the buffer with a partial result, if the
passed in buffer size is too low to hold the full result.
MFC after: 3 days
in handling the cpuset sizes different from sizeof(cpuset_t).
For both cases, cpuset size shorter than sizeof(cpuset_t) results
in EINVAL on Linux.
For sched_getaffinity(), be more permissive and accept cpuset size
larger than our cpuset_t, by clipping the syscall argument and zeroing
the rest of the output buffer. For sched_setaffinity(), we should allow
shorter cpusets than current ABI size, again zeroing the rest of the bits.
With this change, python os.sched_get/setaffinity functions work.
Reported by: se
Sponsored by: The FreeBSD Foundation
MFC after: 1 week
This is a re-application of commit
2d82b47a5b, which was reverted since it
broke with syslog daemons that don't adjust the /dev/log recv buffer
size. Now that the default is large enough to accomodate 8KB messages,
restore support for large messages.
PR: 260126
The introduction of <sched.h> improved compatibility with some 3rd
party software, but caused the configure scripts of some ports to
assume that they were run in a GLIBC compatible environment.
Parts of sched.h were made conditional on -D_WITH_CPU_SET_T being
added to ports, but there still were compatibility issues due to
invalid assumptions made in autoconfigure scripts.
The differences between the FreeBSD version of macros like CPU_AND,
CPU_OR, etc. and the GLIBC versions was in the number of arguments:
FreeBSD used a 2-address scheme (one source argument is also used as
the destination of the operation), while GLIBC uses a 3-adderess
scheme (2 source operands and a separately passed destination).
The GLIBC scheme provides a super-set of the functionality of the
FreeBSD macros, since it does not prevent passing the same variable
as source and destination arguments. In code that wanted to preserve
both source arguments, the FreeBSD macros required a temporary copy of
one of the source arguments.
This patch set allows to unconditionally provide functions and macros
expected by 3rd party software written for GLIBC based systems, but
breaks builds of externally maintained sources that use any of the
following macros: CPU_AND, CPU_ANDNOT, CPU_OR, CPU_XOR.
One contributed driver (contrib/ofed/libmlx5) has been patched to
support both the old and the new CPU_OR signatures. If this commit
is merged to -STABLE, the version test will have to be extended to
cover more ranges.
Ports that have added -D_WITH_CPU_SET_T to build on -CURRENT do
no longer require that option.
The FreeBSD version has been bumped to 1400046 to reflect this
incompatible change.
Reviewed by: kib
MFC after: 2 weeks
Relnotes: yes
Differential Revision: https://reviews.freebsd.org/D33451
- Include <machine/tls.h> in MD rtld_machdep.h headers.
- Remove local definitions of TLS_* constants from rtld_machdep.h
headers and libc using the values from <machine/tls.h> instead.
- Use _tcb_set() instead of inlined versions in MD
allocate_initial_tls() routines in rtld. The one exception is amd64
whose _tcb_set() invokes the amd64_set_fsbase ifunc. rtld cannot
use ifuncs, so amd64 inlines the logic to optionally write to fsbase
directly.
- Use _tcb_set() instead of _set_tp() in libc.
- Use '&_tcb_get()->tcb_dtv' instead of _get_tp() in both rtld and libc.
This permits removing _get_tp.c from rtld.
- Use TLS_TCB_SIZE and TLS_TCB_ALIGN with allocate_tls() in MD
allocate_initial_tls() routines in rtld.
Reviewed by: kib, jrtc27 (earlier version)
Differential Revision: https://reviews.freebsd.org/D33353
- Use 16 byte alignment rather than 8 for aarch64, powerpc64, and RISC-V.
- Use 8 byte alignment rather than 4 for 32-bit arm, mips, and powerpc.
I suspect that mips64 should be using 16 byte alignment, but both libc
and rtld currently use 8 byte alignment.
Reviewed by: kib, jrtc27
Sponsored by: The University of Cambridge, Google Inc.
Differential Revision: https://reviews.freebsd.org/D33350
This reverts commit 2886c93d1b.
The original commit has two problems:
* It sets SO_SNDBUF to be as large as MAXLINE. But for unix domain
sockets, the send buffer is bypassed. Packets go directly to the
peer's receive buffer, so setting and querying SO_SNDBUF is
ineffective. To ensure that the socket can accept messages of a
certain size, it would be necessary to add a SO_PEERRCVBUF socket
option that could query the connected peer's receive buffer size.
* It sets MAXLINE to 8 kB, which is larger than the default sockbuf size
of 4 kB. That's ok for the builtin syslogd, which sets its recvbuf
to 80 kB, but not ok for alternative sysloggers, like rsyslogd, which
use the default size.
As a consequence, writing messages of more than 4 kB with syslog() as a
non-root user while running rsyslogd would cause the logging application
to spin indefinitely within syslog().
PR: 260126
MFC: 2 weeks
Sponsored by: Axcient
Reviewed by: markj
Differential Revision: https://reviews.freebsd.org/D33199
Namely posix_spawn_file_actions_addclosefrom_np, in the form it is
provided by glibc.
Reviewed by: kevans, ngie (previous version)
Sponsored by: The FreeBSD Foundation
MFC after: 1 week
Differential revision: https://reviews.freebsd.org/D33143
to wrap too long lines with function prototypes.
Reviewed by: kevans, ngie (previous version)
Sponsored by: The FreeBSD Foundation
MFC after: 1 week
Differential revision: https://reviews.freebsd.org/D33143
The variables clang13 complains about take the results of var_arg() calls.
I decided to kept variables around, annotating their definitions with
__unused, to keep clear expected types of the varargs.
Sponsored by: The FreeBSD Foundation
MFC after: 1 week
Instead of only hiding cpu_set_t compat typedef itself.
Too many software packages assume that sched_getaffinity() presence
implies full source compatibility with glibc. We can (and should)
handle missing CPU_* macros, but then there are incompatible BIT_* uses
which cannot be fixed in src/.
So hide everything under _WITH_CPU_SET_T, in particular, do not expose
sched_getcpu(), sched_get/setaffinity(), as well as CPU_* and BIT_*
macros. Consumers that want sched* functions must opt-in.
Reported by: portmgr (antoine)
Sponsored by: The FreeBSD Foundation
MFC after: 1 week
for compatibility with Linux.
Reviewed by: jhb
Sponsored by: The FreeBSD Foundation
MFC after: 1 week
Differential revision: https://reviews.freebsd.org/D32901
for compatibility with Linux.
Reviewed by: jhb
Sponsored by: The FreeBSD Foundation
MFC after: 1 week
Differential revision: https://reviews.freebsd.org/D32901
Variant I architectures use off and Variant II ones use size + off.
Define TLS_VARIANT_I/TLS_VARIANT_II symbols similarly to how libc
handles it.
Reviewed by: kib
MFC after: 1 week
Differential revision: https://reviews.freebsd.org/D31539
Differential revision: https://reviews.freebsd.org/D31541
Document that LOG_PID is ignored and can not be disabled.
This change was made along with the move from RFC 3164 to RFC 5424 log messages.
PR: 255664
Reported by: des.gaufres@gmail.com
Reviewed by: gbe, jilles
Approved by: gbe (mentor, manpages), jilles
This is the same change as d36d681615, but for libc static implementaion
of dl_iterate_phdr().
Reported by: emacsray@gmail.com
PR: 254774
Sponsored by: The FreeBSD Foundation
MFC after: 1 week
Differential revision: https://reviews.freebsd.org/D29623
dl_iterate_phdr() dlpi_tls_data should provide the TLS module segment
address, and not the TLS init segment address as it does now.
Reported by: emacsray@gmail.com
PR: 254774
Sponsored by: The FreeBSD Foundation
MFC after: 1 week
- Defined MAXLINE constant (8192 octets by default instead 2048) for
centralized limit setting up. It sets maximum number of characters of
the syslog message. RFC5424 doesn't limit maximum size of the message.
Named after MAXLINE in syslogd(8).
- Fixed size of fmt_cpy buffer up to MAXLINE for rendering formatted
(%m) messages.
- Introduced autoexpansion of sending socket buffer up to MAXLINE.
MFC after: 1 month
Differential Revision: https://reviews.freebsd.org/D27205
This caused LDBL_MANT_DIG to not be defined and therefore the scalbnl
alias was not being emitted for double==long double platforms.
Fixes: 760b2ffc ("Update scalbn* functions to the musl versions")
Reported by: Jenkins
All supported platforms support thread-local vars and __thread.
Reviewed by: emaste
Sponsored by: The FreeBSD Foundation
MFC after: 1 week
Differential Revision: https://reviews.freebsd.org/D28796
Preserve more space for swap devise names.
Prevent line overflow with long devise name.
Don't draw a bar when swap is not used at all.
Simplify and optimize code.
Change the label to end at end of 100%.
PR: 251655
MFC after: 2 weeks
Differential Revision: https://reviews.freebsd.org/D27496
