[sanitizer][msan] fix AArch64 vararg support for KMSAN (#70660)
Cast StackSaveAreaPtr, GrRegSaveAreaPtr, VrRegSaveAreaPtr to pointers to
fix assertions in getShadowOriginPtrKernel().
Fixes: https://github.com/llvm/llvm-project/issues/69738
Patch by Mark Johnston.
Requested by: markj
MFC after: 3 days
traceroute hasn't had a vendor import since 2002, while since then it's
had several significant FreeBSD-specific commits. Since it's unlikely
another vendor import will happen, and to make the merge of traceroute6
into traceroute easier, import traceroute into usr.sbin.
Reviewed by: imp
Pull Request: https://github.com/freebsd/freebsd-src/pull/1100
create_qp_handle_resp_common_cleanup should be void
__ibv_cleanup_wq should use wq->cond for cond destroy
both issues were overlooked in:
a687910 ('Cleanup pthread locks in ofed RDMA verbs')
Signed-off-by: Bartosz Sobczak <bartosz.sobczak@intel.com>
Signed-off-by: Eric Joyner <erj@FreeBSD.org>
Reviewed by: sean.lim@dell.com, vangyzen@, erj@
MFC after: 1 day
Sponsored by: Intel Corporation
Differential Revision: https://reviews.freebsd.org/D43491
Silence the warning:
argument to 'sizeof' in 'strncpy' call is the same expression as the
source; did you mean to use the size of the destination?"
by using strlcpy() and the size of the destination (device).
No functional change intended.
Reviewed by: imp
Pull Request: https://github.com/freebsd/freebsd-src/pull/901
[libc++] Fix filesystem::remove_all() on FreeBSD (#79540)
remove_all_impl() opens the target path with O_NOFOLLOW, which fails if
the target is a symbolic link. On FreeBSD, rather than returning ELOOP,
openat() returns EMLINK. This is unlikely to change for compatibility
reasons, see https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=214633 .
Thus, check for EMLINK as well.
Reported by: markj
PR: 276632
MFC after: 3 days
[compiler-rt] remove hexdump interception. (#79378)
a freebsd dev member reported a symbol conflict and intercepting this
had little value anyway.
This is one part of fixing the WITH_ASAN build. Some executables in the
base system define their own hexdump() symbol, which would otherwise
conflict with the ASan-intercepted one.
Reported by: markj
PR: 276597
MFC after: 3 days
This update fixes a bug that line breaks in printed numbers may not
match the line length set by the user. The value is printed correctly,
just not split as specified in some situations.
(cherry picked from commit 52a5ec1b178fd07651446c7e31b1512794a04dbf)
This update improves the implementation of the power function p() and
adds 3 new functions to the extended math library: min(), max(), and
i2rand().
(cherry picked from commit 0b4a06ab29a0da80f6cb5c99189054cb8e2f756c)
Introduce pfctl_add_rule_h(), which takes a pfctl_handle rather than a
file descriptor (which it didn't use). This means that library users can
open the handle while they're running as root, but later drop privileges
and still add rules to pf.
Sponsored by: Rubicon Communications, LLC ("Netgate")
Explicit Congestion Notification (ECN) is a mechanism that allows
end-to-end notification of network congestion without dropping packets
by explicitly setting the ECN code point (2 bits).
Per RFC 8087, section 3.5, network devices should not be configured to
change the ECN code point in the packets that they forward, except to
set the CE (Congestion Experienced) code point ('11') to signal
incipient congestion.
The current commit adds an -E flag to traceroute that crafts a packet
with an ECT(1) code point ('01').
If the packet is received back with a zero ECN code point ('00'), it
outputs that the hop in question erases or "bleaches" the ECN code point
values. Bleaching may occur for various reasons (including normalizing
packets to hide which equipment supports ECN). This policy prevents the
use of ECN by applications.
If the packet is received back with an all-ones ECN code point ('11'),
it outputs that the hop in question is experiencing "congestion".
If the packet is received back with a different ECN code point ('10'),
it outputs that the hop in question changes or "mangles" the ECN code
point values.
If the packet is received with the same ECN code point that was sent
('01'), it outputs that the hop has "passed" the ECN bits appropriately.
Inspired by: Darwin
Reviewed by: imp, markj
MFC after: 1 month
Pull Request: https://github.com/freebsd/freebsd-src/pull/879
Signal blocking originally showed up in 51c2afc4b65b2782 ("Support:
Don't call close again if we get EINTR"), but it was overzealous --
there are systems where the error is known to be fine.
This commit elides signal blocking for said systems (the list is
incomplete though).
Note close() can still fail for other reasons (like ENOSPC), in which
case an error will be returned while the fd slot is cleared up.
Reviewed by: dim
Differential Revision: https://reviews.freebsd.org/D42984
In commit 88640c0e8b the new EINTEGRITY errno value was added, and
this caused us to carry a patch for upstream libc++ since that time.
Because it can cause merge conflicts when importing libc++ code from
upstream, I have submitted an upstream pull request to get most of that
patch integrated.
It turns out that we do not need the errno.h part of it at all, since
all supported FreeBSD versions define EOWNERDEAD and ENOTRECOVERABLE,
and therefore the block that juggles with ELAST values is never used in
FreeBSD. At the moment it only applies to older versions of Linux, or
possibly other platforms.
Therefore the only part that needs to stay is the definition of a enum
errc value for EINTEGRITY, and this is made optional upon EINTEGRITY
being defined, to make it suitable for upstreaming.
No functional change is intended.
MFC after: 1 week
Building telnet with clang 18 results in the following warning:
contrib/telnet/telnet/telnet.c:231:5: error: 'snprintf' will always be truncated; specified size is 10, but format string expands to at least 11 [-Werror,-Wformat-truncation]
231 | snprintf(temp2, sizeof(temp2), "%c%c%c%c....%c%c", IAC, SB, TELOPT_COMPORT,
| ^
The temp2 buffer is 10 chars, while the format string also consists of
10 chars. Therefore, snprintf(3) will truncate the last character, 'SE'
(end sub negotation) in this case.
Bump the buffer to 11 chars to avoid truncation.
MFC after: 3 days
It appears that Clang 16 errors by default for the mismatched function
pointer types that are triggered by the fts callback (since glibc has a
callback type without the second const qualifier).
Fortunately, there is already code to handle glibc inside mandoc, we
just have to edit the checked-in config.h.
Reviewed By: imp, emaste
Differential Revision: https://reviews.freebsd.org/D42999
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
[Clang] Do not change the type of captured vars when checking lambda constraints
When checking the constraint of a lambda, we need to respect the constness
of the call operator when establishing the type of capture variables.
In D124351, this was done by adding const to the captured variable...
However, that would change the type of the variable outside of the scope
of the lambda, which is clearly not the desired outcome.
Instead, to ensure const-correctness, we need to populate
a LambdaScopeInfo with the capture variables before checking the
constraints of a generic lambda.
There is no changelog as I'd like to tentatively propose we backport
this change to RC3 as it is a regression introduced in the Clang 17
cycle.
Fixes#61267
Reviewed By: aaron.ballman, #clang-language-wg
Differential Revision: https://reviews.llvm.org/D158433
Merge commit 3ed9e9e3ace6 from llvm git (by Corentin Jabot):
[Clang] Add captures to the instantiation scope of lambda call operators
Like concepts checking, a trailing return type of a lambda
in a dependent context may refer to captures in which case
they may need to be rebuilt, so the map of local decl
should include captures.
This patch reveal a pre-existing issue.
`this` is always recomputed by TreeTransform.
`*this` (like all captures) only become `const`
after the parameter list.
However, if try to recompute the value of `this` (in a parameter)
during template instantiation while determining the type of the call operator,
we will determine it to be const (unless the lambda is mutable).
There is no good way to know at that point that we are in a parameter
or not, the easiest/best solution is to transform the type of this.
Note that doing so break a handful of HLSL tests.
So this is a prototype at this point.
Fixes#65067Fixes#63675
Reviewed By: erichkeane
Differential Revision: https://reviews.llvm.org/D159126
This fixes 'Assertion failed: (isa<LabelDecl>(D) && "declaration not
instantiated in this scope"), function findInstantiationOf' error when
building databases/mongodb44.
PR: 273753
MFC after: 1 month
This updates llvm, clang, compiler-rt, libc++, libunwind, lld, lldb and
openmp to llvm-project main llvmorg-17-init-19304-gd0b54bb50e51, the
last commit before the upstream release/17.x branch was created.
PR: 273753
MFC after: 1 month
In order to avoid running into the default net.local.dgram.maxdgram
of 2K currently when calling sendto(2) try to set the sndbuf size to
the maximum ctrl message size.
While on 14 and 15 this does not actually raise the limit anymore (and
be7c095ac9 raised it for syslogd and this),
FreeBSD 13 still requires this change and it will work as expected there.
In addition we always ensure a large enough send buffer this way
independent of kernel defaults.
The problem occured, e.g., when the scan_list result had enough BSSIDs
so the text output would exceed 2048 bytes.
Sponsored by: The FreeBSD Foundation
MFC after: 3 days
PR: 274990
Reviewed by: cy, adrian (with previous comment)
Differential Revision: https://reviews.freebsd.org/D42558
