vmimage.subr: Add ability to install src in VM image
In some cases having a src tree in a VM image is convenient
for development or debugging. Add a WITH_SRC variable,
which, when set, will cause the vm-release target to include
FreeBSD-set-src in the list of packages installed in an image.
Signed-off-by: Krzysztof Galazka <krzysztof.galazka at intel.com>
Sponsored by: Intel Corporation
Reviewed by: cperciva
MFC after: 2 weeks
Differential Revision: https://reviews.freebsd.org/D57143
hosts.equiv.5: correct nits to fix `mandoc -T lint` issues
- Rename `.Nm .rhosts` to `.Nm rhosts` to match the MLINK for the
manpage.
- Use `.Pa` instead of `.Nm` when discussing the paths for `.rhosts` and
`hosts.equiv.5` for explicitness and clarity.
Bump .Dd for the change.
MFC after: 1 week
(cherry picked from commit af864dd4a2df50021f8a48c218a1f5968dbbb0c1)
hosts.equiv.5: correct nits to fix `mandoc -T lint` issues
- Rename `.Nm .rhosts` to `.Nm rhosts` to match the MLINK for the
manpage.
- Use `.Pa` instead of `.Nm` when discussing the paths for `.rhosts` and
`hosts.equiv.5` for explicitness and clarity.
Bump .Dd for the change.
MFC after: 1 week
(cherry picked from commit af864dd4a2df50021f8a48c218a1f5968dbbb0c1)
security(7): fix `mandoc -T lint` complaints
- Add `.Nm` section for securelevel(7) to match corresponding MLINKS entry.
- Fix the spelling for mac(4) (the actual subsystem manpage is spelled out in
lowercase.
MFC after: 1 week
(cherry picked from commit 573a9e5764df04d2dbfb0cf174458936b0a97095)
OpenSSL: update MAINTAINERS/CODEOWNERS
I've been the quasi-defacto component maintainer for OpenSSL since
14.0-RELEASE. Make it official via CODEOWNERS/MAINTAINERS.
The goal is to help guide those interested in making changes in this
space to solicit my input with the new vendor import process and
coordinate fixes with upstream until things are at a point where most of
this is automated a system of automated checks and balances to confirm
that the updates being made to the component help maintain a security
supply chain for this given component.
Thank you benl and jkim for your past efforts in this component area.
Hopefully I can do my part to help improve this critical space further
as you both did in your respective tenures.
MFC after: 3 days
(cherry picked from commit 8f9aabbdbcd55b25b698bd762e8693d43f295bbd)
Remove all of /usr/tests/share/examples/... when MK_EXAMPLES == no
- Remove the generated files (`file1`).
- Remove the top-level example `Kyuafile`.
MFC after: 1 week
(cherry picked from commit fb7df70a479f7cf972073f3a779adba2b4517c31)
Preen/update list for share/examples/sound under `MK_EXAMPLES`
- Update sources to match current installed files list. This involved
adding and removing some example files.
- Sort the list alphabetically so it'll be easier to spot future updates.
MFC after: 1 week
(cherry picked from commit b9495bd8c13e95035366b4e699b9ebe9f3d5c543)
Remove all of /usr/tests/share/examples/... when MK_EXAMPLES == no
- Remove the generated files (`file1`).
- Remove the top-level example `Kyuafile`.
MFC after: 1 week
(cherry picked from commit fb7df70a479f7cf972073f3a779adba2b4517c31)
security(7): fix `mandoc -T lint` complaints
- Add `.Nm` section for securelevel(7) to match corresponding MLINKS entry.
- Fix the spelling for mac(4) (the actual subsystem manpage is spelled out in
lowercase.
MFC after: 1 week
(cherry picked from commit 573a9e5764df04d2dbfb0cf174458936b0a97095)
OpenSSL: update MAINTAINERS/CODEOWNERS
I've been the quasi-defacto component maintainer for OpenSSL since
14.0-RELEASE. Make it official via CODEOWNERS/MAINTAINERS.
The goal is to help guide those interested in making changes in this
space to solicit my input with the new vendor import process and
coordinate fixes with upstream until things are at a point where most of
this is automated a system of automated checks and balances to confirm
that the updates being made to the component help maintain a security
supply chain for this given component.
Thank you benl and jkim for your past efforts in this component area.
Hopefully I can do my part to help improve this critical space further
as you both did in your respective tenures.
MFC after: 3 days
(cherry picked from commit 8f9aabbdbcd55b25b698bd762e8693d43f295bbd)
jail: Don't double-free the current prison in kern_jail_set/get
Reported by: Yuxiang Yang, et al <yangyx22 at mails.tsinghua.edu.cn>
Discussed with: markj
(cherry picked from commit b52dc2067618fc73e8d4d20e4035d1a67a8b455d)
rc.d/routing: Silence errors for loopback routes
_loopback entry in `static_routes` ensures a loopback route
exists in all routing tables.
However, loopback routes may already be added by the kernel.
Therefore, re-adding them triggers an `EEXIST` error on every boot.
This change suppresses those harmless errors.
PR: 259553
MFC after: 1 week
Reviewed by: glebius, jlduran, markj
Differential Revision: https://reviews.freebsd.org/D57470
ice(4): Fix link speed after changing cable type
When interface was connected to a link partner with a cable
type limitting maximum supported speed, e.g. SFP+ cable
in 25G port, driver incorrectly saved a supported speed
as the user configured speed. This prevented interface
from using all supported speeds after switching cable to SFP28.
Link was established at 10G as supported by previously used
SFP+ cable. Don't set user requested speed unless actually
configured by an user, to allow automatic selection of highest
available speed. Only when user sets custom config
using advertise_speed sysctl save it and try
to apply after cable is changed.
Also don't save initial supported speeds if FW supports
reporting default PHY config.
Signed-off-by: Krzysztof Galazka <krzysztof.galazka at intel.com>
[4 lines not shown]
libpfctl: fix memory leak
When we snl_init_writer() we allocate memory in the struct snl_state in the struct pfctl_handle.
This memory was never released again, leading to a memory leak. We still
had a reference to the memory and would release it on pfctl_close()
(so valgrind did not detect it as a leak), but long-lived users (e.g.
bsnmpd) would eventually run out of memory.
Explicitly reset the snl_state when we're done to prevent this.
MFC after: 2 weeks
Sponsored by: Rubicon Communications, LLC ("Netgate")
libpfctl: retrieve family id only once
Look up the pfctl family id when we open the handle, rather than for
every function call.
This saves us a lot of netlink calls, at the expense of storing one
extra int in the handle.
Sponsored by: Rubicon Communications, LLC ("Netgate")
ice(4): Add support for new E810-XXV-2 adapters
Add two new subdevice IDs for E810-XXV-2 and E810-XXV-2 for OCP 3.0.
Signed-off-by: Krzysztof Galazka <krzysztof.galazka at intel.com>
Reviewed by: kbowling, erj, mateusz.moga_intel.com
Sponsored by: Intel Corporation
MFC after: 1 week
Differential Revision: https://reviews.freebsd.org/D54069
bhyve: Document vCPU range pinning
This change documents the recently introduced changes to -p
that allow users to specify CPU ranges instead of having to
specify each individual mapping.
While we're here, move the -p examples to the EXAMPLES section.
Reviewed by: bcr
MFC after: 2 weeks
Differential Revision: https://reviews.freebsd.org/D57480
Remove fips-module related diff
This particular change didn't come from upstream. It was added locally
in 7a991ecd1 when attempting to enable the fips provider with 3.0.
Given the fact that we no longer build the fips provider and the fips
provider build process (including sources) is very prescribed to
specific build steps and source versions, there's no reason why we need
to continue carrying around this diff anymore.
MFC after: 1 week
Signed-off-by: Enji Cooper <ngie at FreeBSD.org>
Update in preparation for 15.1-RELEASE
- Bump BRANCH to RELEASE
- Add the anticipated RELEASE announcement date
- Set a static __FreeBSD_version
Approved by: re (implicit)
Sponsored by: OpenSats Initiative
vt: Do not lock request comming from terminal
only those originated by mouse. Because the terminal surrounds
requests to vt(4) with locking.
Reported by: bz, adrian
Reviewed by: adrian, glebius
Approved by: glebius (mentor)
MFC after: 2 weeks
Differential Revision: https://reviews.freebsd.org/D57442
