sys/abi_types.h: time32_t is 64-bit on non-x86 architectures
As long as 'sys/compat/freebsd32/freebsd32.h' is used unconditionally on
all platforms (in 'kern_umtx.c' at least), the rule of thumb is to
ensure that 'struct foo32' on a 32-bit arch is type-compatible with
'struct foo' on the same arch. In practice, this is very simple to
achieve: All 'foo32' types should be compatible with 'foo' on 32-bit
architectures, which is what we are supposed to do already for compat'
structures by design. The recently introduced 'freebsd32_uint64_t' type
typically supports that.
This change fixes commit 87632ddf67b0 ("openzfs sys/types32.h: use
abi_compat.h for time32_t") which was defining 'time32_t' to 'in32_t'
for all 32-bit architectures, which is wrong but on i386. By luck, this
did not change the size of whole 'struct ffclock_estimate32' (whose size
is compile-time asserted) because 'struct bintime32''s one would stay
the same, as even if its field 'sec' was incorrectly sized after that
commit, the 'frac' one is 64-bit and 64-bit aligned on all non-x86
architectures so its offset in 'struct bintime32' would stay the same.
[5 lines not shown]
sys/compat/freebsd32: FF clock struct: Don't pack, use 'ffcounter32'
Packing 'struct ffclock_estimate32', in absence of substitution of
'ffcounter' (some 'uint64_t') by a 32-bit compatible type, was necessary
on amd64 since 'uint64_t' is 8-byte aligned, which leaves a padding gap
of 4-byte between fields 'update_time' and 'update_ffcount'. This gap
does not exist on i386 (or amd64 32-bit mode), as 'uint64_t' there is
only 4-byte aligned.
Change the type of the 'update_ffcount' and 'leapsec_next' fields to the
recently introduced 'freebsd32_uint64_t', and adapt copy-in and copy-out
accordingly. Using `CP()` previously worked due to the '__packed__'
attribute.
Reviewed by: kib
MFC after: 2 weeks
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D55282
lagg: Avoid dropping locks when starting the interface
The init routine of a lagg(4) interface will not change during the whole
lifecycle. So we can call lagg_init() directly instead of through the
function pointer. Well, that requires a drop and pickup lock, which
unnecessarily expose a small race window. Refactor lagg_init() into
lagg_init_locked() and call the later one to avoid that.
Meanwhile, delay updating the driver managed status until after the
interface is really ready.
Reviewed by: markj
MFC after: 5 days
Differential Revision: https://reviews.freebsd.org/D55198
(cherry picked from commit c182cf646a4f995fa8506afd8afc9541c4d32905)
lagg: Make lagg_link_active() static
It is declared as static. Make the definition consistent with the
declaration.
It was ever fixed by commit 52e53e2de0ec, but the commit was reverted,
leaving it unfixed.
No functional change intended.
MFC after: 3 days
(cherry picked from commit 30988d0a7bd7ebd5f5825b9b7aa04ff0af788aa7)
libusb: dequeue next transfer on completion to prevent stalls
The transfer proxy callbacks (bulk/interrupt, control, isochronous)
only called libusb10_submit_transfer_sub() in the START path to
pipeline the second kernel transfer slot. On completion or error,
no attempt was made to dequeue the next pending transfer from
tr_head onto the now-free slot.
When more than two async transfers were submitted on the same
endpoint, the third (and subsequent) transfers would remain stuck
on tr_head indefinitely, since no completion ever triggered their
submission. This caused a protocol-level deadlock in applications
like adb that submit header + payload + zero-length terminator as
three separate bulk transfers in sequence.
Fix by calling libusb10_submit_transfer_sub() after every
libusb10_complete_transfer() in all three proxy callbacks.
MFC After: 2 weeks
[2 lines not shown]
ichsmb: Add Intel Raptor Lake SMBus controller support
Add PCI device ID 0x7a23 for Intel 700 Series (Raptor Lake) chipset SMBus controller.
This enables hardware monitoring functionality on 13th and 14th generation Intel Core platforms.
Reviewed by: adrian
Differential Revision: https://reviews.freebsd.org/D54957
runat: Add -h to manipulate a symlink's named attribute dir
Lionel Cons <lionelcons1972 at gmail.com> requested
that a new option be added to runat(1) so that it could
be used to manipulate named attributes associated with
a symbolic link and not the file the symbolic link refers to).
This patch adds the option -h/--nofollow to do this.
(cherry picked from commit 4bfb7cfb70e62bc316de9e73cfd63a5c85541154)
t_access.c: remove unnecessary local modification
FreeBSD 11.x is no longer supported; there's no reason why the
`FreeBSD_version__` check is still required (now).
MFC after: 1 week
libnetbsd: import the `__nothing` macro
This macro is widely used in new NetBSD tests. Please see the comment
next to the imported macro for more details on its use.
Obtained from: NetBSD (c26cc77b3a0b2)
MFC after: 1 week
t_create.sh: use `ATF_TESTS_SH_SED` & remove local mods
This particular change replaces all local modifications to the test
script like so:
- Use `ATF_TESTS_SH_SED_test` with a sed(1) statement in the Makefile,
instead of the equivalent local modifications.
- Remove the need for expecting the output of newfs_msdos to be empty.
There isn't much to gain from deviating from the upstream NetBSD test--it's
just another local modification that would need to be carried forward. If
it's worth testing this FreeBSD-specific behavior, it should be in a
FreeBSD-specific test.
This makes moving new modifications to the script easier moving forward.
MFC after: 1 week
Revert "stand: compile ia32 EFI loader with -malign-double"
The loader shares types with various libraries that don't compile with
this flag. Revert for now.
Reported by: jrtc27
stand: compile ia32 EFI loader with -malign-double
The UEFI spec says:
> Structures are aligned on boundaries equal to the largest internal
> datum of the structure and internal data are implicitly padded to
> achieve natural alignment.
By default, structs containing members of type "long long" have 4 byte
alignment on i386. This caused some EFI structures to be subtly wrong.
Fix this by compiling the ia32 EFI loader with -malign-double, which
bumps the alignment up to 8 if such members are present.
MFC after: 3 days
daemon: Add option for output file mode
The daemon utility has always created its output file with a fixed mode
of 0600. This causes issues for log collection setups where the collector
does not run as root but instead relies on group access to the watched
daemon’s log file.
Introduce a new option that allows specifying the output file mode using
install(1)-style semantics. This enables non-root log collectors to access
the file as intended and improves compatibility with log rotation tools.
Reviewed by: kevans
MFC after: 1 week
Relnotes: yes
Differential Revision: https://reviews.freebsd.org/D54930
(cherry picked from commit a3b90a1f008365d9f62773998f89f9c872e2bed5)
daemon: Add option for output file mode
The daemon utility has always created its output file with a fixed mode
of 0600. This causes issues for log collection setups where the collector
does not run as root but instead relies on group access to the watched
daemon’s log file.
Introduce a new option that allows specifying the output file mode using
install(1)-style semantics. This enables non-root log collectors to access
the file as intended and improves compatibility with log rotation tools.
Reviewed by: kevans
MFC after: 1 week
Relnotes: yes
Differential Revision: https://reviews.freebsd.org/D54930
(cherry picked from commit a3b90a1f008365d9f62773998f89f9c872e2bed5)
daemon: Add option for output file mode
The daemon utility has always created its output file with a fixed mode
of 0600. This causes issues for log collection setups where the collector
does not run as root but instead relies on group access to the watched
daemon’s log file.
Introduce a new option that allows specifying the output file mode using
install(1)-style semantics. This enables non-root log collectors to access
the file as intended and improves compatibility with log rotation tools.
Reviewed by: kevans
MFC after: 1 week
Relnotes: yes
Differential Revision: https://reviews.freebsd.org/D54930
(cherry picked from commit a3b90a1f008365d9f62773998f89f9c872e2bed5)
diff: Improve directory loop detection
When we're done processing a directory, remove its entry from the tree
of visited inodes, ensuring that we only report a loop when we encounter
a descendant-to-ancestor link, not when we encounter a cousin-to-cousin
or sibling-to-sibling link.
MFC after: 1 week
Reported by: Bakul Shah <bakul at iitbombay.org>
Sponsored by: Klara, Inc.
Reviewed by: kevans
Differential Revision: https://reviews.freebsd.org/D55248
(cherry picked from commit 71569594d860a59d8362770a56d806e1d31fb946)
