Previously a stream opened as read-only could be written to. Add a test
case for the fix.
Also correct another incorrect access mode check that worked by
accident, and improve the tests for that.
PR: 281953
Reported by: Erkki Moorits, fuz
Reviewed by: fuz, khng (earlier)
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D47265
(cherry picked from commit 0953460ce149e6f384aafbcb1e6213dfbf8f6a16)
(cherry picked from commit 6b9f7133aba44189d9625c352bc2c2a59baf18ef)
Add a minimal membarrier man page that documents the available cmd
values and errors that can be returned. We can add more information and
iterate on it in the tree.
Reviewed by: kib
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D46967
(cherry picked from commit 1fc766e3b41d0cdbd166ef95258434069a90ca52)
(cherry picked from commit 92cd5abb64dd70c305535c9504c6a2b73552147f)
(cherry picked from commit 8b41e693fc3956385d5771d60ee93e18001a5a0d)
This is a feature which allows one to splice two TCP sockets together
such that data which arrives on one socket is automatically pushed into
the send buffer of the spliced socket. This can be used to make TCP
proxying more efficient as it eliminates the need to copy data into and
out of userspace.
The interface is copied from OpenBSD, and this implementation aims to be
compatible. Splicing is enabled by setting the SO_SPLICE socket option.
When spliced, data that arrives on the receive buffer is automatically
forwarded to the other socket. In particular, splicing is a
unidirectional operation; to splice a socket pair in both directions,
SO_SPLICE needs to be applied to both sockets. More concretely, when
setting the option one passes the following struct:
struct splice {
int fd;
off_t max;
struct timveval idle;
};
where "fd" refers to the socket to which the first socket is to be
spliced, and two setsockopt(SO_SPLICE) calls are required to set up a
bi-directional splice.
select(), poll() and kevent() do not return when data arrives in the
receive buffer of a spliced socket, as such data is expected to be
removed automatically once space is available in the corresponding send
buffer. Userspace can perform I/O on spliced sockets, but it will be
unpredictably interleaved with splice I/O.
A splice can be configured to unsplice once a certain number of bytes
have been transmitted, or after a given time period. Once unspliced,
the socket behaves normally from userspace's perspective. The number of
bytes transmitted via the splice can be retrieved using
getsockopt(SO_SPLICE); this works after unsplicing as well, up until the
socket is closed or spliced again. Userspace can also manually trigger
unsplicing by splicing to -1.
Splicing work is handled by dedicated threads, similar to KTLS. A
worker thread is assigned at splice creation time. At some point it
would be nice to have a direct dispatch mode, wherein the thread which
places data into a receive buffer is also responsible for pushing it
into the sink, but this requires tighter integration with the protocol
stack in order to avoid reentrancy problems.
Currently, sowakeup() and related functions will signal the worker
thread assigned to a spliced socket. so_splice_xfer() does the hard
work of moving data between socket buffers.
Co-authored by: gallatin
Reviewed by: brooks (interface bits)
MFC after: 3 months
Sponsored by: Klara, Inc.
Sponsored by: Stormshield
Sponsored by: Netflix
Differential Revision: https://reviews.freebsd.org/D46411
(cherry picked from commit a1da7dc1cdad8c000622a7b23ff5994ccfe9cac6)
The manual page says %m is replaced with “the string representation of
the error code stored in the errno variable at the beginning of the
call”. However, we don't actually save `errno` until fairly late in
`__vfprintf()`. Make sure it is saved before we do anything that
might perturb `errno`.
MFC after: 1 week
Reviewed by: kevans
Differential Revision: https://reviews.freebsd.org/D46718
(cherry picked from commit 74f1007fcc838501c74a633792c3f01833bf65e1)
Checking the first nibble of the IPv6 address to be 0 and then
excluding two well known cases (v4-mapped, loopback) leaves us with
more cases where the first nibble could be 0, e.g., the RFC 6052,
2.1 Well-Known Prefix 64:ff9b::/96.
It is not practical to track them all and it is not clear what lead
to this special casing originally, so remove them.
While here also remove the IN6_IS_ADDR_LINKLOCAL() + NI_NUMERICHOST
case as link-local address resolution does exist.
We do leave the IN6_IS_ADDR_MULTICAST() case for now as I could
not find any references to any official reverse lookups for these.
Adding comments for more case (and some historic behaviour) in order
to make it easier to follow the logic.
PR: 279618
Fixes: 6cb9418289
Reviewed by: hrs
Differential Revision: https://reviews.freebsd.org/D45547
(cherry picked from commit c179937b986ec3959d89bfeb8eed0a6f58a28649)
Make the system call honor `AT_SYMLINK_NOFOLLOW`.
Also enable this from `linux_faccessat2` where the issue arised the first time.
Update manual pages accordingly.
PR: 275295
Reported by: kenrap@kennethraplee.com
Approved by: kib@
Differential Revision: https://reviews.freebsd.org/D46267
(cherry picked from commit 5ab6ed93cd3680f8b69dd4d05823f4740a2bdef9)
Fix "singleton" function used by regcomp() to turn character set matches
into exact character matches if a character set has exactly one
element.
The underlying cset representation is complex; most critically it
records"small" characters (codepoint less than either 128
or 256 depending on locale) in a bit vector, and "wide" characters in
a secondary array.
Unfortunately the "singleton" function uses to identify singleton sets
treated a cset as a singleton if either the "small" or the "wide" sets
had exactly one element (it would then ignore the other set).
The easiest way to demonstrate this bug:
$ export LANG=C.UTF-8
$ echo 'a' | grep '[abà]'
It should match (and print "a") but instead it doesn't match because the
single accented character in the set is misinterpreted as a singleton.
PR: 281710
Reviewed by: kevans, yuripv
Obtained from: illumos
(cherry picked from commit 8f7ed58a15556bf567ff876e1999e4fe4d684e1d)
The index symbol doesn't belong in memcpy.S as it is already in
strchr.S where it belongs.
Sponsored by: Arm Ltd
(cherry picked from commit 024248c933c5741a21c17eda63092f330dd98337)
Add support for extra registers to the arm64 getcontextx. As no
registers are defined this just adds the extra register list and an end
context.
Reviewed by: kib
Sponsored by: Arm Ltd
Differential Revision: https://reviews.freebsd.org/D44255
(cherry picked from commit 5202ca77aaf552310bcbaccba750ee9f0888d0d8)
This will be used as the base of a non-trivial implementation.
Reviewed by: kib
Sponsored by: Arm Ltd
Differential Revision: https://reviews.freebsd.org/D44254
(cherry picked from commit fd6b1cc34e4175c1e223f42540debb74cfe3c3e6)
An overread condition in memccpy(dst, src, c, len) would occur if
src does not cross a 16 byte boundary and there is no instance of
c between *src and the next 16 byte boundary. This could cause a
read fault if src is just before the end of a page and the next page
is unmapped or unreadable.
The bug is a consequence of basing memccpy() on the strlcpy() code:
whereas strlcpy() assumes that src is a nul-terminated string and
hence a terminator is always present, c may not be present at all in
the source string. It was not caught earlier due to insufficient
unit test design.
As a part of the fix, the function is refactored such that the runt
case (buffer length from last alignment boundary between 1 and 32 B)
is handled separately. This reduces the number of conditional
branches on all code paths and simplifies the handling of early
matches in the non-runt case. Performance is improved slightly.
os: FreeBSD
arch: amd64
cpu: 11th Gen Intel(R) Core(TM) i7-1165G7 @ 2.80GHz
│ memccpy.unfixed.out │ memccpy.fixed.out │
│ sec/op │ sec/op vs base │
Short 66.76µ ± 0% 62.45µ ± 1% -6.44% (p=0.000 n=20)
Mid 7.938µ ± 0% 7.967µ ± 0% +0.36% (p=0.001 n=20)
Long 3.577µ ± 0% 3.577µ ± 0% ~ (p=0.429 n=20)
geomean 12.38µ 12.12µ -2.08%
│ memccpy.unfixed.out │ memccpy.fixed.out │
│ B/s │ B/s vs base │
Short 1.744Gi ± 0% 1.864Gi ± 1% +6.89% (p=0.000 n=20)
Mid 14.67Gi ± 0% 14.61Gi ± 0% -0.36% (p=0.001 n=20)
Long 32.55Gi ± 0% 32.55Gi ± 0% ~ (p=0.429 n=20)
geomean 9.407Gi 9.606Gi +2.12%
Reported by: getz
Reviewed by: getz
Approved by: mjg (blanket, via IRC)
See also: D46051
MFC: stable/14
Event: GSoC 2024
Differential Revision: https://reviews.freebsd.org/D46052
See 8164d511d6a6 ("libc/tests: Fix installation without MK_TOOLCHAIN")
for some background. Here we should really be testing MK_CLANG instead,
since that's what gates compilation of libclang_rt.
Fixes: 8164d511d6a6 ("libc/tests: Fix installation without MK_TOOLCHAIN")
(cherry picked from commit da925fcebf397cc3bfc74b7aa9757efd6231aa00)
There is some exotic conditional logic here to avoid building a
particular test if a certain UBSAN library isn't present in the
toolchain sysroot. This causes build failures for me when doing an
"installworld WITHOUT_TOOLCHAIN=", which I do frequently during tests.
I believe the problem is that SYSROOT is unset during installworld, so
the build sees the host's copy of libclang_rt.ubsan_standalone.a and
then tries to install a binary that wasn't built during buildworld. Try
to make the check a bit less fragile.
Reviewed by: dim
MFC after: 2 weeks
Differential Revision: https://reviews.freebsd.org/D45035
(cherry picked from commit 8164d511d6a6053df82911e7d4ebb34fff3d765c)
Before this commit, we only had the capability to check if a specific
capability was set (using cap_rights_is_set function). However, there
was no efficient method to determine if a cap_rights_t structure doesn't
contain any capability. The cap_rights_is_empty function addresses
this gap.
PR: 275330
Reported by: vini.ipsmaker@gmail.com
Reviewed by: emaste, markj
Differential Revision: https://reviews.freebsd.org/D42780
(cherry picked from commit a7100ae23aca07976926bd8d50223c45149f65d6)
To fix WITHOUT_NIS build. Building yp_xdr.c is gated by MK_NIS.
PR: 279270
Reported by: peterj
Reported by: matteo
Reported by: Michael Dexter's Build Option Survey run
Reviewed by: brooks
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D45347
(cherry picked from commit 61639bb3fc5abe0bb7b096e643b51c30703ac432)
access(), eaccess() and faccessat() will always dereference
symbolic links.
So add a note in the manual page, that lstat(2) should be
used in the case of symbolic links.
PR: 262895
Reviewed by: gbe, pauamma_gundo.com
MFC after: 1 week
Differential Revision: https://reviews.freebsd.org/D44890
(cherry picked from commit 421025a274fb5759b3ecc8bdb30b24db830b45ae)
Capsicum-sandboxed applications generally cannot use dlopen, as absolute
and cwd-relative paths cannot be accessed. Mention that fdlopen is
useful for sandboxed applications.
PR: 277169
Reviewed by: markj, oshogbo
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D45108
(cherry picked from commit d84fd89ecd404ffbf629381d2dde14fd79b39402)
The CLOCK_* constants are "defined variable or preprocessor constants"
and so use .Dv.
Reviewed by: imp
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D45106
(cherry picked from commit 2d29d2ecebf8ea19221995b3ea2e3a7ac700bf81)
As kib@ noted:
> Obviously gettimeofday(2) is not going to be removed
> even in the far future.
Reported by: kib
Fixes: 4395d3ced5cf Document that gettimeofday() is obsolescent
MFC after: 3 days
(cherry picked from commit 6662c2312e956439652ce2d06b42753b6a78fc61)
Change .Xr reference to .Fn, which quiets a mandoc warning.
Reviewed by: mhorne
MFC after: 3 days
Pull Request: https://github.com/freebsd/freebsd-src/pull/1135
(cherry picked from commit d3de1bd429bc51fbbcb37fadaf2581461edf848b)
* Mention that mktime() and timegm() set errno on failure.
* Correctly determining whether mktime() / timegm() succeeded with
arbitrary input (where -1 can be a valid result) is non-trivial.
Document the recommended procedure.
PR: 277863
MFC after: 1 week
Reviewed by: pauamma_gundo.com, gbe
Differential Revision: https://reviews.freebsd.org/D44503
(cherry picked from commit 7534109d13a6cdb22e78d9d4c0a0cd5efd323c45)