-
Notifications
You must be signed in to change notification settings - Fork 32
Sync with FreeBSD stable/14 for 25.01.1 #350
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Merged
Conversation
This file contains hidden or 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
shm_alloc() can fail if swap reservation fails (i.e., vm.overcommit is non-zero) or racct is imposing some limits on swap usage. PR: 282994 MFC after: 2 weeks Reviewed by: olce, kib Differential Revision: https://reviews.freebsd.org/D47839 (cherry picked from commit f3b7dbd)
(cherry picked from commit 58d1fdf)
File system specific *fid structures are copied into the generic struct fid defined in sys/mount.h. As such, they cannot be larger than struct fid. This patch adds _Static_assert()s to check for this. ZFS and fuse already have _Static_assert()s. (cherry picked from commit 91b5592)
Fix two proto name typos MFC after: 2 weeks (cherry picked from commit 7aa7f4b)
Allow the creation of '!0' partition types. Fix it by not considering "0" an invalid partition type. Reviewed by: emaste Approved by: emaste (mentor) MFC after: 1 month Differential Revision: https://reviews.freebsd.org/D47652 (cherry picked from commit accf715)
The bsdlabel utility is deprecated, gpart should be used instead: - Offset the first 16 sectors, just like bsdlabel did (used for metadata) - Use a freebsd-ufs partition type (regardless bsdlabel creating a '!0') Reviewed by: emaste, imp Approved by: emaste (mentor) MFC after: 1 month Differential Revision: https://reviews.freebsd.org/D47653 (cherry picked from commit 87e87fe)
USB_GET_REPORT ioctl is documented to update ugd_actlen on return with the number of bytes copied. It does not do this. Reviewed by: wulf PR: 282790 MFC after: 1 week (cherry picked from commit 0b5d86b)
HIDRAW_GET_REPORT ioctl is documented to update hgd_actlen on return with the number of bytes copied. It does not do this. Reviewed by: wulf PR: 282790 MFC after: 1 week (cherry picked from commit f4f46a2)
Required firmware files are already included in to comms/iwmbt-firmware port Sponsored by: Future Crew LLC MFC after: 1 month Reviewed by: bz Differential Revision: https://reviews.freebsd.org/D46735 (cherry picked from commit c1643ce)
If Intel firmware is already in operational mode at boot that takes place at warm boot, BT adaptor can generate extra HCI events which interferes with firmware mode detection logic. Ignore them. Sponsored by: Future Crew LLC MFC after: 1 month Differential Revision: https://reviews.freebsd.org/D46737 (cherry picked from commit aa0b938)
Attempt to initialize FreeBSD bluetooth stack while such a device is in bootloader mode locks the adapter hardly so it requires power on/off cycle to restore. This change blocks ng_ubt attachment unless operational firmware is loaded thus preventing the lock up. Sponsored by: Future Crew LLC MFC after: 1 month Differential Revision: https://reviews.freebsd.org/D46738 (cherry picked from commit 24ae172)
with operational mode firmware. Sponsored by: Future Crew LLC MFC after: 1 month Reviewed by: bz Differential Revision: https://reviews.freebsd.org/D46734 (cherry picked from commit 19a577e)
Firmware files are available in the comms/rtlbt-firmware port. Sponsored by: Future Crew LLC MFC after: 1 month Differential Revision: https://reviews.freebsd.org/D46739 (cherry picked from commit 5036d96)
If Intel firmware is already in operational mode at boot that takes place at warm boot, BT adaptor can generate extra HCI events which interferes with firmware mode detection logic. Ignore them. Sponsored by: Future Crew LLC MFC after: 1 month Reviewed by: bz Differential Revision: https://reviews.freebsd.org/D46736 (cherry picked from commit 0b23c50)
Reviewed by: emaste, trasz Differential Revision: https://reviews.freebsd.org/D47262 (cherry picked from commit 3df1abd)
(cherry picked from commit 3b35e7e)
(cherry picked from commit 2674340)
(cherry picked from commit ae316d1)
The 2.6.1 - 2.6.3 releases address several security issues with the library. The release notes for the 2.6.1-2.6.3 releases can be found at https://github.com/libexpat/libexpat/blob/R_2_6_3/expat/Changes . Differential Revision: https://reviews.freebsd.org/D46829 Merge commit '8e1eae2319cd3a651941c88b46d95e8ee8507c6c' (cherry picked from commit ffd294a)
This change updates the version of expat referenced from 2.6.0 to 2.6.3, correcting documentation post-ffd294a1f4c23863c3e515d16dce31d5509bcb01. Bump .Dd for the change. MFC with: ffd294a Differential Revision: https://reviews.freebsd.org/D46865 (cherry picked from commit ba23ab2)
(cherry picked from commit 908f215)
(cherry picked from commit c77c488)
PR: bin/276106 (cherry picked from commit e23954b)
PR: bin/276107 (cherry picked from commit 1fb3cae)
When aborting command waiting in restart queue remove it from the queue before freeing it. This should fix NULL dereference panics we saw on some very busy system. MFC after: 2 weeks (cherry picked from commit 40fb1b8)
- When handling notify acknowledge from target code for task abort request, not only send abort to the firmware, but also delete the ATIO private data associated with the command. It is required for proper tag reuse, allowing new "conflicting" commands to be passed to the target. CTL was already fixed to handle that right, instead of delaying them in restart queue of the driver. - When target finally aborts the command (which it should have done before the notify ack) we should not send another abort to the firmware. Since we already sent the abort and deleted ATIO private data above, just return successful completion here, doing nothing. Since the tag can be reused by that time, we can not rely on its uniqueness, so when searching to the ATIO private data compare also the aborted CCB pointer in addition to the tag. - Fix BA_RJT sending in isp_acknak_abts(). While it should be rare, teach the code to send error responses for ABTS requests. MFC after: 2 weeks (cherry picked from commit ec3175f)
(cherry picked from commit ac3dedf)
(cherry picked from commit c4ca1d2)
PR: 283015 Reviewed by: bz MFC after: 1 week Fixes: 0936c64 ("LinuxKPI: 802.11: update the ni/lsta reference cycle") Differential Revision: https://reviews.freebsd.org/D47949 (cherry picked from commit 9269057)
ipfw.d requires definitions of, at least, in_addr_t and struct ip6_addr, which it must obtain from CTF info. This is found by looking at $(sysctl -n kern.bootfile)/kernel, which might not be available in a jail. These depends_on declarations ensure that dtrace(1) invocations will simply abort processing of ipfw.d if the required binaries can't be found, rather than raising an error. PR: 283359 MFC after: 1 week (cherry picked from commit b64c5a0)
Ensure we update the mbuf pointer returned by pf_normalize_ip() or pf_normalize_ip6() even if they fail. Otherwise we'd risk using a freed mbuf. PR: 283705 Reported by: Yichen Chai <[email protected]>, Zhuo Ying Jiang Li <[email protected]> Sponsored by: Rubicon Communications, LLC ("Netgate") (cherry picked from commit 5d28f4c)
Unusually, the FUSE_NOTIFY_INVAL_INODE and FUSE_NOTIFY_INVAL_ENTRY messages are fully asynchronous. The server sends them to the kernel unsolicited. That means that unlike every other fuse message coming from the server, these two arrive to a potentially unbusied mountpoint. So they must explicitly busy it. Otherwise a page fault could result if the mountpoint were being unmounted. Reported by: [email protected] (cherry picked from commit 9899985)
[skip ci] Sponsored by: ConnectWise Reviewed by: markj Differential Revision: https://reviews.freebsd.org/D48125 (cherry picked from commit 22bb70a)
Every fuse ticket has a "unique" token. As the name implies, they're supposed to be unique. Previously the fusefs test suite verified their uniqueness by relying on the fact that they are also sequential. But they aren't guaranteed to be sequential. Enhance the tests by removing that convenient assumption. Sponsored by: Axcient (cherry picked from commit b187997)
Even on a riscv embedded system, the fusefs tests run fast enough that 10 seconds is a reasonable timeout. [skip ci] Sponsored by: ConnectWise (cherry picked from commit 53f73aa)
The FUSE_NO_OPEN_SUPPORT and FUSE_NO_OPENDIR_SUPPORT flags are only meant to indicate kernel features, and should be ignored if they appear in the FUSE_INIT reply flags. Also fix the corresponding test cases. Reviewed by: Alan Somers <[email protected]> Signed-off-by: CismonX <[email protected]> Pull Request: freebsd/freebsd-src#1509 (cherry picked from commit f0f596b)
Fix a leak of a fuse_ticket structure. The leak mostly affected NFS-exported fuse file systems, and was triggered by a failure during FUSE_LOOKUP. Sponsored by: ConnectWise (cherry picked from commit 969d1aa)
Delete some unused includes and member variables. Sponsored by: ConnectWise (cherry picked from commit c2153a5)
Always check the return value of open(). Reported by: Coverity Scan CID: 1471118 1471133 1471215 1471896 1471901 1472116 1473799 CID: 1473879 1473996 1555269 1558044 Sponsored by: ConnectWise (cherry picked from commit f415b2e)
These tests create a linked list with one entry for every group on the running system. On a system with about 30,000 groups, the test took 69 seconds to run, and crashed Kyua with the below error: kyua: E: string or blob too big (sqlite op: sqlite3_bind_blob) (sqlite db: /root/.kyua/store/results.usr_tests.20241231-203317-570235.db). Fix the test by limiting it to operating on the first 1024 groups. Apply the same change to getpw_test and getserv_test too, which are vulnerable to the same problem. Sponsored by: ConnectWise Reviewed by: markj Differential Revision: https://reviews.freebsd.org/D48275 (cherry picked from commit d11904b)
The sockaddr passed to ktrcapfail() may be smaller than sizeof(struct sockaddr), and the trailing bytes in the sockaddr structure will be uninitialized, whereupon they get copied out to userspace. PR: 283673 Reviewed by: jfree, emaste Reported by: Yichen Chai <[email protected]> Reported by: Zhuo Ying Jiang Li <[email protected]> Fixes: 9bec841 ("ktrace: Record detailed ECAPMODE violations") MFC after: 3 days Differential Revision: https://reviews.freebsd.org/D48499 (cherry picked from commit 5b86888)
(cherry picked from commit 4804cb4)
(cherry picked from commit 9718f18)
…lloc (cherry picked from commit 9a2ae72)
(cherry picked from commit 676be27)
(cherry picked from commit 02703de)
PR: 284158 (cherry picked from commit f5cf173)
PR: 284158 (cherry picked from commit d6c2d4f)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The pull request #350 has too many files changed.
We can only review pull requests with up to 300 changed files, and this pull request has 9030.
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.