Syncing from FreeBSD for 24.07.1 #335
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
- Add typical comments after device entries (copied from amd64 GENERIC) - Add an entry for 'device ada'. Normally this is pulled in via 'device sd', but is documented in ada(4) and can be used to include ATA/SATA disk support in a kernel without SCSI disk support. Reviewed by: imp Sponsored by: Chelsio Communications Differential Revision: https://reviews.freebsd.org/D44689 (cherry picked from commit a508f5d92a93cda11b0c68084dbb181f97e7f5f7)
The NVMe drivers are portable and are already included statically in GENERIC on other architectures such as aarch64 and riscv64. Reviewed by: imp Sponsored by: Chelsio Communications Differential Revision: https://reviews.freebsd.org/D44690 (cherry picked from commit 16e846fa1ed3c97419b55b292f77b0f4209f0875)
While here, adjust the sample setting for NVME_USE_NVD to use a non-default setting as is typical in entries in NOTES. Discussed with: imp Reviewed by: manu Sponsored by: Chelsio Communications Differential Revision: https://reviews.freebsd.org/D44691 (cherry picked from commit 8f7105a20697d47060dbedc966cf085a64aeced6)
Reviewed by: imp Differential Revision: https://reviews.freebsd.org/D44759 (cherry picked from commit b9c6fa339d9c7c90a1c0f9ebc000ecbde8873508)
This option is not specific to amd64 Reviewed by: imp Differential Revision: https://reviews.freebsd.org/D44779 (cherry picked from commit 9c3fd2c1c7b8887d2ffaf14c61b04c55657d68bf)
Reviewed by: imp Differential Revision: https://reviews.freebsd.org/D44780 (cherry picked from commit ff3569be6fe01839affdefa14f55cc03a1f4f9d0)
Reviewed by: imp Differential Revision: https://reviews.freebsd.org/D44781 (cherry picked from commit 1d51575980bd246c1583cd02df47278aac5b6f4c)
While here, add virtio_gpu Reviewed by: imp, emaste Differential Revision: https://reviews.freebsd.org/D44782 (cherry picked from commit 1f678b6ba215aad01a1610772c77af653a981601)
This avoids requiring both 'device hyperv' and 'options HYPERV' for kernel configs. Instead, just 'device hyperv' can now be used matching the kernel configuration used for amd64. Reviewed by: imp Differential Revision: https://reviews.freebsd.org/D44783 (cherry picked from commit e045163cce955c32332a02a8eb9a48f3c2cd3c3f)
Reviewed by: imp Differential Revision: https://reviews.freebsd.org/D44784 (cherry picked from commit 717b22e18ca249dee0ec858c6571f68e00008290)
Reviewed by: imp Differential Revision: https://reviews.freebsd.org/D44785 (cherry picked from commit b620daf63309f655546caa060ea79cb230e4c9bc)
This option is for this driver. Reviewed by: imp Differential Revision: https://reviews.freebsd.org/D44786 (cherry picked from commit 5ea0b89242dbc1e4d4bac16983291a7c3803f88e)
While here, reorder some of the entries using headers more aligned with sys/conf/NOTES. Also add a pointer from the amd64/i386 NOTES files to x86 NOTES. The "extra" ACPI device drivers were only present in i386 NOTES previously. Reviewed by: imp Differential Revision: https://reviews.freebsd.org/D44787 (cherry picked from commit 1f38677ba40b26b861e063e130117143c9342c5d)
This was used by the old iSCSI initiator, not the current one. Reported by: trasz (cherry picked from commit f3f04c4027a71421b38094bb22e3aa4710ddcc38)
Some drivers, e.g. if_enc(4), only allow one instance to be created, but the KPI ifc_attach_cloner() treat zero value of maxunit as not limited, aka IF_MAXUNIT. Introduce a new flag IFC_F_LIMITUNIT to indicate that the requested maxunit is limited and should be respected. Consumers should use the new flag if there is an intended limit. Reviewed by: glebius MFC after: 2 weeks Differential Revision: https://reviews.freebsd.org/D45757 (cherry picked from commit a2cac544a668d2834ed41986aca32b44b9819c89)
The cloner has the ability to limit the maximum unit. Employ it to do that rather than roll our own. No functional change intended. Reviewed by: kp MFC after: 2 weeks Differential Revision: https://reviews.freebsd.org/D45767 (cherry picked from commit 07d138afc7e5efee73368459dd047493713056cf)
Remove pre 4.6 code to define _Static_assert in terms of _COUNTER. We no longer need to support compilers this old (in fact support for all pre gcc 10 compilers has been removed in -current). This is a partial MFC of that work because removing this fixes a bug that's oft reported with -pedantic-errors and C++98 compilations. PR: 280382, 276738 Sponsored by: Netflix This is a direct commit to stable/14.
MFC after: 3 days Reviewed by: imp Pull Request: freebsd/freebsd-src#1300 (cherry picked from commit c2c6f08c8b47cfda79529e0a1016b8f7803c0ec8)
Update the man page descriptions so that apropos {console,keyboard}
finds more relevant man pages.
MFC after: 3 days
Reviewed by: imp, emase
Pull Request: freebsd/freebsd-src#1275
(cherry picked from commit 580dc180c7ebd84a4aee27938a5f4a62520ac5d9)
Update the man page descriptions so that apropos are more consistent for console related man pages. Motive: apropos results: clarify consistently MFC after: 3 days Reviewed by: emaste, imp Pull Request: freebsd/freebsd-src#1275 (cherry picked from commit de2ab11ff955faa32bfffe5b2401b444a7c138f2)
+ service routing restart breaks on dhcp + change my copyright from inbox to home Fixes: 75eda009 MFC after: 3 days Reported by: Graham Perrin, zlei Reviewed by: imp Pull Request: freebsd/freebsd-src#1316 (cherry picked from commit c55f56de9da11e11ee950993afe8b8575d8daa56)
Assume you have loader configured to load linux64, which has a dependency on both linux_common and mqueuefs but neither the kernel nor kernel config in question have the mqueuefs module included. When the load command for linux64 fails to find mqueuefs, it will free both linux64 and linux_common as they were loaded first, but only linux64 gets removed from the module list. As a result, future traversals hit an easy use-after-free with linux_common. Fix it so that we unlink the entire tail of the list. Anything after the initially loaded module is, by definition, a dependency on the loaded module while we're still in the load command, so we can just discard the entire tail. If linux_common were loaded before linux64, it should not move to a position during this load where it would suddenly be missing from the view presented to the kernel. Reported by: philip Reviewed by: imp, philip, tsoome (cherry picked from commit 3da568710fde08251996c117b87bedb326dedb57)
The kern.arandom sysctl handler uses an intermediate buffer on the stack to hold random data that it subsequently copies out to the sysctl request. Err on the side of caution and zero out the stack buffer after we're done with it to avoid a potential entropy leak later on. Reviewed by: cem, emaste, markj (cherry picked from commit 5862c891bb7c588aa00538d85eb26ffe77d3f709)
(cherry picked from commit 616dd88a2e68c1243e4c8b57e883742937a61af0)
(cherry picked from commit 10a6ae0ddffb1de842a0ba6a6ca29786de6d3bfd)
(cherry picked from commit 45cde0e439188589ca2511f6fd76829cbf68267e)
(cherry picked from commit 7773023b72de19c6c9a47fd04ac955ec52773f0f)
MFC after: 1 week (cherry picked from commit 6ac0f711ad9ecd9ac1525787bb08002c85c03cde)
On Feb. 28, a problem was reported on freebsd-stable@ where a nfsd thread processing an ExchangeID operation was blocked for a long time by another nfsd thread performing a copy_file_range. This occurred because the copy_file_range was taking a long time, but also because handling a clientID requires that all other nfsd threads be blocked via an exclusive lock, as required by ExchangeID. This patch adds two arguments to nfsv4_cleanclient() so that it can optionally be called with a mutex held. For this patch, the first of these arguments is "false" and, as such, there is no change in semantics. However, this change will allow a future commit to modify handling of the clientID so that it can be done with a mutex held while other nfsd threads continue to process NFS RPCs. (cherry picked from commit a7de51068502ad1e2851d4a855ed28b27573bb36)
No functional change intended. MFC after: 1 week Sponsored by: Innovate UK (cherry picked from commit f6372351da07ae101d5a22a2bb2bdb2753da2b40)
MFC after: 1 week (cherry picked from commit 9cc67e43610e34a692398a65adcc5e8846e84250)
Under certain circumstances it may call log(3), which is not async- signal-safe. For now just remove the blacklist integration from this path, which means that blacklistd will not detect and firewall hosts that establish a connection but do nothing further. Sponsored by: The FreeBSD Foundation Differential Revision: https://reviews.freebsd.org/D46203 (cherry picked from commit 2739a6845031e69be7c03461a9335d8bbb9f59bd) (cherry picked from commit 3d3bae9b95388169d396adc8007585699c5a23e0) Approved by: so
LLVM bugzilla bug 8100 became issue #8472 with the migration to GitHub. llvm/llvm-project#8472 (cherry picked from commit 92927b8bcf51dcbcf99d633c1b3cab3cab2373ac)
Obtained from: NetBSD (cherry picked from commit 001606523a48ca2aa440c985db47327a00671358)
If the object directory prefix does not exist, make.py previously exited with a message indicating that the chosen prefix does not exit. Reviewed by: emaste Pull request: freebsd/freebsd-src#1348 (cherry picked from commit d55de30efd09ee011bf4604be1c15ce4155775c1)
> These tests increase the build time (albeit by a small amount), so > they should be removed once enough time has passed and it is extremely > unlikely anyone would try a NO_CLEAN build against an object tree from > before the related change. The comment suggests a year is a reasonable period but we'll be somewhat more conservative for now, in part so that we retain different examples of special cases. Reviewed by: brooks, imp Sponsored by: The FreeBSD Foundation Differential Revision: https://reviews.freebsd.org/D46178 (cherry picked from commit 4a06d149371c16287e1dd5a8fa51e92346a0c3f4)
These ones were unambiguous cases where the Foundation was the only listed copyright holder. Sponsored by: The FreeBSD Foundation (cherry picked from commit 5c2bc3db201a4fe8d7911cf816bea104d5dc2138)
This is a fixed version of 888796ade284. PR: 277783 Reported by: Victor Stinner Reviewed by: emaste MFC after: 1 week (cherry picked from commit 888796ade2842486d3167067e8034254c38aadd3) (cherry picked from commit e77ad954bb825983b4346b9cc646c9c910b1be24) (cherry picked from commit 34f746cc7f8a8dd261027a8b392b76e70adc8438)
We are not 100% compatible with 1.0.16, but implement some functionality from that version that is required by certain ports. PR: 277799 PR: 279555 (exp-run) Event: Kitchener-Waterloo Hackathon 202406 Sponsored by: The FreeBSD Foundation Differential Revision: https://reviews.freebsd.org/D45514 (cherry picked from commit 5654b42142e1f689b26d405c90379b85f22349a0)
fsn_included should only be considered, if first_frag_seen is true. Also, fix the resetting of the control structure, if stream queues are flushed. This fixes a bug where a legitimate message sequence was incorrectly classified as illegitimate. Thanks to Victor Boivie for reporting the issue on the userland stack. (cherry picked from commit 101a0f09e8baf8293e1eeb591de18caf15e49e00)
Approved by: so Security: FreeBSD-24:06.ktrace Security: CVE-2024-6760 Fixes: 1762f67 ("ktrace: pack all ktrace parameters into allocated structure ktr_io_params") (cherry picked from commit 166b7573b5220aadf8b02a85933c9651b909b309)
An overread condition in memccpy(dst, src, c, len) would occur if
src does not cross a 16 byte boundary and there is no instance of
c between *src and the next 16 byte boundary. This could cause a
read fault if src is just before the end of a page and the next page
is unmapped or unreadable.
The bug is a consequence of basing memccpy() on the strlcpy() code:
whereas strlcpy() assumes that src is a nul-terminated string and
hence a terminator is always present, c may not be present at all in
the source string. It was not caught earlier due to insufficient
unit test design.
As a part of the fix, the function is refactored such that the runt
case (buffer length from last alignment boundary between 1 and 32 B)
is handled separately. This reduces the number of conditional
branches on all code paths and simplifies the handling of early
matches in the non-runt case. Performance is improved slightly.
os: FreeBSD
arch: amd64
cpu: 11th Gen Intel(R) Core(TM) i7-1165G7 @ 2.80GHz
│ memccpy.unfixed.out │ memccpy.fixed.out │
│ sec/op │ sec/op vs base │
Short 66.76µ ± 0% 62.45µ ± 1% -6.44% (p=0.000 n=20)
Mid 7.938µ ± 0% 7.967µ ± 0% +0.36% (p=0.001 n=20)
Long 3.577µ ± 0% 3.577µ ± 0% ~ (p=0.429 n=20)
geomean 12.38µ 12.12µ -2.08%
│ memccpy.unfixed.out │ memccpy.fixed.out │
│ B/s │ B/s vs base │
Short 1.744Gi ± 0% 1.864Gi ± 1% +6.89% (p=0.000 n=20)
Mid 14.67Gi ± 0% 14.61Gi ± 0% -0.36% (p=0.001 n=20)
Long 32.55Gi ± 0% 32.55Gi ± 0% ~ (p=0.429 n=20)
geomean 9.407Gi 9.606Gi +2.12%
Reported by: getz
Reviewed by: getz
Approved by: mjg (blanket, via IRC)
See also: D46051
MFC: stable/14
Event: GSoC 2024
Differential Revision: https://reviews.freebsd.org/D46052
Improve wording and also fix the constants' names. Sponsored by: The FreeBSD Foundation MFC after: 2 days Reviewed by: dev_submerge.ch Differential Revision: https://reviews.freebsd.org/D46220 (cherry picked from commit 6e744de1a3dc5dde8d2ee51e97a1224a01bdfb21)
To make parsing of, for example, Spamhaus' drop.txt and similar files that contains semicolons as comments, allow them also in file-based tables. Reviewed by: kp MFC after: 2 weeks Differential Revision: https://reviews.freebsd.org/D46088 (cherry picked from commit a8a95277363be2c92b3c06bd9cd1a32d1c6c6ecd)
This was done in the original DTrace import, presumably because that made it a bit easier to handle includes. However, this can cause dtrace_getpcstack() to be inlined into dtrace_probe(), resulting in a missing frame in stack traces since dtrace_getpcstack() takes care to bump "aframes" to account for its own stack frame. To avoid this, compile dtrace_isa.c separately on all platforms. Add requisite includes. MFC after: 2 weeks Sponsored by: Innovate UK (cherry picked from commit 82283cad12a417abfb1469d899b2d7cfb1d38f77)
Previously, when transmitting short runs of packets via cxgbe_nm_tx(), we would wait until a large number of packets were buffered before scheduling a task to clean transmit buffers. Obtained from: np (cherry picked from commit 6af3d59962449c66688361598163dd174cc5fb2a)
The nd6 code listens for RTM_DELETE events so that it can mark the corresponding default router as inactive in the case where the default route is deleted. A subsequent RA from the router may then reinstall the default route. Commit fedeb08 broke this for non-multipath routes, as rib_decompose_notification() only invokes the callback for multipath routes. Restore the old behaviour. Also ensure that we update the router only for RTM_DELETE notifications, lost in commit 2259a03. Reviewed by: bz Fixes: fedeb08 ("Introduce scalable route multipath.") Fixes: 2259a03 ("Rework part of routing code to reduce difference to D26449.") MFC after: 2 weeks Sponsored by: Klara, Inc. Sponsored by: Bell Tower Integration Differential Revision: https://reviews.freebsd.org/D46020 (cherry picked from commit a48df53e4249499be3e8779dd30888a405aa81ae)
This serves as a regression test for commit a48df53e4249. Reviewed by: bz, allanjude MFC after: 2 weeks Sponsored by: Klara, Inc. Sponsored by: Bell Tower Integration Differential Revision: https://reviews.freebsd.org/D46136 (cherry picked from commit feda329622bc77ab64ae5f0bf852743f4a037616)
Passing overlapping buffers to strcpy yields an undefined result, so let's avoid it. The copy doesn't really need to happen anyways, we can just point to the domain part of the hostname. This was discovered with _FORTIFY_SOURCE. Sponsored by: Klara, Inc. Sponsored by: Stormshield Reviewed by: allanjude, emaste, imp, melifaro (all previous version) (cherry picked from commit 158f319428c10143ce2ffe766416207c75578931)
As of e67975d ("Fix 'calendar -a' in several ways."), `calendar -a` will now fork off a new process for each user and do all of its own processing in the user's own context. As a side-effect, calendar(1) started calling setlogin(2) in each of the forked processes and inadvertently hijacked the login name for the session it was running under, which was typically not a fresh session but rather that of whatever cron/periodic run spawned it. Thus, daily and security e-mails started coming from completely arbitrary user. We could create a new session, but it appears that nothing calendar(1) does really needs the login name to be clobbered; opt to just avoid the setlogin(2) call entirely rather than incur the overhead of a new session for each process. PR: 280418 Reviewed by: des, olce Fixes: e67975d ("Fix 'calendar -a' in several ways.") (cherry picked from commit 6cb8b61efe8899ee9194563108d0ae90c1eb89e3)
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
No description provided.