-
Notifications
You must be signed in to change notification settings - Fork 12
Rebuild rocky9_5 with kernel-5.14.0-503.22.1.el9_5 #94
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
Collaborator
PlaidCat
commented
Jan 28, 2025
jira LE-2290 cve CVE-2024-50208 Rebuild_History Non-Buildable kernel-5.14.0-503.21.1.el9_5 commit-author Bhargava Chenna Marreddy <[email protected]> commit 7988bdb Avoid memory corruption while setting up Level-2 PBL pages for the non MR resources when num_pages > 256K. There will be a single PDE page address (contiguous pages in the case of > PAGE_SIZE), but, current logic assumes multiple pages, leading to invalid memory access after 256K PBL entries in the PDE. Fixes: 0c4dcd6 ("RDMA/bnxt_re: Refactor hardware queue memory allocation") Link: https://patch.msgid.link/r/[email protected] Signed-off-by: Bhargava Chenna Marreddy <[email protected]> Signed-off-by: Selvin Xavier <[email protected]> Signed-off-by: Jason Gunthorpe <[email protected]> (cherry picked from commit 7988bdb) Signed-off-by: Jonathan Maple <[email protected]>
jira LE-2290 cve CVE-2024-46713 Rebuild_History Non-Buildable kernel-5.14.0-503.21.1.el9_5 commit-author Peter Zijlstra <[email protected]> commit 2ab9d83 Ole reported that event->mmap_mutex is strictly insufficient to serialize the AUX buffer, add a per RB mutex to fully serialize it. Note that in the lock order comment the perf_event::mmap_mutex order was already wrong, that is, it nesting under mmap_lock is not new with this patch. Fixes: 45bfb2e ("perf: Add AUX area to ring buffer for raw data streams") Reported-by: Ole <[email protected]> Signed-off-by: Peter Zijlstra (Intel) <[email protected]> Signed-off-by: Ingo Molnar <[email protected]> (cherry picked from commit 2ab9d83) Signed-off-by: Jonathan Maple <[email protected]>
jira LE-2290 Rebuild_History Non-Buildable kernel-5.14.0-503.21.1.el9_5 commit-author Josh Poimboeuf <[email protected]> commit e8deb00 With KCSAN enabled, even empty inline stubs can be out-of-lined. Force the context_tracking_guest_exit() stub inline. Fixes the following warnings: vmlinux.o: warning: objtool: vmx_vcpu_enter_exit+0x1be: call to context_tracking_guest_exit() leaves .noinstr.text section vmlinux.o: warning: objtool: svm_vcpu_enter_exit+0x85: call to context_tracking_guest_exit() leaves .noinstr.text section Signed-off-by: Josh Poimboeuf <[email protected]> Signed-off-by: Peter Zijlstra (Intel) <[email protected]> Link: https://lore.kernel.org/r/dc93f45abdec90c171108b4b590b7fff5790963c.1681320026.git.jpoimboe@kernel.org (cherry picked from commit e8deb00) Signed-off-by: Jonathan Maple <[email protected]>
jira LE-2290 Rebuild_History Non-Buildable kernel-5.14.0-503.21.1.el9_5 commit-author Paul E. McKenney <[email protected]> commit 68d124b If a CPU is running either a userspace application or a guest OS in nohz_full mode, it is possible for a system call to occur just as an RCU grace period is starting. If that CPU also has the scheduling-clock tick enabled for any reason (such as a second runnable task), and if the system was booted with rcutree.use_softirq=0, then RCU can add insult to injury by awakening that CPU's rcuc kthread, resulting in yet another task and yet more OS jitter due to switching to that task, running it, and switching back. In addition, in the common case where that system call is not of excessively long duration, awakening the rcuc task is pointless. This pointlessness is due to the fact that the CPU will enter an extended quiescent state upon returning to the userspace application or guest OS. In this case, the rcuc kthread cannot do anything that the main RCU grace-period kthread cannot do on its behalf, at least if it is given a few additional milliseconds (for example, given the time duration specified by rcutree.jiffies_till_first_fqs, give or take scheduling delays). This commit therefore adds a rcutree.nohz_full_patience_delay kernel boot parameter that specifies the grace period age (in milliseconds, rounded to jiffies) before which RCU will refrain from awakening the rcuc kthread. Preliminary experimentation suggests a value of 1000, that is, one second. Increasing rcutree.nohz_full_patience_delay will increase grace-period latency and in turn increase memory footprint, so systems with constrained memory might choose a smaller value. Systems with less-aggressive OS-jitter requirements might choose the default value of zero, which keeps the traditional immediate-wakeup behavior, thus avoiding increases in grace-period latency. [ paulmck: Apply Leonardo Bras feedback. ] Link: https://lore.kernel.org/all/[email protected]/ Reported-by: Leonardo Bras <[email protected]> Suggested-by: Leonardo Bras <[email protected]> Suggested-by: Sean Christopherson <[email protected]> Signed-off-by: Paul E. McKenney <[email protected]> Reviewed-by: Leonardo Bras <[email protected]> (cherry picked from commit 68d124b) Signed-off-by: Jonathan Maple <[email protected]>
jira LE-2290 Rebuild_History Non-Buildable kernel-5.14.0-503.21.1.el9_5 commit-author Leonardo Bras <[email protected]> commit 5933770 As of today, KVM notes a quiescent state only in guest entry, which is good as it avoids the guest being interrupted for current RCU operations. While the guest vcpu runs, it can be interrupted by a timer IRQ that will check for any RCU operations waiting for this CPU. In case there are any of such, it invokes rcu_core() in order to sched-out the current thread and note a quiescent state. This occasional schedule work will introduce tens of microsseconds of latency, which is really bad for vcpus running latency-sensitive applications, such as real-time workloads. So, note a quiescent state in guest exit, so the interrupted guests is able to deal with any pending RCU operations before being required to invoke rcu_core(), and thus avoid the overhead of related scheduler work. Signed-off-by: Leonardo Bras <[email protected]> Acked-by: Paul E. McKenney <[email protected]> Acked-by: Sean Christopherson <[email protected]> Message-ID: <[email protected]> Signed-off-by: Paolo Bonzini <[email protected]> (cherry picked from commit 5933770) Signed-off-by: Jonathan Maple <[email protected]>
jira LE-2290 Rebuild_History Non-Buildable kernel-5.14.0-503.21.1.el9_5 commit-author Pavan Chebbi <[email protected]> commit d3c9828 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-503.21.1.el9_5/d3c98285.failed For ntuple filters added by aRFS, the Toeplitz hash calculated by our NIC is available and is used to store the ntuple filter for quick retrieval. In the next patches, user defined ntuple filter support will be added and we need to calculate the same hash for these filters. The same hash function needs to be used so we can detect duplicates. Add the function bnxt_toeplitz() to calculate the Toeplitz hash for user defined ntuple filters. bnxt_toeplitz() uses the same Toeplitz key and the same key length as the NIC. bnxt_get_ntp_filter_idx() is added to return the hash index. For aRFS, the hash comes from the NIC. For user defined ntuple, we call bnxt_toeplitz() to calculate the hash index. Reviewed-by: Andy Gospodarek <[email protected]> Signed-off-by: Pavan Chebbi <[email protected]> Signed-off-by: Michael Chan <[email protected]> Signed-off-by: David S. Miller <[email protected]> (cherry picked from commit d3c9828) Signed-off-by: Jonathan Maple <[email protected]> # Conflicts: # drivers/net/ethernet/broadcom/bnxt/bnxt.c # drivers/net/ethernet/broadcom/bnxt/bnxt.h
jira LE-2290 Rebuild_History Non-Buildable kernel-5.14.0-503.21.1.el9_5 commit-author Pavan Chebbi <[email protected]> commit 5de1fce 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-503.21.1.el9_5/5de1fce3.failed Store the user configured or generated Toeplitz key in bp->rss_hash_key. The key stays constant across ifdown/ifup unless updated by the user. Signed-off-by: Pavan Chebbi <[email protected]> Signed-off-by: Michael Chan <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Jakub Kicinski <[email protected]> (cherry picked from commit 5de1fce) Signed-off-by: Jonathan Maple <[email protected]> # Conflicts: # drivers/net/ethernet/broadcom/bnxt/bnxt.c
jira LE-2290 Rebuild_History Non-Buildable kernel-5.14.0-503.21.1.el9_5 commit-author Oliver Upton <[email protected]> commit 78a0055 kvm_vgic_map_resources() prematurely marks the distributor as 'ready', potentially allowing vCPUs to enter the guest before the distributor's MMIO registration has been made visible. Plug the race by marking the distributor as ready only after MMIO registration is completed. Rely on the implied ordering of synchronize_srcu() to ensure the MMIO registration is visible before vgic_dist::ready. This also means that writers to vgic_dist::ready are now serialized by the slots_lock, which was effectively the case already as all writers held the slots_lock in addition to the config_lock. Fixes: 59112e9 ("KVM: arm64: vgic: Fix a circular locking issue") Signed-off-by: Oliver Upton <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Marc Zyngier <[email protected]> (cherry picked from commit 78a0055) Signed-off-by: Jonathan Maple <[email protected]>
jira LE-2290 Rebuild_History Non-Buildable kernel-5.14.0-503.21.1.el9_5 commit-author Alexandra Winter <[email protected]> commit f558120 iucv_sever_path() is called from process context and from bh context. iucv->path is used as indicator whether somebody else is taking care of severing the path (or it is already removed / never existed). This needs to be done with atomic compare and swap, otherwise there is a small window where iucv_sock_close() will try to work with a path that has already been severed and freed by iucv_callback_connrej() called by iucv_tasklet_fn(). Example: [452744.123844] Call Trace: [452744.123845] ([<0000001e87f03880>] 0x1e87f03880) [452744.123966] [<00000000d593001e>] iucv_path_sever+0x96/0x138 [452744.124330] [<000003ff801ddbca>] iucv_sever_path+0xc2/0xd0 [af_iucv] [452744.124336] [<000003ff801e01b6>] iucv_sock_close+0xa6/0x310 [af_iucv] [452744.124341] [<000003ff801e08cc>] iucv_sock_release+0x3c/0xd0 [af_iucv] [452744.124345] [<00000000d574794e>] __sock_release+0x5e/0xe8 [452744.124815] [<00000000d5747a0c>] sock_close+0x34/0x48 [452744.124820] [<00000000d5421642>] __fput+0xba/0x268 [452744.124826] [<00000000d51b382c>] task_work_run+0xbc/0xf0 [452744.124832] [<00000000d5145710>] do_notify_resume+0x88/0x90 [452744.124841] [<00000000d5978096>] system_call+0xe2/0x2c8 [452744.125319] Last Breaking-Event-Address: [452744.125321] [<00000000d5930018>] iucv_path_sever+0x90/0x138 [452744.125324] [452744.125325] Kernel panic - not syncing: Fatal exception in interrupt Note that bh_lock_sock() is not serializing the tasklet context against process context, because the check for sock_owned_by_user() and corresponding handling is missing. Ideas for a future clean-up patch: A) Correct usage of bh_lock_sock() in tasklet context, as described in Link: https://lore.kernel.org/netdev/1280155406.2899.407.camel@edumazet-laptop/ Re-enqueue, if needed. This may require adding return values to the tasklet functions and thus changes to all users of iucv. B) Change iucv tasklet into worker and use only lock_sock() in af_iucv. Fixes: 7d316b9 ("af_iucv: remove IUCV-pathes completely") Reviewed-by: Halil Pasic <[email protected]> Signed-off-by: Alexandra Winter <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Paolo Abeni <[email protected]> (cherry picked from commit f558120) Signed-off-by: Jonathan Maple <[email protected]>
jira LE-2290 Rebuild_History Non-Buildable kernel-5.14.0-503.21.1.el9_5 commit-author Paulo Alcantara <[email protected]> commit 343d7fe Customers have reported use-after-free in @ses->auth_key.response with SMB2.1 + sign mounts which occurs due to following race: task A task B cifs_mount() dfs_mount_share() get_session() cifs_mount_get_session() cifs_send_recv() cifs_get_smb_ses() compound_send_recv() cifs_setup_session() smb2_setup_request() kfree_sensitive() smb2_calc_signature() crypto_shash_setkey() *UAF* Fix this by ensuring that we have a valid @ses->auth_key.response by checking whether @ses->ses_status is SES_GOOD or SES_EXITING with @ses->ses_lock held. After commit 24a9799 ("smb: client: fix UAF in smb2_reconnect_server()"), we made sure to call ->logoff() only when @SES was known to be good (e.g. valid ->auth_key.response), so it's safe to access signing key when @ses->ses_status == SES_EXITING. Cc: [email protected] Reported-by: Jay Shin <[email protected]> Signed-off-by: Paulo Alcantara (Red Hat) <[email protected]> Signed-off-by: Steve French <[email protected]> (cherry picked from commit 343d7fe) Signed-off-by: Jonathan Maple <[email protected]>
jira LE-2290 Rebuild_History Non-Buildable kernel-5.14.0-503.21.1.el9_5 commit-author Andreas Gruenbacher <[email protected]> commit e7beb8b Rename the SDF_DEACTIVATING flag to SDF_KILL to make it more obvious that this relates to the kill_sb filesystem operation. Signed-off-by: Andreas Gruenbacher <[email protected]> (cherry picked from commit e7beb8b) Signed-off-by: Jonathan Maple <[email protected]>
jira LE-2290 Rebuild_History Non-Buildable kernel-5.14.0-503.21.1.el9_5 commit-author Andreas Gruenbacher <[email protected]> commit 18c1db3 When trying to upgrade the iopen glock, gfs2_upgrade_iopen_glock() tries to take the iopen glock with the LM_FLAG_TRY_1CB flag set before trying to take it without the LM_FLAG_TRY or LM_FLAG_TRY_1CB flags set. Both calls will cause the lock contention bast callbacks to be invoked throughout the cluster, and we really don't need them to be invoked twice. Remove the first LM_FLAG_TRY_1CB call to eliminate unnecessary dlm traffic. Signed-off-by: Andreas Gruenbacher <[email protected]> (cherry picked from commit 18c1db3) Signed-off-by: Jonathan Maple <[email protected]>
jira LE-2290 Rebuild_History Non-Buildable kernel-5.14.0-503.21.1.el9_5 commit-author Wolfram Sang <[email protected]> commit c1c53c2 'timeout' is a vague name for the return value of wait_event_*_timeout because it actually returns the time left. Because the variable is never used later, just drop the return value. Since variable 'timeout' is then only used to carry a fixed timeout value, drop this in favor of a fixed function argument as in the other call to wait_event_timeout() above. Signed-off-by: Wolfram Sang <[email protected]> Signed-off-by: Andreas Gruenbacher <[email protected]> (cherry picked from commit c1c53c2) Signed-off-by: Jonathan Maple <[email protected]>
jira LE-2290 Rebuild_History Non-Buildable kernel-5.14.0-503.21.1.el9_5 commit-author Andreas Gruenbacher <[email protected]> commit 820ce8e Rename the GLF_VERIFY_EVICT flag to GLF_VERIFY_DELETE: that flag indicates that we want to delete an inode / verify that it has been deleted. To match, rename gfs2_queue_verify_evict() to gfs2_queue_verify_delete(). Signed-off-by: Andreas Gruenbacher <[email protected]> (cherry picked from commit 820ce8e) Signed-off-by: Jonathan Maple <[email protected]>
jira LE-2290 Rebuild_History Non-Buildable kernel-5.14.0-503.21.1.el9_5 commit-author Andreas Gruenbacher <[email protected]> commit 1072b3a Set gl_no_formal_ino of the iopen glock to the generation of the associated inode (ip->i_no_formal_ino) as soon as that value is known. This saves us from setting it later, possibly repeatedly, when queuing GLF_VERIFY_DELETE work. Signed-off-by: Andreas Gruenbacher <[email protected]> (cherry picked from commit 1072b3a) Signed-off-by: Jonathan Maple <[email protected]>
jira LE-2290 Rebuild_History Non-Buildable kernel-5.14.0-503.21.1.el9_5 commit-author Andreas Gruenbacher <[email protected]> commit 160bc95 Add an argument to gfs2_queue_verify_delete() that allows it to queue GLF_VERIFY_DELETE work for immediate execution. This is used in the next patch. Signed-off-by: Andreas Gruenbacher <[email protected]> (cherry picked from commit 160bc95) Signed-off-by: Jonathan Maple <[email protected]>
jira LE-2290 Rebuild_History Non-Buildable kernel-5.14.0-503.21.1.el9_5 commit-author Andreas Gruenbacher <[email protected]> commit 7c6f714 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-503.21.1.el9_5/7c6f714d.failed Before commit f0e56ed ("gfs2: Split the two kinds of glock "delete" work"), function delete_work_func() was used to trigger the eviction of in-memory inodes from remote as well as deleting unlinked inodes at a later point. These two kinds of work were then split into two kinds of work, and the two places in the code were deferred deletion of inodes is required accidentally ended up queuing the wrong kind of work. This caused unlinked inodes to be left behind, which could in the worst case fill up filesystems and require a filesystem check to recover. Fix that by queuing the right kind of work in try_rgrp_unlink() and gfs2_drop_inode(). Fixes: f0e56ed ("gfs2: Split the two kinds of glock "delete" work") Signed-off-by: Andreas Gruenbacher <[email protected]> (cherry picked from commit 7c6f714) Signed-off-by: Jonathan Maple <[email protected]> # Conflicts: # fs/gfs2/glock.h
jira LE-2290 Rebuild_History Non-Buildable kernel-5.14.0-503.21.1.el9_5 commit-author Andreas Gruenbacher <[email protected]> commit ee51baa Move function needs_demote() to glock.h and rename it to glock_needs_demote(). In handle_callback(), wake up the glock when setting the GLF_PENDING_DEMOTE flag as well. (Setting the GLF_DEMOTE flag already triggered a wake-up.) With that, check for glock_needs_demote() in gfs2_upgrade_iopen_glock() to wake up when either of those flags is set for the inode glock: the faster we can react to contention, the better. The GLF_PENDING_DEMOTE flag is only used for inode glocks (see gfs2_glock_cb()) so it's okay to only check for the GLF_DEMOTE flag in gfs2_drop_inode(). Still, using glock_needs_demote() there as well makes the code a little easier to read. Signed-off-by: Andreas Gruenbacher <[email protected]> (cherry picked from commit ee51baa) Signed-off-by: Jonathan Maple <[email protected]>
jira LE-2290 Rebuild_History Non-Buildable kernel-5.14.0-503.21.1.el9_5 commit-author Andreas Gruenbacher <[email protected]> commit 9fb794a The GIF_DEFERRED_DELETE flag indicates an action that gfs2_evict_inode() should take, so rename the flag to GIF_DEFER_DELETE to clarify. Signed-off-by: Andreas Gruenbacher <[email protected]> (cherry picked from commit 9fb794a) Signed-off-by: Jonathan Maple <[email protected]>
jira LE-2290 Rebuild_History Non-Buildable kernel-5.14.0-503.21.1.el9_5 commit-author Andreas Gruenbacher <[email protected]> commit c79ba4b 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-503.21.1.el9_5/c79ba4be.failed Rename enum dinode_demise to evict_behavior and its items SHOULD_DELETE_DINODE to EVICT_SHOULD_DELETE, SHOULD_NOT_DELETE_DINODE to EVICT_SHOULD_SKIP_DELETE, and SHOULD_DEFER_EVICTION to EVICT_SHOULD_DEFER_DELETE. In gfs2_evict_inode(), add a separate variable of type enum evict_behavior instead of implicitly casting to int. Signed-off-by: Andreas Gruenbacher <[email protected]> (cherry picked from commit c79ba4b) Signed-off-by: Jonathan Maple <[email protected]> # Conflicts: # fs/gfs2/super.c
jira LE-2290 Rebuild_History Non-Buildable kernel-5.14.0-503.21.1.el9_5 commit-author Andreas Gruenbacher <[email protected]> commit a94dafe 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-503.21.1.el9_5/a94dafe8.failed In case an iopen glock cannot be upgraded, function gfs2_upgrade_iopen_glock() needs to communicate to gfs2_evict_inode() whether deleting the inode should be deferred or skipped altogether. Change the function to return the appropriate enum evict_behavior value to indicate that. Signed-off-by: Andreas Gruenbacher <[email protected]> (cherry picked from commit a94dafe) Signed-off-by: Jonathan Maple <[email protected]> # Conflicts: # fs/gfs2/super.c
jira LE-2290 Rebuild_History Non-Buildable kernel-5.14.0-503.21.1.el9_5 commit-author Andreas Gruenbacher <[email protected]> commit b410045 Move those definitions into the the scope in which they are used. Signed-off-by: Andreas Gruenbacher <[email protected]> (cherry picked from commit b410045) Signed-off-by: Jonathan Maple <[email protected]>
jira LE-2290 Rebuild_History Non-Buildable kernel-5.14.0-503.21.1.el9_5 commit-author Andreas Gruenbacher <[email protected]> commit 0baa10b Function delete_work_func() was previously assuming that the GLF_TRY_TO_EVICT and GLF_VERIFY_DELETE flags won't both be set at the same time, but there probably are races in which that can happen, so handle that case correctly. Signed-off-by: Andreas Gruenbacher <[email protected]> (cherry picked from commit 0baa10b) Signed-off-by: Jonathan Maple <[email protected]>
jira LE-2290 Rebuild_History Non-Buildable kernel-5.14.0-503.21.1.el9_5 commit-author Andreas Gruenbacher <[email protected]> commit 8c21c2c 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-503.21.1.el9_5/8c21c2c7.failed Move calls to gfs2_queue_verify_delete() into gfs2_evict_inode(). Signed-off-by: Andreas Gruenbacher <[email protected]> (cherry picked from commit 8c21c2c) Signed-off-by: Jonathan Maple <[email protected]> # Conflicts: # fs/gfs2/super.c
jira LE-2290 Rebuild_History Non-Buildable kernel-5.14.0-503.21.1.el9_5 commit-author Andreas Gruenbacher <[email protected]> commit a603333 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-503.21.1.el9_5/a6033333.failed Try to be a bit more clear and remove some duplications. We cannot actually get rid of the verification step eventually, so remove the comment saying so. Signed-off-by: Andreas Gruenbacher <[email protected]> (cherry picked from commit a603333) Signed-off-by: Jonathan Maple <[email protected]> # Conflicts: # fs/gfs2/glock.c
jira LE-2290 Rebuild_History Non-Buildable kernel-5.14.0-503.21.1.el9_5 commit-author Andreas Gruenbacher <[email protected]> commit f6ca45e In the unlikely case that we're trying to queue GLF_TRY_TO_EVICT work for an inode that already has GLF_VERIFY_DELETE work queued, we want to make sure that the GLF_TRY_TO_EVICT work gets scheduled immediately instead of waiting for the delayed work timer to expire. Signed-off-by: Andreas Gruenbacher <[email protected]> (cherry picked from commit f6ca45e) Signed-off-by: Jonathan Maple <[email protected]>
jira LE-2290 Rebuild_History Non-Buildable kernel-5.14.0-503.21.1.el9_5 commit-author Andreas Gruenbacher <[email protected]> commit 085e423 Randomize the delay of GLF_VERIFY_DELETE work. This avoids thundering herd problems when multiple nodes schedule that kind of work in response to an inode being unlinked remotely. Signed-off-by: Andreas Gruenbacher <[email protected]> (cherry picked from commit 085e423) Signed-off-by: Jonathan Maple <[email protected]>
jira LE-2290 Rebuild_History Non-Buildable kernel-5.14.0-503.21.1.el9_5 commit-author Andreas Gruenbacher <[email protected]> commit c5b7a24 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-503.21.1.el9_5/c5b7a240.failed The mechanism to defer deleting unlinked inodes is tied to delete_work_func(), which is tied to iopen glocks. When we don't have an iopen glock, we must carry out deletes immediately instead. Fixes a NULL pointer dereference in gfs2_evict_inode(). Fixes: 8c21c2c ("gfs2: Call gfs2_queue_verify_delete from gfs2_evict_inode") Signed-off-by: Andreas Gruenbacher <[email protected]> (cherry picked from commit c5b7a24) Signed-off-by: Jonathan Maple <[email protected]> # Conflicts: # fs/gfs2/super.c
jira LE-2290 Rebuild_History Non-Buildable kernel-5.14.0-503.21.1.el9_5 commit-author Andreas Gruenbacher <[email protected]> commit ffd1cf0 When a request to evict an inode comes in over the network, we are trying to grab an inode reference via the iopen glock's gl_object pointer. There is a very small probability that by the time such a request comes in, inode creation hasn't completed and the I_NEW flag is still set. To deal with that, wait for the inode and then check if inode creation was successful. Signed-off-by: Andreas Gruenbacher <[email protected]> (cherry picked from commit ffd1cf0) Signed-off-by: Jonathan Maple <[email protected]>
jira LE-2290 Rebuild_History Non-Buildable kernel-5.14.0-503.21.1.el9_5 commit-author Nina Schoetterl-Glausch <[email protected]> commit 22fdd8b In order for SIE to interpretively execute STFLE, it requires the real or absolute address of a facility-list control block. Before writing the location into the shadow SIE control block, convert it from a virtual address. We currently do not run into this bug because the lower 31 bits are the same for virtual and physical addresses. Signed-off-by: Nina Schoetterl-Glausch <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Janosch Frank <[email protected]> Message-Id: <[email protected]> Signed-off-by: Alexander Gordeev <[email protected]> (cherry picked from commit 22fdd8b) Signed-off-by: Jonathan Maple <[email protected]>
…w_params jira LE-2290 Rebuild_History Non-Buildable kernel-5.14.0-503.22.1.el9_5 commit-author Peter Ujfalusi <[email protected]> commit b679302 Add a bitmask parameter to sof_ipc4_update_hw_params() to be able to select the param to be updated. This feature can be used when not all params should be updated, for example if caller only wants to update the format in the params, leaving the channels and rates untouched. Reviewed-by: Seppo Ingalsuo <[email protected]> Reviewed-by: Ranjani Sridharan <[email protected]> Signed-off-by: Peter Ujfalusi <[email protected]> Signed-off-by: Pierre-Louis Bossart <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Mark Brown <[email protected]> (cherry picked from commit b679302) Signed-off-by: Jonathan Maple <[email protected]>
…uest jira LE-2290 Rebuild_History Non-Buildable kernel-5.14.0-503.22.1.el9_5 commit-author Peter Ujfalusi <[email protected]> commit f920964 In case of capture and when the DAI copier have single bit depth supported on it's input side we should use this format instead of the one in fe_params. Regardless of the stream direction for the NHLT blob lookup when the DAI copier only supports single bit depth on the DAI side we should only look for a blob which matches with this single configuration. For DMIC if the DAI copier supports multiple bit depths, try to request 32-bit blob first if the requested bit depth is 16-bit. If the 32-bit blob is available then look for marching (32-bit) copier format to make sure that both the blob and copier have correct parameters. Reviewed-by: Seppo Ingalsuo <[email protected]> Reviewed-by: Ranjani Sridharan <[email protected]> Signed-off-by: Peter Ujfalusi <[email protected]> Signed-off-by: Pierre-Louis Bossart <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Mark Brown <[email protected]> (cherry picked from commit f920964) Signed-off-by: Jonathan Maple <[email protected]>
…blob jira LE-2290 Rebuild_History Non-Buildable kernel-5.14.0-503.22.1.el9_5 commit-author Peter Ujfalusi <[email protected]> commit d556f80 The ACPI NHLT table always had 32-bit DMIC blob even if 16-bit was also present and taken as a 'rule' which obviously got broken and there is at least one device on the market which ships with only 16-bit DMIC configuration blob. This corner case has never been supported and it is going to need topology updates for DMIC copier to support multiple formats. As for the kernel side: if the copier supports multiple formats and the preferred 32-bit DMIC blob is not found then we will try to get a 16-bit DMIC configuration and look for a 16-bit copier config. Fixes: f920964 ("ASoC: SOF: ipc4-topology: Correct DAI copier config and NHLT blob request") Link: thesofproject/linux#4973 Signed-off-by: Peter Ujfalusi <[email protected]> Reviewed-by: Seppo Ingalsuo <[email protected]> Reviewed-by: Pierre-Louis Bossart <[email protected]> Reviewed-by: Ranjani Sridharan <[email protected]> Link: https://msgid.link/r/[email protected] Signed-off-by: Mark Brown <[email protected]> (cherry picked from commit d556f80) Signed-off-by: Jonathan Maple <[email protected]>
jira LE-2290 Rebuild_History Non-Buildable kernel-5.14.0-503.22.1.el9_5 commit-author Brent Lu <[email protected]> commit 6073c47 We are going to extend the dai_get_clk() callback function to retrieve other dai-specific settings like tdm slot number, not just mclk/bclk frequencies. Revisit functions and macros related to the callback and replace the string 'clk' with 'param' to reflect the ongoing change. Reviewed-by: Bard Liao <[email protected]> Signed-off-by: Brent Lu <[email protected]> Signed-off-by: Pierre-Louis Bossart <[email protected]> Link: https://msgid.link/r/[email protected] Signed-off-by: Mark Brown <[email protected]> (cherry picked from commit 6073c47) Signed-off-by: Jonathan Maple <[email protected]>
jira LE-2290 Rebuild_History Non-Buildable kernel-5.14.0-503.22.1.el9_5 commit-author Brent Lu <[email protected]> commit 1deba6e An new interface, sof_dai_get_tdm_slots(), is added for machine driver to get tdm slot number from topology. The dai_get_param() callback needs to support new parameter type SOF_DAI_PARAM_INTEL_SSP_TDM_SLOTS by returning the tdm slot number of specific SSP port. Reviewed-by: Bard Liao <[email protected]> Signed-off-by: Brent Lu <[email protected]> Signed-off-by: Pierre-Louis Bossart <[email protected]> Link: https://msgid.link/r/[email protected] Signed-off-by: Mark Brown <[email protected]> (cherry picked from commit 1deba6e) Signed-off-by: Jonathan Maple <[email protected]>
jira LE-2290 Rebuild_History Non-Buildable kernel-5.14.0-503.22.1.el9_5 commit-author Brent Lu <[email protected]> commit e495f3e Support the new parameter type SOF_DAI_PARAM_INTEL_SSP_TDM_SLOTS in sof_ipc3_dai_get_param() function to get the tdm slot number of specific SSP port. Reviewed-by: Bard Liao <[email protected]> Signed-off-by: Brent Lu <[email protected]> Signed-off-by: Pierre-Louis Bossart <[email protected]> Link: https://msgid.link/r/[email protected] Signed-off-by: Mark Brown <[email protected]> (cherry picked from commit e495f3e) Signed-off-by: Jonathan Maple <[email protected]>
jira LE-2290 Rebuild_History Non-Buildable kernel-5.14.0-503.22.1.el9_5 commit-author Brent Lu <[email protected]> commit 97a9e99 Support the new parameter type SOF_DAI_PARAM_INTEL_SSP_TDM_SLOTS in sof_ipc4_dai_get_param() function to get the tdm slot number of specific SSP port. Reviewed-by: Bard Liao <[email protected]> Signed-off-by: Brent Lu <[email protected]> Signed-off-by: Pierre-Louis Bossart <[email protected]> Link: https://msgid.link/r/[email protected] Signed-off-by: Mark Brown <[email protected]> (cherry picked from commit 97a9e99) Signed-off-by: Jonathan Maple <[email protected]>
…_audio_format jira LE-2290 Rebuild_History Non-Buildable kernel-5.14.0-503.22.1.el9_5 commit-author Peter Ujfalusi <[email protected]> commit 2a865c9 Print out the number of channels for the format explicitly instead of having the reader to understand how to interpret the ch_map and ch_cfg values. Signed-off-by: Peter Ujfalusi <[email protected]> Reviewed-by: Pierre-Louis Bossart <[email protected]> Reviewed-by: Ranjani Sridharan <[email protected]> Reviewed-by: Bard Liao <[email protected]> Link: https://msgid.link/r/[email protected] Signed-off-by: Mark Brown <[email protected]> (cherry picked from commit 2a865c9) Signed-off-by: Jonathan Maple <[email protected]>
jira LE-2290 Rebuild_History Non-Buildable kernel-5.14.0-503.22.1.el9_5 commit-author Peter Ujfalusi <[email protected]> commit 3b64fd2 Rename the sof_ipc4_copier_is_single_format() to sof_ipc4_copier_is_single_bitdepth() to clear the confusion of the use of 'format' when we are querying information on the bit depth. Format is used to describe a combination of parameters (rate, channels, sample format / bit depth). Rename the flags used to store the result at the same time. Signed-off-by: Peter Ujfalusi <[email protected]> Reviewed-by: Pierre-Louis Bossart <[email protected]> Reviewed-by: Bard Liao <[email protected]> Reviewed-by: Seppo Ingalsuo <[email protected]> Reviewed-by: Ranjani Sridharan <[email protected]> Link: https://msgid.link/r/[email protected] Signed-off-by: Mark Brown <[email protected]> (cherry picked from commit 3b64fd2) Signed-off-by: Jonathan Maple <[email protected]>
…_copier() jira LE-2290 Rebuild_History Non-Buildable kernel-5.14.0-503.22.1.el9_5 commit-author Peter Ujfalusi <[email protected]> commit 2fcad03 Remove the duplicated code paths to check for single bit depth and to update the params with storing the parameters needed by the function and have a single code section. No functional change but the code is easier to follow. Signed-off-by: Peter Ujfalusi <[email protected]> Reviewed-by: Pierre-Louis Bossart <[email protected]> Reviewed-by: Bard Liao <[email protected]> Reviewed-by: Seppo Ingalsuo <[email protected]> Reviewed-by: Ranjani Sridharan <[email protected]> Link: https://msgid.link/r/[email protected] Signed-off-by: Mark Brown <[email protected]> (cherry picked from commit 2fcad03) Signed-off-by: Jonathan Maple <[email protected]>
jira LE-2290 Rebuild_History Non-Buildable kernel-5.14.0-503.22.1.el9_5 commit-author Peter Ujfalusi <[email protected]> commit b65456b Currently we only check the bit depth value among to DAI formats, but other parameters might be constant, like number of channels and/or rate. In capture we use the fe params as a reference to find the format and blob which should be used, but in the path we can have components which can handle expanding/narrowing number of channels or do a resample. In these cases the topology is expected to have 'fixed' parameter for channels/rates/bit depth and the conversion to the fe format is going to be done within the path. In practice this patch fixes issues like: All DMIC formats are fixed four channels We have a component which converts the four channel to stereo FE is opened with 2 channel Even if we have the correct bit depth format and blob (for four channel) we will still be looking for stereo configurations, which will fail. Note: the adjustment of params have switched order with the checking of single bit depth (needed for the NHLT blob fallback support). This change is non function, just that if the sof_ipc4_narrow_params_to_format() would fail, there is no point of checking the single bit depth. Signed-off-by: Peter Ujfalusi <[email protected]> Reviewed-by: Pierre-Louis Bossart <[email protected]> Reviewed-by: Bard Liao <[email protected]> Reviewed-by: Seppo Ingalsuo <[email protected]> Reviewed-by: Ranjani Sridharan <[email protected]> Link: https://msgid.link/r/[email protected] Signed-off-by: Mark Brown <[email protected]> (cherry picked from commit b65456b) Signed-off-by: Jonathan Maple <[email protected]>
…in format jira LE-2290 Rebuild_History Non-Buildable kernel-5.14.0-503.22.1.el9_5 commit-author Peter Ujfalusi <[email protected]> commit fe836c7 It is incorrect to request the input pin format of the destination widget using the output pin index of the source module as the indexes are not necessarily matching. moduleA.out_pin1 can be connected to moduleB.in_pin0 for example. Use the dst_queue_id to request the input format of the destination module. This bug remained unnoticed likely because in nocodec topologies we don't have process modules after a module copier, thus the pin/queue index is ignored. For the process module case, the code was likely have been tested in a controlled way where all the pin/queue/format properties were present to work. Update the debug prints to have better information. Reviewed-by: Kai Vehmanen <[email protected]> Reviewed-by: Ranjani Sridharan <[email protected]> Reviewed-by: Bard Liao <[email protected]> Signed-off-by: Peter Ujfalusi <[email protected]> Signed-off-by: Pierre-Louis Bossart <[email protected]> Cc: [email protected] # v6.8+ Link: https://patch.msgid.link/[email protected] Signed-off-by: Mark Brown <[email protected]> (cherry picked from commit fe836c7) Signed-off-by: Jonathan Maple <[email protected]>
jira LE-2290 Rebuild_History Non-Buildable kernel-5.14.0-503.22.1.el9_5 commit-author Peter Ujfalusi <[email protected]> commit 6558e87 There is no need to keep separate token list for dai and 'common' copier token list when the 'common' list is actually the aif list, the SOF_COPIER_DEEP_BUFFER_TOKENS are not applicable for buffers. We could have separate lists for all types but it is probably simpler to just use a single list for all types of copiers. Function specific tokens will be only parsed by function specific code anyways. Reviewed-by: Bard Liao <[email protected]> Reviewed-by: Ranjani Sridharan <[email protected]> Signed-off-by: Peter Ujfalusi <[email protected]> Signed-off-by: Pierre-Louis Bossart <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Mark Brown <[email protected]> (cherry picked from commit 6558e87) Signed-off-by: Jonathan Maple <[email protected]>
…hainDMA jira LE-2290 Rebuild_History Non-Buildable kernel-5.14.0-503.22.1.el9_5 commit-author Peter Ujfalusi <[email protected]> commit ae67ed9 The DMA Link ID is only valid in snd_sof_dai_config_data when the dai_config is called with HW_PARAMS. The commit that this patch fixes is actually moved a code section without changing it, the same bug exists in the original code, needing different patch to kernel prior to 6.9 kernels. Cc: [email protected] Fixes: 3858464 ("ASoC: SOF: ipc4-topology: change chain_dma handling in dai_config") Link: thesofproject/linux#5116 Signed-off-by: Peter Ujfalusi <[email protected]> Reviewed-by: Bard Liao <[email protected]> Reviewed-by: Ranjani Sridharan <[email protected]> Reviewed-by: Pierre-Louis Bossart <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Mark Brown <[email protected]> (cherry picked from commit ae67ed9) Signed-off-by: Jonathan Maple <[email protected]>
…prepare jira LE-2290 Rebuild_History Non-Buildable kernel-5.14.0-503.22.1.el9_5 commit-author Peter Ujfalusi <[email protected]> commit e6fc5fc The DMA Link ID is set to the IPC message's primary during dai_config, which is only during hw_params. During xrun handling the hw_params is not called and the DMA Link ID information will be lost. All other fields in the message expected to be 0 for re-configuration, only the DMA Link ID needs to be preserved and the in case of repeated dai_config, it is correctly updated (masked and then set). Cc: [email protected] Fixes: ca5ce0c ("ASoC: SOF: ipc4/intel: Add support for chained DMA") Link: thesofproject/linux#5116 Signed-off-by: Peter Ujfalusi <[email protected]> Reviewed-by: Bard Liao <[email protected]> Reviewed-by: Ranjani Sridharan <[email protected]> Reviewed-by: Pierre-Louis Bossart <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Mark Brown <[email protected]> (cherry picked from commit e6fc5fc) Signed-off-by: Jonathan Maple <[email protected]>
jira LE-2290 Rebuild_History Non-Buildable kernel-5.14.0-503.22.1.el9_5 commit-author Justin Tee <[email protected]> commit ede596b The MBX_TIMEOUT return code is not handled in lpfc_get_sfp_info and the routine unconditionally frees submitted mailbox commands regardless of return status. The issue is that for MBX_TIMEOUT cases, when firmware returns SFP information at a later time, that same mailbox memory region references previously freed memory in its cmpl routine. Fix by adding checks for the MBX_TIMEOUT return code. During mailbox resource cleanup, check the mbox flag to make sure that the wait did not timeout. If the MBOX_WAKE flag is not set, then do not free the resources because it will be freed when firmware completes the mailbox at a later time in its cmpl routine. Also, increase the timeout from 30 to 60 seconds to accommodate boot scripts requiring longer timeouts. Signed-off-by: Justin Tee <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Martin K. Petersen <[email protected]> (cherry picked from commit ede596b) Signed-off-by: Jonathan Maple <[email protected]>
…ta paths jira LE-2290 Rebuild_History Non-Buildable kernel-5.14.0-503.22.1.el9_5 commit-author Justin Tee <[email protected]> commit 2be1d4f When the HBA is undergoing a reset or is handling an errata event, NULL ptr dereference crashes may occur in routines such as lpfc_sli_flush_io_rings(), lpfc_dev_loss_tmo_callbk(), or lpfc_abort_handler(). Add NULL ptr checks before dereferencing hdwq pointers that may have been freed due to operations colliding with a reset or errata event handler. Signed-off-by: Justin Tee <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Martin K. Petersen <[email protected]> (cherry picked from commit 2be1d4f) Signed-off-by: Jonathan Maple <[email protected]>
jira LE-2290 Rebuild_History Non-Buildable kernel-5.14.0-503.22.1.el9_5 commit-author Wander Lairson Costa <[email protected]> commit 8b62645 The function __bpf_ringbuf_reserve is invoked from a tracepoint, which disables preemption. Using spinlock_t in this context can lead to a "sleep in atomic" warning in the RT variant. This issue is illustrated in the example below: BUG: sleeping function called from invalid context at kernel/locking/spinlock_rt.c:48 in_atomic(): 1, irqs_disabled(): 0, non_block: 0, pid: 556208, name: test_progs preempt_count: 1, expected: 0 RCU nest depth: 1, expected: 1 INFO: lockdep is turned off. Preemption disabled at: [<ffffd33a5c88ea44>] migrate_enable+0xc0/0x39c CPU: 7 PID: 556208 Comm: test_progs Tainted: G Hardware name: Qualcomm SA8775P Ride (DT) Call trace: dump_backtrace+0xac/0x130 show_stack+0x1c/0x30 dump_stack_lvl+0xac/0xe8 dump_stack+0x18/0x30 __might_resched+0x3bc/0x4fc rt_spin_lock+0x8c/0x1a4 __bpf_ringbuf_reserve+0xc4/0x254 bpf_ringbuf_reserve_dynptr+0x5c/0xdc bpf_prog_ac3d15160d62622a_test_read_write+0x104/0x238 trace_call_bpf+0x238/0x774 perf_call_bpf_enter.isra.0+0x104/0x194 perf_syscall_enter+0x2f8/0x510 trace_sys_enter+0x39c/0x564 syscall_trace_enter+0x220/0x3c0 do_el0_svc+0x138/0x1dc el0_svc+0x54/0x130 el0t_64_sync_handler+0x134/0x150 el0t_64_sync+0x17c/0x180 Switch the spinlock to raw_spinlock_t to avoid this error. Fixes: 457f443 ("bpf: Implement BPF ring buffer and verifier support for it") Reported-by: Brian Grech <[email protected]> Signed-off-by: Wander Lairson Costa <[email protected]> Signed-off-by: Wander Lairson Costa <[email protected]> Signed-off-by: Daniel Borkmann <[email protected]> Acked-by: Daniel Borkmann <[email protected]> Link: https://lore.kernel.org/r/[email protected] (cherry picked from commit 8b62645) Signed-off-by: Jonathan Maple <[email protected]>
jira LE-2290 cve CVE-2024-50275 Rebuild_History Non-Buildable kernel-5.14.0-503.22.1.el9_5 commit-author Mark Brown <[email protected]> commit 751ecf6 The logic for handling SVE traps manipulates saved FPSIMD/SVE state incorrectly, and a race with preemption can result in a task having TIF_SVE set and TIF_FOREIGN_FPSTATE clear even though the live CPU state is stale (e.g. with SVE traps enabled). This has been observed to result in warnings from do_sve_acc() where SVE traps are not expected while TIF_SVE is set: | if (test_and_set_thread_flag(TIF_SVE)) | WARN_ON(1); /* SVE access shouldn't have trapped */ Warnings of this form have been reported intermittently, e.g. https://lore.kernel.org/linux-arm-kernel/CA+G9fYtEGe_DhY2Ms7+L7NKsLYUomGsgqpdBj+QwDLeSg=JhGg@mail.gmail.com/ https://lore.kernel.org/linux-arm-kernel/[email protected]/ The race can occur when the SVE trap handler is preempted before and after manipulating the saved FPSIMD/SVE state, starting and ending on the same CPU, e.g. | void do_sve_acc(unsigned long esr, struct pt_regs *regs) | { | // Trap on CPU 0 with TIF_SVE clear, SVE traps enabled | // task->fpsimd_cpu is 0. | // per_cpu_ptr(&fpsimd_last_state, 0) is task. | | ... | | // Preempted; migrated from CPU 0 to CPU 1. | // TIF_FOREIGN_FPSTATE is set. | | get_cpu_fpsimd_context(); | | if (test_and_set_thread_flag(TIF_SVE)) | WARN_ON(1); /* SVE access shouldn't have trapped */ | | sve_init_regs() { | if (!test_thread_flag(TIF_FOREIGN_FPSTATE)) { | ... | } else { | fpsimd_to_sve(current); | current->thread.fp_type = FP_STATE_SVE; | } | } | | put_cpu_fpsimd_context(); | | // Preempted; migrated from CPU 1 to CPU 0. | // task->fpsimd_cpu is still 0 | // If per_cpu_ptr(&fpsimd_last_state, 0) is still task then: | // - Stale HW state is reused (with SVE traps enabled) | // - TIF_FOREIGN_FPSTATE is cleared | // - A return to userspace skips HW state restore | } Fix the case where the state is not live and TIF_FOREIGN_FPSTATE is set by calling fpsimd_flush_task_state() to detach from the saved CPU state. This ensures that a subsequent context switch will not reuse the stale CPU state, and will instead set TIF_FOREIGN_FPSTATE, forcing the new state to be reloaded from memory prior to a return to userspace. Fixes: cccb78c ("arm64/sve: Rework SVE access trap to convert state in registers") Reported-by: Mark Rutland <[email protected]> Signed-off-by: Mark Brown <[email protected]> Cc: [email protected] Reviewed-by: Mark Rutland <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Will Deacon <[email protected]> (cherry picked from commit 751ecf6) Signed-off-by: Jonathan Maple <[email protected]>
jira LE-2290 Rebuild_History Non-Buildable kernel-5.14.0-503.22.1.el9_5 Rebuild_CHGLOG: - [s390] zcore: WRITE is "data source", not destination... (CKI Backport Bot) [RHEL-63078] Rebuild_FUZZ: 93.33% commit-author Al Viro <[email protected]> commit 4ba48e1 Signed-off-by: Al Viro <[email protected]> (cherry picked from commit 4ba48e1) 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..master: 278851 Number of commits in rpm: 47 Number of commits matched with upstream: 44 (93.62%) Number of commits in upstream but not in rpm: 278807 Number of commits NOT found in upstream: 3 (6.38%) Rebuilding Kernel on Branch rocky9_5_rebuild_kernel-5.14.0-503.22.1.el9_5 for kernel-5.14.0-503.22.1.el9_5 Clean Cherry Picks: 41 (93.18%) Empty Cherry Picks: 3 (6.82%) _______________________________ Full Details Located here: ciq/ciq_backports/kernel-5.14.0-503.22.1.el9_5/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
Since we need to make sure external contributors code actually compiles prior to merging. To get access to the forked repos merge request we need to switch over our push to pull_request. In addition we're fixing up some Naming Conventions, adding aarch64 to this branch and fixing the naming so that we can quickly identify if the CI is for x86_64 or aarch64.
bmastbergen
approved these changes
Jan 28, 2025
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.
🥌
gvrose8192
approved these changes
Jan 29, 2025
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.
LGTM - Thanks!
github-actions bot
pushed a commit
that referenced
this pull request
Aug 9, 2025
Our testcase trigger panic: BUG: kernel NULL pointer dereference, address: 00000000000000e0 ... Oops: Oops: 0000 [#1] SMP NOPTI CPU: 2 UID: 0 PID: 85 Comm: kworker/2:1 Not tainted 6.16.0+ #94 PREEMPT(none) Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.1-2.fc37 04/01/2014 Workqueue: md_misc md_start_sync RIP: 0010:rdev_addable+0x4d/0xf0 ... Call Trace: <TASK> md_start_sync+0x329/0x480 process_one_work+0x226/0x6d0 worker_thread+0x19e/0x340 kthread+0x10f/0x250 ret_from_fork+0x14d/0x180 ret_from_fork_asm+0x1a/0x30 </TASK> Modules linked in: raid10 CR2: 00000000000000e0 ---[ end trace 0000000000000000 ]--- RIP: 0010:rdev_addable+0x4d/0xf0 md_spares_need_change in md_start_sync will call rdev_addable which protected by rcu_read_lock/rcu_read_unlock. This rcu context will help protect rdev won't be released, but rdev->mddev will be set to NULL before we call synchronize_rcu in md_kick_rdev_from_array. Fix this by using READ_ONCE and check does rdev->mddev still alive. Fixes: bc08041 ("md: suspend array in md_start_sync() if array need reconfiguration") Fixes: 570b914 ("md: use RCU lock to protect traversal in md_spares_need_change()") Signed-off-by: Yang Erkun <[email protected]> Link: https://lore.kernel.org/linux-raid/[email protected] Signed-off-by: Yu Kuai <[email protected]>
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.