Define this helper variable in one place and make it available while
building the entire base system.
Reviewed by: sjg
Obtained from: CheriBSD (mostly)
Differential Revision: https://reviews.freebsd.org/D53790
Clear the RSS hash on transmit, now that RSS hashing is enabled
unconditionally, and the network stack may want to trust that
it is getting the correct hash on input.
Differential Revision: https://reviews.freebsd.org/D53090
Reviewed by: zlei
Sponsored by: Netflix
When in restricted mode, the slirp-helper process enters a capsicum
sandbox, after which we cannot look up the uid for the "nobody" user.
Reverse the order.
Reported by: kp
Fixes: 0e62ebd201 ("bhyve: Move the slirp backend out into a separate process")
Otherwise etcupdate apparently can fail if its private object directory
under /var/db is in a filesystem mounted noexec. We shouldn't be
building this target at all, but for now, just apply this workaround.
PR: 291043
Reviewed by: ivy, cy, des
MFC after: 1 week
Differential Revision: https://reviews.freebsd.org/D53861
In arch_fix_auxv(), remove local variable shadowing the argument,
remove write-only variable, and declare the loop variable.
The wrong patch was committed after series of local reverts and
re-apply.
Fixes: b2b3d2a962
Sponsored by: The FreeBSD Foundation
MFC after: 1 week
* Always install the manual page as pam_krb5(8) regardless of which
version we're using.
* Regenerate it using pod2mdoc instead of pod2man so it doesn't claim
to be part of “User Contributed Perl Documentation”.
* Put the correct section number in the header and footer.
* Don't cross-reference non-existent pam(7) manual page.
Reviewed by: cperciva
Differential Revision: https://reviews.freebsd.org/D53885
Not only does the new pam_krb5 module not have the same allow_kdc_spoof
option that the old one had, its behavior in this matter defaults to
insecure. Reimplement allow_kdc_spoof and switch the default back.
Reviewed by: cy
Differential Revision: https://reviews.freebsd.org/D53884
[Driver] Enable outline atomics for FreeBSD/aarch64 (#156089)
The compiler_rt helper functions have been built since 12.4, 13.1, 14
and anything newer.
This reverts commit bd27bd1f51.
Only some people (including the release manager, unfortunately) ran into
build issues with the previous iteration of this commit, because they
were bootstrapping the compiler, either via the WITHOUT_SYSTEM_COMPILER
src.conf(5) setting, or because the build system determined that their
base system compiler was out of date.
The bootstrapped compiler would then enable outline atomics and compile
libgcc_s with these, but because libgcc_s is linked with -nodefaultlibs,
it could not find the helper routines in libcompiler_rt.a.
In contrast, people who did not bootstrap the compiler never saw any
issues, because libgcc_s was built using their 'old' base system
compiler, and so libgcc_s would not contain any calls to those helper
routines.
Fix this by ensuring that libgcc_s is linked against libcompiler_rt.a
explicitly, similar to some other binaries and libraries that are built
with -nodefaultlibs.
Also, bump FREEBSD_CC_VERSION to ensure that everybody gets the updated
compiler with outline atomics enabled. (This should have been done in
the first iteration of this commit, because the error would have shown
up right away then.)
MFC after: 3 days
The register set information is stored as a singleton in
GetRegisterInfo_i386. However, other functions later access this
information assuming it is stored in GetSharedRegisterInfoVector. To
resolve this inconsistency, we remove the original construction logic
and instead initialize the singleton using llvm::call_once within the
appropriate function (GetSharedRegisterInfoVector_i386).
PR: 289945
Obtained from: llvm-project 41859c27842eeda1ef6ff18f3b2fb269388c0857
Currently, LLDB in FreeBSD host sets the Process Architecture used by
lldbserver as Default one. Which cause problem when trying to debug a
32bit binary on amd64 platform since the lldb itself will found mismatch
architecture with lldbserver's return.
Notice that this patch is only a partial fix for the debugging problem.
We are still unable to debug x86 on x86_64 so that we don't provide
testcase in this patch.
PR: 289945
Obtained from: llvm-project 394e7ded8b6bcff1382468b407ca620a2837f41b
It turns out that snd_uaudio(4) uses sound(4)'s channel lock for its USB
transfer callbacks. I will try to address this at some point, because
this is layering violation, but for now we need to revert the commit, as
it causes a lock recursion panic with USB audio devices.
This reverts commit e254ef87a3.
Contrary to the claim made in a previous commit, removing KDE and
adding all of vim and emacs results in an image which does not fit
into 4.7 GB; to be specific, it lands at 4.722 GB rather than the
claimed 4.689 GB. (This descrepancy resulted from doing test DVD
image builds using an out-of-date tree, and became visible when the
15.0-RC3 images were built.)
Limit the emacs packages shipped on the DVD to the "nox" flavor;
this brings the disk image down to 4.407 GB, aka under the 4.7 GB
limit for standard DVDs.
Fixes: 6cc6beb4c8 ("release: Remove KDE from dvd1.iso")
MFC after: 1 day (for 15.0-RC4)
This key was generated by gordon@ (aka security-officer@) on an offline
system as a backup key should anything happen to the AWS Key
Management Service that is currently in use for signing pkgbase
repositories for FreeBSD 15.x.
Reviewed by: cperciva
With hat: so
It's not clear what the race described in the commit actually is, nor
how it could arise, but this commit is definitely wrong; curthread is no
longer set for intr_pic_init_secondary, and gic_v3's pic_init_secondary
uses mutex(9) in some places, which requires curthread, so it has led to
panics. Revert this change until the original issue this was intended to
be fixed can be more thorougly investigated and a better fix made.
Reported by: Herbert J. Skuhra <herbert@gojira.at>, jhb
This reverts commit a695ac2ce8.
Rockchip have two erratas (#3568001 and #3568002) for the GIC on RK356x.
Until we have a way to handle them revert the changes that uses ITS instead of
GIC for PCIe.
Sort usage and man page options, mention possible minimum and maximum
values, fix punctuation marks, and cleanup the man page.
PR: 291092
Reviewed by: pauamma_gundo.com, christos
MFC after: 1 week
Differential Revision: https://reviews.freebsd.org/D53827
Add guards against attempting to process a user data file with an empty
first line or contents.
PR: 290395
Reviewed by: bapt (earlier), dtxdf, markj
MFC after: 3 days
Differential Revision: https://reviews.freebsd.org/D53239
Now that we can trust NICs to supply an identical hash result
to software, we can setup the inpcb hash on outgoing connections.
This gives us symmetric hashing, meaning packets should enter
and leave on the same NIC queue.
Differential Revision: https://reviews.freebsd.org/D53104
Reviewed by: adrian, cc, kbowling, tuexen, zlei
Sponsored by: Netflix
We use the fact that all NICs that support hashing are using the
same hash algorithm and hash key to enable symmetic hashing in
TCP, where a software version of the same hash is used to
establish hashes on outgoing connections.
Sponsored by: Netflix
Reviewed by: adrian, zlei (both early version)
Differential Revision: https://reviews.freebsd.org/D53089
- Add several missing .Pp after lists and literal blocks.
- Fix the column widths for the console table and use a shorter indent
so that it doesn't wrap on an 80-col display.
Reviewed by: imp
Differential Revision: https://reviews.freebsd.org/D53866
When the source of the copy operation is the root directory, we should
neither append it to the destination path on FTS_D nor trim it back off
on FTS_DP.
PR: 291132
MFC after: 3 days
Fixes: 82fc0d09e8 ("cp: Partly restore symlink folllowing.")
Reviewed by: markj
Differential Revision: https://reviews.freebsd.org/D53863
John Baldwin