vfs_lookup_cross_mount(): fix missing LK_CANRECURSE
This was a rather dumb miss on my part in commit 42442d7a6e.
LK_CANRECURSE is clearly needed in any case in which the covered vnode
is held exclusive across the call to VFS_ROOT(), regardless of whether
it was initially held exclusive or upgraded. The commit message for
that change also noted that unionfs lookup only worked without
LK_CANRECURSE due to a coincidence of the then-current unionfs
implementation. As it happens, said coincidence was recently removed
in commit b952606b4f ("unionfs_lock(): eliminate LK_CANRECURSE special-
case").
PR: 298201
Reported by: olivier
Fixes: 42442d7a6e "Generalize the VV_CROSSLOCK logic in
vfs_lookup"
Reviewed by: kib, markj, pho
Tested by: pho
Differential Revision: https://reviews.freebsd.org/D59494
[2 lines not shown]
vfs_lookup_cross_mount(): fix missing LK_CANRECURSE
This was a rather dumb miss on my part in commit 42442d7a6e.
LK_CANRECURSE is clearly needed in any case in which the covered vnode
is held exclusive across the call to VFS_ROOT(), regardless of whether
it was initially held exclusive or upgraded. The commit message for
that change also noted that unionfs lookup only worked without
LK_CANRECURSE due to a coincidence of the then-current unionfs
implementation. As it happens, said coincidence was recently removed
in commit b952606b4f ("unionfs_lock(): eliminate LK_CANRECURSE special-
case").
PR: 298201
Reported by: olivier
Fixes: 42442d7a6e "Generalize the VV_CROSSLOCK logic in
vfs_lookup"
Reviewed by: kib, markj, pho
Tested by: pho
Differential Revision: https://reviews.freebsd.org/D59494
[2 lines not shown]
nfsuserd.c: Fix handling where pw_name/gr_name differ from lookup name
When an NSS backend returns a canonical pw_name or gr_name that differs from
the lookup name supplied by the NFSv4 upcall, nfsuserd stores the successful
mapping in the kernel cache under the canonical name instead of the requested
name.
This causes the retry lookup performed by nfsv4_strtouid() or
nfsv4_strtogid() to miss the newly inserted cache entry, resulting in the
default UID/GID being returned although the NSS lookup itself succeeded.
PR: 296753
(cherry picked from commit 1771ab245c2341033f0cee3bd098c76888cf3515)
nfsuserd.c: Fix handling where pw_name/gr_name differ from lookup name
When an NSS backend returns a canonical pw_name or gr_name that differs from
the lookup name supplied by the NFSv4 upcall, nfsuserd stores the successful
mapping in the kernel cache under the canonical name instead of the requested
name.
This causes the retry lookup performed by nfsv4_strtouid() or
nfsv4_strtogid() to miss the newly inserted cache entry, resulting in the
default UID/GID being returned although the NSS lookup itself succeeded.
PR: 296753
(cherry picked from commit 1771ab245c2341033f0cee3bd098c76888cf3515)
dtrace/arm64: Fix copyout and copyoutstr
Calling dtrace_copy and dtrace_copystr with the kaddr and uaddr
arguments inversed does not work with PAN. Rename them
dtrace_copyin_pan and dtrace_copyinstr_pan, respectively, and
implement dtrace_copyout_pan and dtrace_copyoutstr_pan.
Avoid excessive faulting by checkin DTrace's CPU flags. Implement the
trick from OpenSolaris/Illumos of only checking the flags when
crossing into a new page, altough more effectively by examining the
vaddr instead of the count.
Reviewed by: markj
MFC after: 3 weeks
Differential Revision: https://reviews.freebsd.org/D59449
add nprice to committers-src
Approved by: adrian (mentor)
Reviewed by: adrian
Differential Revision: https://reviews.freebsd.org/D59860
Signed-off-by: Nick Price <nprice at FreeBSD.org>
hastd: Use fixed-length protocol names
All communication between hastd nodes and internally between hastd and
its worker children passes through the same pair of send / receive
functions. The receive function uses recv(2) with the MSG_WAITALL flag,
which in theory means we should never get a short read. However, when
handing off a socket to a worker child, we also pass a variable-length
string identifying the type of socket we're passing, and reading this
string relies on a short read. This used to work because the arrival of
the descriptor would interrupt the recv(2) call, but this bug was fixed
when the AF_UNIX code was rewritten a while ago and hastd has been
broken ever since.
Fixing the length of the protocol name to four characters including the
terminating null solves the short-read bug by never requiring a short
read (nothing else in hastd requires one).
Note that this issue appears to have been reported independently first
by Alessandro Sagratini in PR 292322 and then by Martin Vidovic in
[11 lines not shown]
hastd: Ensure nvpair padding is initialized
The proto-libnv implementation embedded in hastd pads names and values
out to the nearest multiple of eight bytes, but leaves the padding
uninitialized, leaking up to 14 bytes of recycled heap per pair in a
message.
While here, switch from bcopy() to memcpy().
MFC after: 3 days
Reviewed by: kevans, emaste
Differential Revision: https://reviews.freebsd.org/D59343
(cherry picked from commit 911bda7cffbf358c4e83ea05cfe980d429aff61c)
tests: Fix graid3 insert tests
The script was passing the wrong device name to `graid3 insert` and
didn't notice that the command was failing.
MFC after: 1 week
Event: EuroBSDcon 2026 DevSummit
Reviewed by: delphij
Differential Revision: https://reviews.freebsd.org/D59564
(cherry picked from commit 4cc85d1f00fa1938923fe8d6fc2934593d4303b4)
graid3: Restore lock acquisition
The lock acquisition in g_raid3_ctl_insert() was improperly dropped a
while ago, making it impossible to add or replace a device in an
existing graid3. This went unnoticed because the tests are broken.
MFC after: 1 week
Fixes: fcf69f3dbce6 ("Consistently use gctl_get_provider instead of home-grown variants.")
Event: EuroBSDcon 2026 DevSummit
Reviewed by: delphij
Differential Revision: https://reviews.freebsd.org/D59563
(cherry picked from commit 9094f86b57a7e4b356cae83f35c8d41c842b42a2)
hastd: Ensure nvpair padding is initialized
The proto-libnv implementation embedded in hastd pads names and values
out to the nearest multiple of eight bytes, but leaves the padding
uninitialized, leaking up to 14 bytes of recycled heap per pair in a
message.
While here, switch from bcopy() to memcpy().
MFC after: 3 days
Reviewed by: kevans, emaste
Differential Revision: https://reviews.freebsd.org/D59343
(cherry picked from commit 911bda7cffbf358c4e83ea05cfe980d429aff61c)
hastd: Use fixed-length protocol names
All communication between hastd nodes and internally between hastd and
its worker children passes through the same pair of send / receive
functions. The receive function uses recv(2) with the MSG_WAITALL flag,
which in theory means we should never get a short read. However, when
handing off a socket to a worker child, we also pass a variable-length
string identifying the type of socket we're passing, and reading this
string relies on a short read. This used to work because the arrival of
the descriptor would interrupt the recv(2) call, but this bug was fixed
when the AF_UNIX code was rewritten a while ago and hastd has been
broken ever since.
Fixing the length of the protocol name to four characters including the
terminating null solves the short-read bug by never requiring a short
read (nothing else in hastd requires one).
Note that this issue appears to have been reported independently first
by Alessandro Sagratini in PR 292322 and then by Martin Vidovic in
[11 lines not shown]
tests: Fix graid3 insert tests
The script was passing the wrong device name to `graid3 insert` and
didn't notice that the command was failing.
MFC after: 1 week
Event: EuroBSDcon 2026 DevSummit
Reviewed by: delphij
Differential Revision: https://reviews.freebsd.org/D59564
(cherry picked from commit 4cc85d1f00fa1938923fe8d6fc2934593d4303b4)
graid3: Restore lock acquisition
The lock acquisition in g_raid3_ctl_insert() was improperly dropped a
while ago, making it impossible to add or replace a device in an
existing graid3. This went unnoticed because the tests are broken.
MFC after: 1 week
Fixes: fcf69f3dbce6 ("Consistently use gctl_get_provider instead of home-grown variants.")
Event: EuroBSDcon 2026 DevSummit
Reviewed by: delphij
Differential Revision: https://reviews.freebsd.org/D59563
(cherry picked from commit 9094f86b57a7e4b356cae83f35c8d41c842b42a2)
kern.mk: make clang 23 -Wunused-but-set-global non-fatal
This warning triggers in a few places in contributed code, and would
therefore be annoying to fix. Use -Wno-error= to at least show the
warnings so there is some incentive to submit them upstream.
MFC after: 3 days
(cherry picked from commit bcd0d76d4882dd8d19a49c050411b5c58a0deb74)
bsd.sys.mk: make clang 23 -Wunused-but-set-global non-fatal
This warning triggers in a few places in contributed code, and would
therefore be annoying to fix. Use -Wno-error= to at least show the
warnings so there is some incentive to submit them upstream.
MFC after: 3 days
(cherry picked from commit d577b4ed588c0f259d7298188233b17dc0435dd4)
Merge commit 1f332ae4f1b3 from llvm-project (by Alexander Kornienko):
Fix -Wformat diagnostic after #190965 (#193704)
Fixes libunwind compiler diagnostic when building with clang after
034d4dcad6396d1241e8262e69871b8d61da7e4f:
```
In file included from libunwind/src/libunwind.cpp:31:
In file included from libunwind/src/UnwindCursor.hpp:52:
libunwind/src/CompactUnwinder.hpp:339:46: error: format specifies type 'unsigned long long' but the argument has type 'uint64_t' (aka 'unsigned long') [-Werror,-Wformat]
338 | "function starting at 0x%llX",
| ~~~~
| %lX
339 | compactEncoding, functionStart);
| ^~~~~~~~~~~~~
libunwind/src/config.h:215:63: note: expanded from macro '_LIBUNWIND_DEBUG_LOG'
215 | #define _LIBUNWIND_DEBUG_LOG(msg, ...) _LIBUNWIND_LOG(msg, __VA_ARGS__)
| ~~~ ^~~~~~~~~~~
libunwind/src/config.h:181:45: note: expanded from macro '_LIBUNWIND_LOG'
[23 lines not shown]
kern.mk: make clang 23 -Wunused-but-set-global non-fatal
This warning triggers in a few places in contributed code, and would
therefore be annoying to fix. Use -Wno-error= to at least show the
warnings so there is some incentive to submit them upstream.
MFC after: 3 days
(cherry picked from commit bcd0d76d4882dd8d19a49c050411b5c58a0deb74)
bsd.sys.mk: make clang 23 -Wunused-but-set-global non-fatal
This warning triggers in a few places in contributed code, and would
therefore be annoying to fix. Use -Wno-error= to at least show the
warnings so there is some incentive to submit them upstream.
MFC after: 3 days
(cherry picked from commit d577b4ed588c0f259d7298188233b17dc0435dd4)
Merge commit 1f332ae4f1b3 from llvm-project (by Alexander Kornienko):
Fix -Wformat diagnostic after #190965 (#193704)
Fixes libunwind compiler diagnostic when building with clang after
034d4dcad6396d1241e8262e69871b8d61da7e4f:
```
In file included from libunwind/src/libunwind.cpp:31:
In file included from libunwind/src/UnwindCursor.hpp:52:
libunwind/src/CompactUnwinder.hpp:339:46: error: format specifies type 'unsigned long long' but the argument has type 'uint64_t' (aka 'unsigned long') [-Werror,-Wformat]
338 | "function starting at 0x%llX",
| ~~~~
| %lX
339 | compactEncoding, functionStart);
| ^~~~~~~~~~~~~
libunwind/src/config.h:215:63: note: expanded from macro '_LIBUNWIND_DEBUG_LOG'
215 | #define _LIBUNWIND_DEBUG_LOG(msg, ...) _LIBUNWIND_LOG(msg, __VA_ARGS__)
| ~~~ ^~~~~~~~~~~
libunwind/src/config.h:181:45: note: expanded from macro '_LIBUNWIND_LOG'
[23 lines not shown]
