nfs_commonkrpc.c: Get rid of NFSv4.0 delegation cruft
Delegations in NFSv4.0 never worked well and, since
the NFSv4.0 protocol is now deprecated, use of delegations
for NFSv4.0 is disabled as far as the client can do so.
It turns out that some Illumos NFSv4.0 server issues
delegations anyhow (even when the callback path is
specified as 0.0.0.0) and this can cause use after free
problems.
This patch deleted some cruft that did an nfsrpc_openrpc()
call recursively when an NFSv4.0 server failed to issue
a delegation when it had previously done so.
This code was only meant to be an optimization and
would have been rarely exercised. Since this recursive
call of nfsrpc_openrpc() is in some of the backtraces
in the bugzilla PR, getting rid of the cruft makes sense.
[6 lines not shown]
nfs_commonkrpc.c: Fix recovery that was broken by 4d80d4913e79
Commit 4d80d4913e79 added a check for nfsess_defunct already
being set. This was incorrect because, once set, nfsess_defunct
remains set and an additional recovery might be needed.
This patch reverts this part of 4d80d4913e79.
PR: 297252
(cherry picked from commit 5ab48fb9f7ac43fb1242a678312a02df5d4d5b53)
nfs_commonkrpc.c: Get rid of NFSv4.0 delegation cruft
Delegations in NFSv4.0 never worked well and, since
the NFSv4.0 protocol is now deprecated, use of delegations
for NFSv4.0 is disabled as far as the client can do so.
It turns out that some Illumos NFSv4.0 server issues
delegations anyhow (even when the callback path is
specified as 0.0.0.0) and this can cause use after free
problems.
This patch deleted some cruft that did an nfsrpc_openrpc()
call recursively when an NFSv4.0 server failed to issue
a delegation when it had previously done so.
This code was only meant to be an optimization and
would have been rarely exercised. Since this recursive
call of nfsrpc_openrpc() is in some of the backtraces
in the bugzilla PR, getting rid of the cruft makes sense.
[6 lines not shown]
nfs_commonkrpc.c: Fix recovery that was broken by 4d80d4913e79
Commit 4d80d4913e79 added a check for nfsess_defunct already
being set. This was incorrect because, once set, nfsess_defunct
remains set and an additional recovery might be needed.
This patch reverts this part of 4d80d4913e79.
PR: 297252
(cherry picked from commit 5ab48fb9f7ac43fb1242a678312a02df5d4d5b53)
net-mgmt/check_mk_agent: Change default paths
Upstream changed default values for MK_CONFDIR and MK_VARDIR.
This updates the patch to properly use PREFIX with the new defaults
and not hardcode to /usr/local.
PR: 297244
Approved by: maintainer
link_elf: Make phdrs first page check actually fatal
Otherwise we'll print an error but carry on regardless, presumably
destined to walk off the end of the mapping.
Reported by: thebugfixers at pm.me
MFC after: 1 week
(cherry picked from commit 1e39a314d870e312f623199e146eda6bdbc293a3)
Merge commit 6b0a46958c56 from llvm-project (by Piotr Kubaj):
[libunwind][PPC64] Fix unw_getcontext corrupting callee-saved VSX registers on LE (#198371)
This is the first of two independent fixes for libunwind on ppc64le
(ELFv2 ABI, little-endian), where two separate bugs together cause
SIGSEGV during backtracing. This commit addresses the VSX register
corruption; the TOC-restore fault is handled in a follow-up. Both
were discovered while debugging lang/rust build failures with
RUST_BACKTRACE=1 on FreeBSD/powerpc64le (IBM POWER9).
On ppc64le, `unw_getcontext` saves each VS register with an in-place
`xxswapd n, n` followed by `stxvd2x`. The swap is needed because
`stxvd2x` stores doublewords in the wrong order on LE. However, the
macro never applies a second `xxswapd` to restore the register after
the store, so all 64 VS registers are permanently corrupted on return
from `unw_getcontext`.
This affects every callee-saved VSX register: f14-f31 (VSR14-VSR31)
[13 lines not shown]
Merge commit 26bf39cdba0b from llvm-project (by Jessica Clarke):
[ELF][PowerPC] Don't assume TOC pointer is valid in IPLT entries (#207555)
Unlike normal PLT entries, IPLT entries can be called indirectly even
when in PIEs/DSOs, and so there's no guarantee on what's in the TOC
pointer register at that time. Therefore we must emit variants of the
existing code that work without it, whether r12-relative (playing the
same role as MIPS's $25) in the same number of instructions, or first
retrieving PC in an i386-like manner, being careful not to clobber LR.
On 32-bit PowerPC even direct calls to IPLT entries face the same issue,
since we'd use the TOC base of the resolver, which may not be the same
as the caller, even within the same object.
Normal canonical PLTs still look broken on 64-bit PowerPC as they use
the TOC pointer register too, and similarly on 32-bit PowerPC for PIEs.
We should probably treat these cases the same as PIE on i386 (except
including PDEs for 64-bit PowerPC), where it's an error due to the use
of %ebx in PLT entries.
[9 lines not shown]
Merge commit cbf48349e3e1 from llvm-project (by Jessica Clarke):
[NFC][ELF][PPC64] Pass address not offset to writePPC64LoadAndBranch (#212275)
Every caller currently subtracts the TOC base in its argument, so move
that into common code inside writePPC64LoadAndBranch. This will also
allow a different computation to be used in some cases in a future
commit.
Note that offset is now unsigned not signed; even previously, all
arguments were uint64_t, and all uses are unsigned, so making it signed
doesn't make much sense.
MFC after: 1 week
(cherry picked from commit bcbcd7303009344dc1051e4601284620bca29be8)
libllvmminimal: Fix building with LLVM < 21 on riscv64
On most architectures we end up not needing ABIBreak.cpp as, although
some of the sources here do reference EnableABIBreakingChecks (or, if
assertions are disabled, DisableABIBreakingChecks) at a source level, we
compile with -ffunction-sections and -fdata-sections, and link with
--gc-sections, and it happens to be the case that all references can be
GC'ed. However, prior to LLVM 21, the RISC-V backend did not apply
-fdata-sections to .sdata, where references to these symbols end up, and
for some files we're building with such references we end up not being
able to GC .sdata due to the other unrelated data in it, meaning that we
do in fact need to build ABIBreak.cpp.
Whilst we could make this conditional on the architecture, it's a tiny
file, and it's a bit fragile to rely on GC behaviour, so just include it
unconditionally.
Reviewed by: dim, emaste
Fixes: 770cf0a5f02d ("Fixups after llvm-project main llvmorg-21-init-19288-gface93e724f4 merge")
[4 lines not shown]
link_elf: Make phdrs first page check actually fatal
Otherwise we'll print an error but carry on regardless, presumably
destined to walk off the end of the mapping.
Reported by: thebugfixers at pm.me
MFC after: 1 week
(cherry picked from commit 1e39a314d870e312f623199e146eda6bdbc293a3)
Merge commit 6b0a46958c56 from llvm-project (by Piotr Kubaj):
[libunwind][PPC64] Fix unw_getcontext corrupting callee-saved VSX registers on LE (#198371)
This is the first of two independent fixes for libunwind on ppc64le
(ELFv2 ABI, little-endian), where two separate bugs together cause
SIGSEGV during backtracing. This commit addresses the VSX register
corruption; the TOC-restore fault is handled in a follow-up. Both
were discovered while debugging lang/rust build failures with
RUST_BACKTRACE=1 on FreeBSD/powerpc64le (IBM POWER9).
On ppc64le, `unw_getcontext` saves each VS register with an in-place
`xxswapd n, n` followed by `stxvd2x`. The swap is needed because
`stxvd2x` stores doublewords in the wrong order on LE. However, the
macro never applies a second `xxswapd` to restore the register after
the store, so all 64 VS registers are permanently corrupted on return
from `unw_getcontext`.
This affects every callee-saved VSX register: f14-f31 (VSR14-VSR31)
[13 lines not shown]
Merge commit 26bf39cdba0b from llvm-project (by Jessica Clarke):
[ELF][PowerPC] Don't assume TOC pointer is valid in IPLT entries (#207555)
Unlike normal PLT entries, IPLT entries can be called indirectly even
when in PIEs/DSOs, and so there's no guarantee on what's in the TOC
pointer register at that time. Therefore we must emit variants of the
existing code that work without it, whether r12-relative (playing the
same role as MIPS's $25) in the same number of instructions, or first
retrieving PC in an i386-like manner, being careful not to clobber LR.
On 32-bit PowerPC even direct calls to IPLT entries face the same issue,
since we'd use the TOC base of the resolver, which may not be the same
as the caller, even within the same object.
Normal canonical PLTs still look broken on 64-bit PowerPC as they use
the TOC pointer register too, and similarly on 32-bit PowerPC for PIEs.
We should probably treat these cases the same as PIE on i386 (except
including PDEs for 64-bit PowerPC), where it's an error due to the use
of %ebx in PLT entries.
[9 lines not shown]
