Rebuild rocky8_10 with kernel-4.18.0-553.36.1.el8_10 #92
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
Collaborator
PlaidCat
commented
Jan 27, 2025
PlaidCat
commented
jira LE-2289 cve CVE-2024-53088 Rebuild_History Non-Buildable kernel-4.18.0-553.34.1.el8_10 commit-author Aleksandr Loktionov <aleksandr.loktionov@intel.com> commit eb58c59 The bug usually affects untrusted VFs, because they are limited to 18 MACs, it affects them badly, not letting to create MAC all filters. Not stable to reproduce, it happens when VF user creates MAC filters when other MACVLAN operations are happened in parallel. But consequence is that VF can't receive desired traffic. Fix counter to be bumped only for new or active filters. Fixes: 621650c ("i40e: Refactoring VF MAC filters counting to make more reliable") Signed-off-by: Aleksandr Loktionov <aleksandr.loktionov@intel.com> Reviewed-by: Arkadiusz Kubalewski <arkadiusz.kubalewski@intel.com> Reviewed-by: Paul Menzel <pmenzel@molgen.mpg.de> Tested-by: Rafal Romanowski <rafal.romanowski@intel.com> Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com> (cherry picked from commit eb58c59) Signed-off-by: Jonathan Maple <jmaple@ciq.com>
jira LE-2289 cve CVE-2024-53088 Rebuild_History Non-Buildable kernel-4.18.0-553.34.1.el8_10 commit-author Aleksandr Loktionov <aleksandr.loktionov@intel.com> commit f30490e Fix a race condition in the i40e driver that leads to MAC/VLAN filters becoming corrupted and leaking. Address the issue that occurs under heavy load when multiple threads are concurrently modifying MAC/VLAN filters by setting mac and port VLAN. 1. Thread T0 allocates a filter in i40e_add_filter() within i40e_ndo_set_vf_port_vlan(). 2. Thread T1 concurrently frees the filter in __i40e_del_filter() within i40e_ndo_set_vf_mac(). 3. Subsequently, i40e_service_task() calls i40e_sync_vsi_filters(), which refers to the already freed filter memory, causing corruption. Reproduction steps: 1. Spawn multiple VFs. 2. Apply a concurrent heavy load by running parallel operations to change MAC addresses on the VFs and change port VLANs on the host. 3. Observe errors in dmesg: "Error I40E_AQ_RC_ENOSPC adding RX filters on VF XX, please set promiscuous on manually for VF XX". Exact code for stable reproduction Intel can't open-source now. The fix involves implementing a new intermediate filter state, I40E_FILTER_NEW_SYNC, for the time when a filter is on a tmp_add_list. These filters cannot be deleted from the hash list directly but must be removed using the full process. Fixes: 278e7d0 ("i40e: store MAC/VLAN filters in a hash with the MAC Address as key") Signed-off-by: Aleksandr Loktionov <aleksandr.loktionov@intel.com> Tested-by: Pucha Himasekhar Reddy <himasekharx.reddy.pucha@intel.com> (A Contingent worker at Intel) Reviewed-by: Michal Schmidt <mschmidt@redhat.com> Tested-by: Michal Schmidt <mschmidt@redhat.com> Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com> (cherry picked from commit f30490e) Signed-off-by: Jonathan Maple <jmaple@ciq.com>
jira LE-2289 Rebuild_History Non-Buildable kernel-4.18.0-553.34.1.el8_10 commit-author Alexander Aring <aahringo@redhat.com> commit f74dacb 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-4.18.0-553.34.1.el8_10/f74dacb4.failed In one special case, recovery is unable to reliably rebuild lock state by simply recreating lkb structs as sent from the lock holders. That case is when the lkb's include conversions between PR and CW modes. The recovery code has always recognized this special case, but the implemention has always been broken, and would set invalid modes in recovered lkb's. Unpredictable or bogus errors could then be returned for further locking calls on these locks. This bug has gone unnoticed for so long due to some combination of: - applications never or infrequently converting between PR/CW - recovery not occuring during these conversions - if the recovery bug does occur, the caller may not notice, depending on what further locking calls are made, e.g. if the lock is simply unlocked it may go unnoticed However, a core analysis from a recent gfs2 bug report points to this broken code. PR = Protected Read CW = Concurrent Write PR and CW are incompatible PR and PR are compatible CW and CW are compatible Example 1 node C, resource R granted: PR node A granted: PR node B granted: NL node C granted: NL node D - A sends convert PR->CW to C - C fails before A gets a reply - recovery occurs At this point, A does not know if it still holds the lock in PR, or if its conversion to CW was granted: - If A's conversion to CW was granted, then another node's CW lock may also have been granted. - If A's conversion to CW was not granted, it still holds a PR lock, and other nodes may also hold PR locks. So, the new master of R cannot simply recreate the lock from A using granted mode PR and requested mode CW. The new master must look at all the recovered locks to determine the correct granted modes, and ensure that all the recovered locks are recreated in compatible states. The correct lock recovery steps in this example are: - node D becomes the new master of R - node B sends D its lkb, granted PR - node A sends D its lkb, convert PR->CW - D determines the correct lock state is: granted: PR node B convert: PR->CW node A The lkb sent by each node was recreated without any change on the new master node. Example 2 node C, resource R granted: PR node A granted: NL node C granted: NL node D waiting: CW node B - A sends convert PR->CW to C - C grants the conversion to CW for A - C grants the waiting request for CW to B - C sends granted message to B, but fails before it can send the granted message to A - B receives the granted message from C At this point: - A believes it is converting PR->CW - B believes it is holding a CW lock The correct lock recovery steps in this example are: - node D becomes the new master of R - node A sends D its lkb, convert PR->CW - node B sends D its lkb, granted CW - D determins the correct lock state is: granted: CW node B granted: CW node A The lkb sent by B is recreated without change, but the lkb sent by A is changed because the granted mode was not compatible. Fixes to make this work correctly: recover_convert_waiter: should not make any changes to a converting lkb that is still waiting for a reply message. It was previously setting grmode to IV, which is invalid state, so the lkb would not be handled correctly by other code. receive_rcom_lock_args: was checking the wrong lkb field (wait_type instead of status) to determine if the lkb is being converted, and in need of inspection for this special recovery. It was also setting grmode to IV in the lkb, causing it to be mishandled by other code. Now, this function just puts the lkb, directly as sent, onto the convert queue of the resource being recovered, and corrects it in recover_conversion() later, if needed. recover_conversion: the job of this function is to detect and correct lkb states for the special PR/CW conversions. The new code now checks for recovered lkbs on the granted queue with grmode PR or CW, and takes the real grmode from that. Then it looks for lkbs on the convert queue with an incompatible grmode (i.e. grmode PR when the real grmode is CW, or v.v.) These converting lkbs need to be fixed. They are fixed by temporarily setting their grmode to NL, so that grmodes are not incompatible and won't confuse other locking code. The converting lkb will then be granted at the end of recovery, replacing the temporary NL grmode. Signed-off-by: Alexander Aring <aahringo@redhat.com> Signed-off-by: David Teigland <teigland@redhat.com> (cherry picked from commit f74dacb) Signed-off-by: Jonathan Maple <jmaple@ciq.com> # Conflicts: # fs/dlm/lock.c
jira LE-2289 Rebuild_History Non-Buildable kernel-4.18.0-553.34.1.el8_10 commit-author Paolo Bonzini <pbonzini@redhat.com> commit 6890cb1 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-4.18.0-553.34.1.el8_10/6890cb1a.failed MKTME repurposes the high bit of physical address to key id for encryption key and, even though MAXPHYADDR in CPUID[0x80000008] remains the same, the valid bits in the MTRR mask register are based on the reduced number of physical address bits. detect_tme() in arch/x86/kernel/cpu/intel.c detects TME and subtracts it from the total usable physical bits, but it is called too late. Move the call to early_init_intel() so that it is called in setup_arch(), before MTRRs are setup. This fixes boot on TDX-enabled systems, which until now only worked with "disable_mtrr_cleanup". Without the patch, the values written to the MTRRs mask registers were 52-bit wide (e.g. 0x000fffff_80000800) and the writes failed; with the patch, the values are 46-bit wide, which matches the reduced MAXPHYADDR that is shown in /proc/cpuinfo. Reported-by: Zixi Chen <zixchen@redhat.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> Signed-off-by: Dave Hansen <dave.hansen@linux.intel.com> Cc:stable@vger.kernel.org Link: https://lore.kernel.org/all/20240131230902.1867092-3-pbonzini%40redhat.com (cherry picked from commit 6890cb1) Signed-off-by: Jonathan Maple <jmaple@ciq.com> # Conflicts: # arch/x86/kernel/cpu/intel.c
jira LE-2289 Rebuild_History Non-Buildable kernel-4.18.0-553.34.1.el8_10 commit-author Sean Christopherson <seanjc@google.com> commit f1187ef Fix a goof where KVM tries to grab source vCPUs from the destination VM when doing intrahost migration. Grabbing the wrong vCPU not only hoses the guest, it also crashes the host due to the VMSA pointer being left NULL. BUG: unable to handle page fault for address: ffffe38687000000 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page PGD 0 P4D 0 Oops: 0000 [#1] SMP NOPTI CPU: 39 PID: 17143 Comm: sev_migrate_tes Tainted: GO 6.5.0-smp--fff2e47e6c3b-next #151 Hardware name: Google, Inc. Arcadia_IT_80/Arcadia_IT_80, BIOS 34.28.0 07/10/2023 RIP: 0010:__free_pages+0x15/0xd0 RSP: 0018:ffff923fcf6e3c78 EFLAGS: 00010246 RAX: 0000000000000000 RBX: ffffe38687000000 RCX: 0000000000000100 RDX: 0000000000000100 RSI: 0000000000000000 RDI: ffffe38687000000 RBP: ffff923fcf6e3c88 R08: ffff923fcafb0000 R09: 0000000000000000 R10: 0000000000000000 R11: ffffffff83619b90 R12: ffff923fa9540000 R13: 0000000000080007 R14: ffff923f6d35d000 R15: 0000000000000000 FS: 0000000000000000(0000) GS:ffff929d0d7c0000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: ffffe38687000000 CR3: 0000005224c34005 CR4: 0000000000770ee0 PKRU: 55555554 Call Trace: <TASK> sev_free_vcpu+0xcb/0x110 [kvm_amd] svm_vcpu_free+0x75/0xf0 [kvm_amd] kvm_arch_vcpu_destroy+0x36/0x140 [kvm] kvm_destroy_vcpus+0x67/0x100 [kvm] kvm_arch_destroy_vm+0x161/0x1d0 [kvm] kvm_put_kvm+0x276/0x560 [kvm] kvm_vm_release+0x25/0x30 [kvm] __fput+0x106/0x280 ____fput+0x12/0x20 task_work_run+0x86/0xb0 do_exit+0x2e3/0x9c0 do_group_exit+0xb1/0xc0 __x64_sys_exit_group+0x1b/0x20 do_syscall_64+0x41/0x90 entry_SYSCALL_64_after_hwframe+0x63/0xcd </TASK> CR2: ffffe38687000000 Fixes: 6defa24 ("KVM: SEV: Init target VMCBs in sev_migrate_from") Cc: stable@vger.kernel.org Cc: Peter Gonda <pgonda@google.com> Reviewed-by: Peter Gonda <pgonda@google.com> Reviewed-by: Pankaj Gupta <pankaj.gupta@amd.com> Link: https://lore.kernel.org/r/20230825022357.2852133-2-seanjc@google.com Signed-off-by: Sean Christopherson <seanjc@google.com> (cherry picked from commit f1187ef) Signed-off-by: Jonathan Maple <jmaple@ciq.com>
jira LE-2289 Rebuild_History Non-Buildable kernel-4.18.0-553.34.1.el8_10 commit-author Dave Chinner <dchinner@redhat.com> commit 1332533 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-4.18.0-553.34.1.el8_10/13325333.failed The runt AG at the end of a filesystem is almost always smaller than the mp->m_sb.sb_agblocks. Unfortunately, when setting the max_agbno limit for the inode chunk allocation, we do not take this into account. This means we can allocate a sparse inode chunk that overlaps beyond the end of an AG. When we go to allocate an inode from that sparse chunk, the irec fails validation because the agbno of the start of the irec is beyond valid limits for the runt AG. Prevent this from happening by taking into account the size of the runt AG when allocating inode chunks. Also convert the various checks for valid inode chunk agbnos to use xfs_ag_block_count() so that they will also catch such issues in the future. Fixes: 56d1115 ("xfs: allocate sparse inode chunks on full chunk allocation failure") Signed-off-by: Dave Chinner <dchinner@redhat.com> Reviewed-by: Darrick J. Wong <djwong@kernel.org> Signed-off-by: Carlos Maiolino <cem@kernel.org> (cherry picked from commit 1332533) Signed-off-by: Jonathan Maple <jmaple@ciq.com> # Conflicts: # fs/xfs/libxfs/xfs_ialloc.c
…k code jira LE-2289 Rebuild_History Non-Buildable kernel-4.18.0-553.34.1.el8_10 commit-author Trond Myklebust <trond.myklebust@hammerspace.com> commit b1a28f2 It is not safe to call filemap_fdatawrite_range() from nfs_async_write_reschedule_io(), since we're often calling from a page reclaim context. Just let fsync() redrive the writeback for us. Signed-off-by: Trond Myklebust <trond.myklebust@hammerspace.com> (cherry picked from commit b1a28f2) Signed-off-by: Jonathan Maple <jmaple@ciq.com>
jira LE-2289 cve CVE-2024-53122 Rebuild_History Non-Buildable kernel-4.18.0-553.34.1.el8_10 commit-author Paolo Abeni <pabeni@redhat.com> commit ce7356a 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-4.18.0-553.34.1.el8_10/ce7356ae.failed Additional active subflows - i.e. created by the in kernel path manager - are included into the subflow list before starting the 3whs. A racing recvmsg() spooling data received on an already established subflow would unconditionally call tcp_cleanup_rbuf() on all the current subflows, potentially hitting a divide by zero error on the newly created ones. Explicitly check that the subflow is in a suitable state before invoking tcp_cleanup_rbuf(). Fixes: c76c695 ("mptcp: call tcp_cleanup_rbuf on subflows") Signed-off-by: Paolo Abeni <pabeni@redhat.com> Reviewed-by: Matthieu Baerts (NGI0) <matttbe@kernel.org> Link: https://patch.msgid.link/02374660836e1b52afc91966b7535c8c5f7bafb0.1731060874.git.pabeni@redhat.com Signed-off-by: Jakub Kicinski <kuba@kernel.org> (cherry picked from commit ce7356a) Signed-off-by: Jonathan Maple <jmaple@ciq.com> # Conflicts: # net/mptcp/protocol.c
Rebuild_History BUILDABLE Rebuilding Kernel from rpm changelog with Fuzz Limit: 87.50% Number of commits in upstream range v4.18~1..master: 522243 Number of commits in rpm: 14 Number of commits matched with upstream: 8 (57.14%) Number of commits in upstream but not in rpm: 522235 Number of commits NOT found in upstream: 6 (42.86%) Rebuilding Kernel on Branch rocky8_10_rebuild_kernel-4.18.0-553.34.1.el8_10 for kernel-4.18.0-553.34.1.el8_10 Clean Cherry Picks: 4 (50.00%) Empty Cherry Picks: 4 (50.00%) _______________________________ Full Details Located here: ciq/ciq_backports/kernel-4.18.0-553.34.1.el8_10/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
jira LE-2289 Rebuild_History Non-Buildable kernel-4.18.0-553.36.1.el8_10 commit-author Michael Kelley <mikelley@microsoft.com> commit 812fe64 Testing of virtual Fibre Channel devices under Hyper-V has shown additional SRB status values being returned for various error cases. Because these SRB status values are not recognized by storvsc, the I/O operations are not flagged as an error. Requests are treated as if they completed normally but with zero data transferred, which can cause a flood of retries. Add definitions for these SRB status values and handle them like other error statuses from the Hyper-V host. Signed-off-by: Michael Kelley <mikelley@microsoft.com> Link: https://lore.kernel.org/r/1692984084-95105-1-git-send-email-mikelley@microsoft.com Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com> (cherry picked from commit 812fe64) Signed-off-by: Jonathan Maple <jmaple@ciq.com>
…VERRUN as an error jira LE-2289 Rebuild_History Non-Buildable kernel-4.18.0-553.36.1.el8_10 commit-author Cathy Avery <cavery@redhat.com> commit b1aee7f This partially reverts commit 812fe64 ("scsi: storvsc: Handle additional SRB status values"). HyperV does not support MAINTENANCE_IN resulting in FC passthrough returning the SRB_STATUS_DATA_OVERRUN value. Now that SRB_STATUS_DATA_OVERRUN is treated as an error, multipath ALUA paths go into a faulty state as multipath ALUA submits RTPG commands via MAINTENANCE_IN. [ 3.215560] hv_storvsc 1d69d403-9692-4460-89f9-a8cbcc0f94f3: tag#230 cmd 0xa3 status: scsi 0x0 srb 0x12 hv 0xc0000001 [ 3.215572] scsi 1:0:0:32: alua: rtpg failed, result 458752 Make MAINTENANCE_IN return success to avoid the error path as is currently done with INQUIRY and MODE_SENSE. Suggested-by: Michael Kelley <mhklinux@outlook.com> Signed-off-by: Cathy Avery <cavery@redhat.com> Link: https://lore.kernel.org/r/20241127181324.3318443-1-cavery@redhat.com Reviewed-by: Michael Kelley <mhklinux@outlook.com> Reviewed-by: Ewan D. Milne <emilne@redhat.com> Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com> (cherry picked from commit b1aee7f) Signed-off-by: Jonathan Maple <jmaple@ciq.com>
jira LE-2289 Rebuild_History Non-Buildable kernel-4.18.0-553.36.1.el8_10 commit-author Daniel T. Lee <danieltimlee@gmail.com> commit 226b96c This commit adds port parsing and port validate helper function to parse single or range of port(s) from a given string. (e.g. 1234, 443-444) Helpers will be used in prior to set target port(s) in samples/pktgen. Signed-off-by: Daniel T. Lee <danieltimlee@gmail.com> Acked-by: Jesper Dangaard Brouer <brouer@redhat.com> Signed-off-by: David S. Miller <davem@davemloft.net> (cherry picked from commit 226b96c) Signed-off-by: Jonathan Maple <jmaple@ciq.com>
jira LE-2289 Rebuild_History Non-Buildable kernel-4.18.0-553.36.1.el8_10 commit-author Daniel T. Lee <danieltimlee@gmail.com> commit 6e32a74 Currently, kernel pktgen has the feature to specify udp destination port for sending packet. (e.g. pgset "udp_dst_min 9") But on samples, each of the scripts doesn't have any option to achieve this. This commit adds the DST_PORT option to specify the target port(s) in the script. -p : ($DST_PORT) destination PORT range (e.g. 433-444) is also allowed Signed-off-by: Daniel T. Lee <danieltimlee@gmail.com> Acked-by: Jesper Dangaard Brouer <brouer@redhat.com> Signed-off-by: David S. Miller <davem@davemloft.net> (cherry picked from commit 6e32a74) Signed-off-by: Jonathan Maple <jmaple@ciq.com>
jira LE-2289 Rebuild_History Non-Buildable kernel-4.18.0-553.36.1.el8_10 commit-author Kai Mäkisara <Kai.Makisara@kolumbus.fi> commit 5bb2d61 Struct mtget field mt_blkno -1 means it is unknown. Don't add anything to it. Signed-off-by: Kai Mäkisara <Kai.Makisara@kolumbus.fi> Link: https://bugzilla.kernel.org/show_bug.cgi?id=219419#c14 Link: https://lore.kernel.org/r/20241106095723.63254-2-Kai.Makisara@kolumbus.fi Reviewed-by: John Meneghini <jmeneghi@redhat.com> Tested-by: John Meneghini <jmeneghi@redhat.com> Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com> (cherry picked from commit 5bb2d61) Signed-off-by: Jonathan Maple <jmaple@ciq.com>
jira LE-2289 Rebuild_History Non-Buildable kernel-4.18.0-553.36.1.el8_10 commit-author Kai Mäkisara <Kai.Makisara@kolumbus.fi> commit 0b120ed Most drives rewind the tape when the device is reset. Reading and writing are not allowed until something is done to make the tape position match the user's expectation (e.g., rewind the tape). Add MTIOCGET and MTLOAD to operations allowed after reset. MTIOCGET is modified to not touch the tape if pos_unknown is non-zero. The tape location is known after MTLOAD. Signed-off-by: Kai Mäkisara <Kai.Makisara@kolumbus.fi> Link: https://bugzilla.kernel.org/show_bug.cgi?id=219419#c14 Link: https://lore.kernel.org/r/20241106095723.63254-3-Kai.Makisara@kolumbus.fi Reviewed-by: John Meneghini <jmeneghi@redhat.com> Tested-by: John Meneghini <jmeneghi@redhat.com> Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com> (cherry picked from commit 0b120ed) Signed-off-by: Jonathan Maple <jmaple@ciq.com>
jira LE-2289 Rebuild_History Non-Buildable kernel-4.18.0-553.36.1.el8_10 commit-author Kai Mäkisara <Kai.Makisara@kolumbus.fi> commit a4550b2 Currently the code starts new tape session when any Unit Attention (UA) is seen when opening the device. This leads to incorrectly clearing pos_unknown when the UA is for reset. Set new session only when the UA is for a new tape. Signed-off-by: Kai Mäkisara <Kai.Makisara@kolumbus.fi> Link: https://lore.kernel.org/r/20241106095723.63254-4-Kai.Makisara@kolumbus.fi Reviewed-by: John Meneghini <jmeneghi@redhat.com> Tested-by: John Meneghini <jmeneghi@redhat.com> Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com> (cherry picked from commit a4550b2) Signed-off-by: Jonathan Maple <jmaple@ciq.com>
jira LE-2289 Rebuild_History Non-Buildable kernel-4.18.0-553.36.1.el8_10 commit-author Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com> commit 7e1c3f5 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-4.18.0-553.36.1.el8_10/7e1c3f58.failed Prevent intel_pstate from loading when OOB (Out Of Band) P-states mode is enabled in Emerald Rapids. The OOB identifying bits are same as for the prior generation CPUs like Sapphire Rapids servers, so also add Emerald Rapids to the intel_pstate_cpu_oob_ids[] list. Signed-off-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> (cherry picked from commit 7e1c3f5) Signed-off-by: Jonathan Maple <jmaple@ciq.com> # Conflicts: # drivers/cpufreq/intel_pstate.c
Rebuild_History BUILDABLE Rebuilding Kernel from rpm changelog with Fuzz Limit: 87.50% Number of commits in upstream range v4.18~1..master: 522243 Number of commits in rpm: 15 Number of commits matched with upstream: 9 (60.00%) Number of commits in upstream but not in rpm: 522234 Number of commits NOT found in upstream: 6 (40.00%) Rebuilding Kernel on Branch rocky8_10_rebuild_kernel-4.18.0-553.36.1.el8_10 for kernel-4.18.0-553.36.1.el8_10 Clean Cherry Picks: 7 (77.78%) Empty Cherry Picks: 1 (11.11%) _______________________________ Full Details Located here: ciq/ciq_backports/kernel-4.18.0-553.36.1.el8_10/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
changed the title
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. Also disable the process-pull-request until the `utf-8` situation is resolved.
PlaidCat
force-pushed
the
rocky8_10_rebuild
branch
from
c497b60 to
b6f3b5c
Compare
gvrose8192
approved these changes
Jan 27, 2025
Thanks, I also checked the stats for the changelog lines that we couldn't fine they're just the RESF specific changes and those are always never found (for obvious reasons) |
bmastbergen
approved these changes
Jan 28, 2025
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.