[rocky9_6] History Rebuild for kernel-5.14.0-570.19.1.el9_6 #321
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
jira LE-3187 Rebuild_History Non-Buildable kernel-5.14.0-570.19.1.el9_6 commit-author Gwenael Georgeault <[email protected]> commit 6636c58 - Added the new device ID - Added new pll algorithm Signed-off-by: Gwenael Georgeault <[email protected]> Co-authored-by: Mamadou Insa Diop <[email protected]> Reviewed-by: Jocelyn Falempe <[email protected]> Reviewed-by: Thomas Zimmermann <[email protected]> Signed-off-by: Jocelyn Falempe <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] (cherry picked from commit 6636c58) Signed-off-by: Jonathan Maple <[email protected]>
jira LE-3187 Rebuild_History Non-Buildable kernel-5.14.0-570.19.1.el9_6 commit-author Ojaswin Mujoo <[email protected]> commit 1f6bc02 Empty-Commit: Cherry-Pick Conflicts during history rebuild. Will be included in final tarball splat. Ref for failed cherry-pick at: ciq/ciq_backports/kernel-5.14.0-570.19.1.el9_6/1f6bc02f.failed Currently in case the goal length is a multiple of stripe size we use ext4_mb_scan_aligned() to find the stripe size aligned physical blocks. In case we are not able to find any, we again go back to calling ext4_mb_choose_next_group() to search for a different suitable block group. However, since the linear search always begins from the start, most of the times we end up with the same BG and the cycle continues. With large fliesystems, the CPU can be stuck in this loop for hours which can slow down the whole system. Hence, until we figure out a better way to continue the search (rather than starting from beginning) in ext4_mb_choose_next_group(), lets just fallback to ext4_mb_complex_scan_group() in case aligned scan fails, as it is much more likely to find the needed blocks. Signed-off-by: Ojaswin Mujoo <[email protected]> Reviewed-by: Jan Kara <[email protected]> Link: https://lore.kernel.org/r/ee033f6dfa0a7f2934437008a909c3788233950f.1702455010.git.ojaswin@linux.ibm.com Signed-off-by: Theodore Ts'o <[email protected]> (cherry picked from commit 1f6bc02) Signed-off-by: Jonathan Maple <[email protected]> # Conflicts: # fs/ext4/mballoc.c
jira LE-3187 Rebuild_History Non-Buildable kernel-5.14.0-570.19.1.el9_6 commit-author Toke Høiland-Jørgensen <[email protected]> commit cd3c931 Empty-Commit: Cherry-Pick Conflicts during history rebuild. Will be included in final tarball splat. Ref for failed cherry-pick at: ciq/ciq_backports/kernel-5.14.0-570.19.1.el9_6/cd3c9316.failed Since we are about to stash some more information into the pp_magic field, let's move the magic signature checks into a pair of helper functions so it can be changed in one place. Reviewed-by: Mina Almasry <[email protected]> Tested-by: Yonglong Liu <[email protected]> Acked-by: Jesper Dangaard Brouer <[email protected]> Reviewed-by: Ilias Apalodimas <[email protected]> Signed-off-by: Toke Høiland-Jørgensen <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Jakub Kicinski <[email protected]> (cherry picked from commit cd3c931) Signed-off-by: Jonathan Maple <[email protected]> # Conflicts: # include/linux/mm.h # mm/page_alloc.c # net/core/netmem_priv.h # net/core/skbuff.c
…pool jira LE-3187 Rebuild_History Non-Buildable kernel-5.14.0-570.19.1.el9_6 commit-author Toke Høiland-Jørgensen <[email protected]> commit ee62ce7 Empty-Commit: Cherry-Pick Conflicts during history rebuild. Will be included in final tarball splat. Ref for failed cherry-pick at: ciq/ciq_backports/kernel-5.14.0-570.19.1.el9_6/ee62ce7a.failed When enabling DMA mapping in page_pool, pages are kept DMA mapped until they are released from the pool, to avoid the overhead of re-mapping the pages every time they are used. This causes resource leaks and/or crashes when there are pages still outstanding while the device is torn down, because page_pool will attempt an unmap through a non-existent DMA device on the subsequent page return. To fix this, implement a simple tracking of outstanding DMA-mapped pages in page pool using an xarray. This was first suggested by Mina[0], and turns out to be fairly straight forward: We simply store pointers to pages directly in the xarray with xa_alloc() when they are first DMA mapped, and remove them from the array on unmap. Then, when a page pool is torn down, it can simply walk the xarray and unmap all pages still present there before returning, which also allows us to get rid of the get/put_device() calls in page_pool. Using xa_cmpxchg(), no additional synchronisation is needed, as a page will only ever be unmapped once. To avoid having to walk the entire xarray on unmap to find the page reference, we stash the ID assigned by xa_alloc() into the page structure itself, using the upper bits of the pp_magic field. This requires a couple of defines to avoid conflicting with the POINTER_POISON_DELTA define, but this is all evaluated at compile-time, so does not affect run-time performance. The bitmap calculations in this patch gives the following number of bits for different architectures: - 23 bits on 32-bit architectures - 21 bits on PPC64 (because of the definition of ILLEGAL_POINTER_VALUE) - 32 bits on other 64-bit architectures Stashing a value into the unused bits of pp_magic does have the effect that it can make the value stored there lie outside the unmappable range (as governed by the mmap_min_addr sysctl), for architectures that don't define ILLEGAL_POINTER_VALUE. This means that if one of the pointers that is aliased to the pp_magic field (such as page->lru.next) is dereferenced while the page is owned by page_pool, that could lead to a dereference into userspace, which is a security concern. The risk of this is mitigated by the fact that (a) we always clear pp_magic before releasing a page from page_pool, and (b) this would need a use-after-free bug for struct page, which can have many other risks since page->lru.next is used as a generic list pointer in multiple places in the kernel. As such, with this patch we take the position that this risk is negligible in practice. For more discussion, see[1]. Since all the tracking added in this patch is performed on DMA map/unmap, no additional code is needed in the fast path, meaning the performance overhead of this tracking is negligible there. A micro-benchmark shows that the total overhead of the tracking itself is about 400 ns (39 cycles(tsc) 395.218 ns; sum for both map and unmap[2]). Since this cost is only paid on DMA map and unmap, it seems like an acceptable cost to fix the late unmap issue. Further optimisation can narrow the cases where this cost is paid (for instance by eliding the tracking when DMA map/unmap is a no-op). The extra memory needed to track the pages is neatly encapsulated inside xarray, which uses the 'struct xa_node' structure to track items. This structure is 576 bytes long, with slots for 64 items, meaning that a full node occurs only 9 bytes of overhead per slot it tracks (in practice, it probably won't be this efficient, but in any case it should be an acceptable overhead). [0] https://lore.kernel.org/all/CAHS8izPg7B5DwKfSuzz-iOop_YRbk3Sd6Y4rX7KBG9DcVJcyWg@mail.gmail.com/ [1] https://lore.kernel.org/r/[email protected] [2] https://lore.kernel.org/r/[email protected] Reported-by: Yonglong Liu <[email protected]> Closes: https://lore.kernel.org/r/[email protected] Fixes: ff7d6b2 ("page_pool: refurbish version of page_pool code") Suggested-by: Mina Almasry <[email protected]> Reviewed-by: Mina Almasry <[email protected]> Reviewed-by: Jesper Dangaard Brouer <[email protected]> Tested-by: Jesper Dangaard Brouer <[email protected]> Tested-by: Qiuling Ren <[email protected]> Tested-by: Yuying Ma <[email protected]> Tested-by: Yonglong Liu <[email protected]> Acked-by: Jesper Dangaard Brouer <[email protected]> Signed-off-by: Toke Høiland-Jørgensen <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Jakub Kicinski <[email protected]> (cherry picked from commit ee62ce7) Signed-off-by: Jonathan Maple <[email protected]> # Conflicts: # include/linux/mm.h # include/net/page_pool/types.h # net/core/netmem_priv.h # net/core/page_pool.c
jira LE-3187 cve CVE-2025-21765 Rebuild_History Non-Buildable kernel-5.14.0-570.19.1.el9_6 commit-author Eric Dumazet <[email protected]> commit 482ad2a dev->nd_net can change, readers should either use rcu_read_lock() or RTNL. We currently use a generic helper, dev_net() with no debugging support. We probably have many hidden bugs. Add dev_net_rcu() helper for callers using rcu_read_lock() protection. Signed-off-by: Eric Dumazet <[email protected]> Reviewed-by: Kuniyuki Iwashima <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Jakub Kicinski <[email protected]> (cherry picked from commit 482ad2a) Signed-off-by: Jonathan Maple <[email protected]>
jira LE-3187 cve CVE-2025-21765 Rebuild_History Non-Buildable kernel-5.14.0-570.19.1.el9_6 commit-author Eric Dumazet <[email protected]> commit 3c8ffcd ip6_default_advmss() needs rcu protection to make sure the net structure it reads does not disappear. Fixes: 5578689 ("[NETNS][IPV6] route6 - make route6 per namespace") Signed-off-by: Eric Dumazet <[email protected]> Reviewed-by: Kuniyuki Iwashima <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Jakub Kicinski <[email protected]> (cherry picked from commit 3c8ffcd) Signed-off-by: Jonathan Maple <[email protected]>
jira LE-3187 cve CVE-2025-21764 Rebuild_History Non-Buildable kernel-5.14.0-570.19.1.el9_6 commit-author Eric Dumazet <[email protected]> commit 628e6d1 ndisc_alloc_skb() can be called without RTNL or RCU being held. Add RCU protection to avoid possible UAF. Fixes: de09334 ("ndisc: Introduce ndisc_alloc_skb() helper.") Signed-off-by: Eric Dumazet <[email protected]> Reviewed-by: David Ahern <[email protected]> Reviewed-by: Kuniyuki Iwashima <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Jakub Kicinski <[email protected]> (cherry picked from commit 628e6d1) Signed-off-by: Jonathan Maple <[email protected]>
…u_fault and gru_handle_user_call_os jira LE-3187 cve CVE-2022-3424 Rebuild_History Non-Buildable kernel-5.14.0-570.19.1.el9_6 commit-author Zheng Wang <[email protected]> commit 643a16a In some bad situation, the gts may be freed gru_check_chiplet_assignment. The call chain can be gru_unload_context->gru_free_gru_context->gts_drop and kfree finally. However, the caller didn't know if the gts is freed or not and use it afterwards. This will trigger a Use after Free bug. Fix it by introducing a return value to see if it's in error path or not. Free the gts in caller if gru_check_chiplet_assignment check failed. Fixes: 55484c4 ("gru: allow users to specify gru chiplet 2") Signed-off-by: Zheng Wang <[email protected]> Acked-by: Dimitri Sivanich <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]> (cherry picked from commit 643a16a) Signed-off-by: Jonathan Maple <[email protected]>
Rebuild_History BUILDABLE Rebuilding Kernel from rpm changelog with Fuzz Limit: 87.50% Number of commits in upstream range v5.14~1..kernel-mainline: 308110 Number of commits in rpm: 10 Number of commits matched with upstream: 8 (80.00%) Number of commits in upstream but not in rpm: 308102 Number of commits NOT found in upstream: 2 (20.00%) Rebuilding Kernel on Branch rocky9_6_rebuild_kernel-5.14.0-570.19.1.el9_6 for kernel-5.14.0-570.19.1.el9_6 Clean Cherry Picks: 5 (62.50%) Empty Cherry Picks: 3 (37.50%) _______________________________ Full Details Located here: ciq/ciq_backports/kernel-5.14.0-570.19.1.el9_6/rebuild.details.txt Includes: * git commit header above * Empty Commits with upstream SHA * RPM ChangeLog Entries that could not be matched Individual Empty Commit failures contained in the same containing directory. The git message for empty commits will have the path for the failed commit. File names are the first 8 characters of the upstream SHA
PlaidCat
requested review from
jdieter,
juphoff,
kerneltoast,
bmastbergen and
thefossguy-ciq
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.
General Process:
src.rpm5.14.0-570git cherry-pickrpmbuild -bpfrom corresponding src.rpm.Checking Rebuild Commits for potentially missing commits:
kernel-5.14.0-570.19.1.el9_6/
BUILD
KSelfTest