This project is mirrored from https://gitlab.com/redhat/centos-stream/src/kernel/centos-stream-10.git.
Pull mirroring updated .
- Mar 07, 2025
-
-
Julio Faracco authored
Signed-off-by:Julio Faracco <jfaracco@redhat.com>
-
Julio Faracco authored
MR: https://gitlab.com/redhat/centos-stream/src/kernel/centos-stream-10/-/merge_requests/190 JIRA: https://issues.redhat.com/browse/RHEL-80305 CVE: CVE-2024-57902 ``` af_packet: fix vlan_get_tci() vs MSG_PEEK Blamed commit forgot MSG_PEEK case, allowing a crash [1] as found by syzbot. Rework vlan_get_tci() to not touch skb at all, so that it can be used from many cpus on the same skb. Add a const qualifier to skb argument. [1] skbuff: skb_under_panic: text:ffffffff8a8da482 len:32 put:14 head:ffff88807a1d5800 data:ffff88807a1d5810 tail:0x14 end:0x140 dev:<NULL> ------------[ cut here ]------------ kernel BUG at net/core/skbuff.c:206 ! Oops: invalid opcode: 0000 [#1] PREEMPT SMP KASAN PTI CPU: 0 UID: 0 PID: 5880 Comm: syz-executor172 Not tainted 6.13.0-rc3-syzkaller-00762-g9268abe611b0 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/13/2024 RIP: 0010:skb_panic net/core/skbuff.c:206 [inline] RIP: 0010:skb_under_panic+0x14b/0x150 net/core/skbuff.c:216 Code: 0b 8d 48 c7 c6 9e 6c 26 8e 48 8b 54 24 08 8b 0c 24 44 8b 44 24 04 4d 89 e9 50 41 54 41 57 41 56 e8 3a 5a 79 f7 48 83 c4 20 90 <0f> 0b 0f 1f 00 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 f3 RSP: 0018:ffffc90003baf5b8 EFLAGS: 00010286 RAX: 0000000000000087 RBX: dffffc0000000000 RCX: 8565c1eec37aa000 RDX: 0000000000000000 RSI: 0000000080000000 RDI: 0000000000000000 RBP: ffff88802616fb50 R08: ffffffff817f0a4c R09: 1ffff92000775e50 R10: dffffc0000000000 R11: fffff52000775e51 R12: 0000000000000140 R13: ffff88807a1d5800 R14: ffff88807a1d5810 R15: 0000000000000014 FS: 00007fa03261f6c0(0000) GS:ffff8880b8600000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007ffd65753000 CR3: 0000000031720000 CR4: 00000000003526f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: <TASK> skb_push+0xe5/0x100 net/core/skbuff.c:2636 vlan_get_tci+0x272/0x550 net/packet/af_packet.c:565 packet_recvmsg+0x13c9/0x1ef0 net/packet/af_packet.c:3616 sock_recvmsg_nosec net/socket.c:1044 [inline] sock_recvmsg+0x22f/0x280 net/socket.c:1066 ____sys_recvmsg+0x1c6/0x480 net/socket.c:2814 ___sys_recvmsg net/socket.c:2856 [inline] do_recvmmsg+0x426/0xab0 net/socket.c:2951 __sys_recvmmsg net/socket.c:3025 [inline] __do_sys_recvmmsg net/socket.c:3048 [inline] __se_sys_recvmmsg net/socket.c:3041 [inline] __x64_sys_recvmmsg+0x199/0x250 net/socket.c:3041 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83 Fixes: 79eecf63 ("af_packet: Handle outgoing VLAN packets without hardware offloading") Reported-by:
<syzbot+8400677f3fd43f37d3bc@syzkaller.appspotmail.com> Closes: https://lore.kernel.org/netdev/6772c485.050a0220.2f3838.04c6.GAE@google.com/T/#u Signed-off-by:
Eric Dumazet <edumazet@google.com> Cc: Chengen Du <chengen.du@canonical.com> Reviewed-by:
Willem de Bruijn <willemb@google.com> Link: https://patch.msgid.link/20241230161004.2681892-1-edumazet@google.com Signed-off-by:
Jakub Kicinski <kuba@kernel.org> (cherry picked from commit 77ee7a6d16b6ec07b5c3ae2b6b60a24c1afbed09) ``` Signed-off-by:
CKI Backport Bot <cki-ci-bot+cki-gitlab-backport-bot@redhat.com> --- <small>Created 2025-01-15 15:13 UTC by backporter - [KWF FAQ](https://red.ht/kernel_workflow_doc) - [Slack #team-kernel-workflow](https://redhat-internal.slack.com/archives/C04LRUPMJQ5) - [Source](https://gitlab.com/cki-project/kernel-workflow/-/blob/main/webhook/utils/backporter.py) - [Documentation](https://gitlab.com/cki-project/kernel-workflow/-/blob/main/docs/README.backporter.md) - [Report an issue](https://gitlab.com/cki-project/kernel-workflow/-/issues/new?issue%5Btitle%5D=backporter%20webhook%20issue)</small > Approved-by:
Hangbin Liu <haliu@redhat.com> Approved-by:
Xin Long <lxin@redhat.com> Merged-by:
-
Julio Faracco authored
MR: https://gitlab.com/redhat/centos-stream/src/kernel/centos-stream-10/-/merge_requests/412 JIRA: https://issues.redhat.com/browse/RHEL-80534 Signed-off-by:
Paulo Alcantara <paalcant@redhat.com> Approved-by:
Scott Mayhew <smayhew@redhat.com> Approved-by:
Jay Shin <jaeshin@redhat.com> Merged-by:
-
Julio Faracco authored
MR: https://gitlab.com/redhat/centos-stream/src/kernel/centos-stream-10/-/merge_requests/470 JIRA: https://issues.redhat.com/browse/RHEL-81482 CVE: CVE-2025-21771 ``` commit d6f3e7d564b2309e1f17e709a70eca78d7ca2bb8 Author: Tejun Heo <tj@kernel.org> Date: Fri Jan 24 12:22:12 2025 -1000 sched_ext: Fix incorrect autogroup migration detection scx_move_task() is called from sched_move_task() and tells the BPF scheduler that cgroup migration is being committed. sched_move_task() is used by both cgroup and autogroup migrations and scx_move_task() tried to filter out autogroup migrations by testing the destination cgroup and PF_EXITING but this is not enough. In fact, without explicitly tagging the thread which is doing the cgroup migration, there is no good way to tell apart scx_move_task() invocations for racing migration to the root cgroup and an autogroup migration. This led to scx_move_task() incorrectly ignoring a migration from non-root cgroup to an autogroup of the root cgroup triggering the following warning: WARNING: CPU: 7 PID: 1 at kernel/sched/ext.c:3725 scx_cgroup_can_attach+0x196/0x340 ... Call Trace: <TASK> cgroup_migrate_execute+0x5b1/0x700 cgroup_attach_task+0x296/0x400 __cgroup_procs_write+0x128/0x140 cgroup_procs_write+0x17/0x30 kernfs_fop_write_iter+0x141/0x1f0 vfs_write+0x31d/0x4a0 __x64_sys_write+0x72/0xf0 do_syscall_64+0x82/0x160 entry_SYSCALL_64_after_hwframe+0x76/0x7e Fix it by adding an argument to sched_move_task() that indicates whether the moving is for a cgroup or autogroup migration. After the change, scx_move_task() is called only for cgroup migrations and renamed to scx_cgroup_move_task(). Link: https://github.com/sched-ext/scx/issues/370 Fixes: 81951366 ("sched_ext: Add cgroup support") Cc: stable@vger.kernel.org # v6.12+ Acked-by:
Peter Zijlstra (Intel) <peterz@infradead.org> Signed-off-by:
Tejun Heo <tj@kernel.org>```> Signed-off-by:
Phil Auld <pauld@redhat.com> Merged-by:
-
Julio Faracco authored
MR: https://gitlab.com/redhat/centos-stream/src/kernel/centos-stream-10/-/merge_requests/395 ``` JIRA: https://issues.redhat.com/browse/RHEL-47437 Add new VMD Device ID and while at it, include a VMD related bug fix. Signed-off-by:
Myron Stowe <mstowe@redhat.com> ``` Approved-by:
David Arcari <darcari@redhat.com> Approved-by:
Steve Best <sbest@redhat.com> Approved-by:
John W. Linville <linville@redhat.com> Approved-by:
Jiri Dluhos <jdluhos@redhat.com> Merged-by:
-
Julio Faracco authored
MR: https://gitlab.com/redhat/centos-stream/src/kernel/centos-stream-10/-/merge_requests/427 JIRA: https://issues.redhat.com/browse/RHEL-80626 Upstream Status: ARK commit bc86c1c47085637adec8627f507a9130211f5178 commit bc86c1c47085637adec8627f507a9130211f5178 Author: Jan Stancek <jstancek@redhat.com> Date: Tue Feb 25 03:59:52 2025 -0500 kernel.spec: add missing tools-libs on s390x tools-libs-devel requires tools-libs. Previously on s390x they would be both skipped by %cpupowerarches check. But after adding ynl headers and library to tools-libs-devel, it is now built also on s390x. But tools-libs is still skipped and creates a missing dependency. We could conditionally skip the Requires on s390x, but that adds extra burden to keep such condition up to date as more artefacts get introduced to tools-libs-devel in future. Simplest is to just create tools-libs on s390x, even if it ends up empty for now. Fixes: e9f967afa161 ("redhat: kernel.spec: add ynl to kernel-tools") Reported-by:
Bruno Goncalves <bgoncalv@redhat.com> Signed-off-by:
Jan Stancek <jstancek@redhat.com> Signed-off-by:
Daniel Horak <dhorak@redhat.com> Approved-by:
Scott Weaver <scweaver@redhat.com> Merged-by:
-
Julio Faracco authored
MR: https://gitlab.com/redhat/centos-stream/src/kernel/centos-stream-10/-/merge_requests/489 JIRA: https://issues.redhat.com/browse/RHEL-81669 CVE: CVE-2025-21785 ``` commit 875d742cf5327c93cba1f11e12b08d3cce7a88d2 Author: Radu Rendec <rrendec@redhat.com> Date: Thu Feb 6 12:44:20 2025 -0500 arm64: cacheinfo: Avoid out-of-bounds write to cacheinfo array The loop that detects/populates cache information already has a bounds check on the array size but does not account for cache levels with separate data/instructions cache. Fix this by incrementing the index for any populated leaf (instead of any populated level). Fixes: 5d425c18 ("arm64: kernel: add support for cpu cache information") Signed-off-by:
Radu Rendec <rrendec@redhat.com> Link: https://lore.kernel.org/r/20250206174420.2178724-1-rrendec@redhat.com Signed-off-by:
Will Deacon <will@kernel.org>```> Signed-off-by:
-
Julio Faracco authored
MR: https://gitlab.com/redhat/centos-stream/src/kernel/centos-stream-10/-/merge_requests/414 JIRA: https://issues.redhat.com/browse/RHEL-76749 Build Info: https://brewweb.engineering.redhat.com/brew/taskinfo?taskID=66787277 Tested: Verified Brew build test kernel RPMs Signed-off-by:
Mamatha Inamdar <minamdar@redhat.com> commit 6efbd5ddb6af0408301b4c15b413e6425c7650b2 Author: Sourabh Jain <sourabhjain@linux.ibm.com> Date: Sat Sep 21 16:07:45 2024 +0530 kexec/crash: no crash update when kexec in progress The following errors are observed when kexec is done with SMT=off on powerpc. [ 358.458385] Removing IBM Power 842 compression device [ 374.795734] kexec_core: Starting new kernel [ 374.795748] kexec: Waking offline cpu 1. [ 374.875695] crash hp: kexec_trylock() failed, elfcorehdr may be inaccurate [ 374.935833] kexec: Waking offline cpu 2. [ 375.015664] crash hp: kexec_trylock() failed, elfcorehdr may be inaccurate snip.. [ 375.515823] kexec: Waking offline cpu 6. [ 375.635667] crash hp: kexec_trylock() failed, elfcorehdr may be inaccurate [ 375.695836] kexec: Waking offline cpu 7. To avoid kexec kernel boot failure on PowerPC, all the present CPUs that are offline are brought online during kexec. For more information, refer to commit e8e5c215 ("powerpc/kexec: Fix orphaned offline CPUs across kexec"). Bringing the CPUs online triggers the crash hotplug handler, crash_handle_hotplug_event(), to update the kdump image. Since the system is on the kexec kernel boot path and the kexec lock is held, the crash_handle_hotplug_event() function fails to acquire the same lock to update the kdump image, resulting in the error messages mentioned above. To fix this, return from crash_handle_hotplug_event() without printing the error message if kexec is in progress. The same applies to the crash_check_hotplug_support() function. Return 0 if kexec is in progress because kernel is not in a position to update the kdump image. Link: https://lkml.kernel.org/r/20240921103745.560430-1-sourabhjain@linux.ibm.com Signed-off-by:
Sourabh Jain <sourabhjain@linux.ibm.com> Acked-by:
Baoquan he <bhe@redhat.com> Reported-by:
Sachin P Bappalige <sachinpb@linux.vnet.ibm.com> Cc: Hari Bathini <hbathini@linux.ibm.com> Cc: Michael Ellerman <mpe@ellerman.id.au> Signed-off-by:
Andrew Morton <akpm@linux-foundation.org> Signed-off-by:
Desnes Nunes <desnesn@redhat.com> Approved-by:
Baoquan He <5820488-baoquan_he@users.noreply.gitlab.com> Merged-by:
-
Julio Faracco authored
MR: https://gitlab.com/redhat/centos-stream/src/kernel/centos-stream-10/-/merge_requests/481 JIRA: https://issues.redhat.com/browse/RHEL-81540 CVE: CVE-2025-21712 ``` commit 8d28d0ddb986f56920ac97ae704cc3340a699a30 Author: Yu Kuai <yukuai3@huawei.com> Date: Fri Jan 24 17:20:55 2025 +0800 md/md-bitmap: Synchronize bitmap_get_stats() with bitmap lifetime After commit ec6bb299 ("md/md-bitmap: add 'sync_size' into struct md_bitmap_stats"), following panic is reported: Oops: general protection fault, probably for non-canonical address RIP: 0010:bitmap_get_stats+0x2b/0xa0 Call Trace: <TASK> md_seq_show+0x2d2/0x5b0 seq_read_iter+0x2b9/0x470 seq_read+0x12f/0x180 proc_reg_read+0x57/0xb0 vfs_read+0xf6/0x380 ksys_read+0x6c/0xf0 do_syscall_64+0x82/0x170 entry_SYSCALL_64_after_hwframe+0x76/0x7e Root cause is that bitmap_get_stats() can be called at anytime if mddev is still there, even if bitmap is destroyed, or not fully initialized. Deferenceing bitmap in this case can crash the kernel. Meanwhile, the above commit start to deferencing bitmap->storage, make the problem easier to trigger. Fix the problem by protecting bitmap_get_stats() with bitmap_info.mutex. Cc: stable@vger.kernel.org # v6.12+ Fixes: 32a7627c ("[PATCH] md: optimised resync using Bitmap based intent logging") Reported-and-tested-by:
Harshit Mogalapalli <harshit.m.mogalapalli@oracle.com> Closes: https://lore.kernel.org/linux-raid/ca3a91a2-50ae-4f68-b317-abd9889f3907@oracle.com/T/#m6e5086c95201135e4941fe38f9efa76daf9666c5 Signed-off-by:
Yu Kuai <yukuai3@huawei.com> Link: https://lore.kernel.org/r/20250124092055.4050195-1-yukuai1@huaweicloud.com Signed-off-by:
Song Liu <song@kernel.org>```> Signed-off-by:
Heinz Mauelshagen <heinzm@redhat.com> Approved-by:
Xiao Ni <xni@redhat.com> Merged-by:
-
Julio Faracco authored
MR: https://gitlab.com/redhat/centos-stream/src/kernel/centos-stream-10/-/merge_requests/513 JIRA: https://issues.redhat.com/browse/RHEL-73721 Upstream Status: All commits are found in Linus's git tree. Brew: https://brewweb.engineering.redhat.com/brew/taskinfo?taskID=66873040 Signed-off-by:
Nigel Croxon <ncroxon@redhat.com> Merged-by:
-
Jan Stancek authored
JIRA: INTERNAL Upstream Status: RHEL only Don't bring in changes from Makefile.rhelver. Signed-off-by:
-
- Mar 06, 2025
-
-
Jan Stancek authored
Signed-off-by: -
Jan Stancek authored
MR: https://gitlab.com/redhat/rhel/src/kernel/rhel-10/-/merge_requests/28 JIRA: https://issues.redhat.com/browse/RHEL-41204 Signed-off-by:
Benjamin Poirier <bpoirier@redhat.com> Approved-by:
Kamal Heib <kheib@redhat.com> Approved-by:
Michal Schmidt <mschmidt@redhat.com> Approved-by:
CKI KWF Bot <cki-ci-bot+kwf-gitlab-com@redhat.com> Merged-by:
-
Jan Stancek authored
MR: https://gitlab.com/redhat/rhel/src/kernel/rhel-10/-/merge_requests/20 JIRA: https://issues.redhat.com/browse/RHEL-71568 commit 56a708742a8bf127eb66798bfc9c9516c61f9930 Author: Yang Shi <yang@os.amperecomputing.com> Date: Mon, 25 Nov 2024 09:16:50 -0800 Commit ba0fb44a ("dma-mapping: replace zone_dma_bits by zone_dma_limit") and subsequent patches changed how zone_dma_limit is calculated to allow a reduced ZONE_DMA even when RAM starts above 4GB. Commit 122c234e ("arm64: mm: keep low RAM dma zone") further fixed this to ensure ZONE_DMA remains below U32_MAX if RAM starts below 4GB, especially on platforms that do not have IORT or DT description of the device DMA ranges. While zone boundaries calculation was fixed by the latter commit, zone_dma_limit, used to determine the GFP_DMA flag in the core code, was not updated. This results in excessive use of GFP_DMA and unnecessary ZONE_DMA allocations on some platforms. Update zone_dma_limit to match the actual upper bound of ZONE_DMA. Fixes: ba0fb44a ("dma-mapping: replace zone_dma_bits by zone_dma_limit") Cc: <stable@vger.kernel.org> # 6.12.x Reported-by:
Yutang Jiang <jiangyutang@os.amperecomputing.com> Tested-by:
Yang Shi <yang@os.amperecomputing.com> Link: https://lore.kernel.org/r/20241125171650.77424-1-yang@os.amperecomputing.com [catalin.marinas@arm.com: some tweaking of the commit log] Signed-off-by:
Catalin Marinas <catalin.marinas@arm.com> Signed-off-by:
Luiz Capitulino <luizcap@redhat.com> Approved-by:
Waiman Long <longman@redhat.com> Approved-by:
Herton R. Krzesinski <herton@redhat.com> Approved-by:
-
Jan Stancek authored
MR: https://gitlab.com/redhat/rhel/src/kernel/rhel-10/-/merge_requests/10 JIRA: https://issues.redhat.com/browse/RHEL-80149 Enable FIPS module for the UKI. Note: 'kernel-uki-virt-addons' already ship fips=1' cmdline extension and this can now be used. Note: to work properly, dracut >= 104 is needed. Signed-off-by:
Vitaly Kuznetsov <vkuznets@redhat.com> Approved-by:
Emanuele Giuseppe Esposito <eesposit@redhat.com> Approved-by:
-
- Mar 05, 2025
-
-
Julio Faracco authored
Signed-off-by: -
Julio Faracco authored
MR: https://gitlab.com/redhat/centos-stream/src/kernel/centos-stream-10/-/merge_requests/381 JIRA: https://issues.redhat.com/browse/RHEL-79464 ``` commit 52c11d31b5a1d1c747bb5f36cc4808e93e2348f4 Author: Joshua Hay <joshua.a.hay@intel.com> Date: Tue Feb 4 18:08:11 2025 -0800 idpf: call set_real_num_queues in idpf_open On initial driver load, alloc_etherdev_mqs is called with whatever max queue values are provided by the control plane. However, if the driver is loaded on a system where num_online_cpus() returns less than the max queues, the netdev will think there are more queues than are actually available. Only num_online_cpus() will be allocated, but skb_get_queue_mapping(skb) could possibly return an index beyond the range of allocated queues. Consequently, the packet is silently dropped and it appears as if TX is broken. Set the real number of queues during open so the netdev knows how many queues will be allocated. Fixes: 1c325aac ("idpf: configure resources for TX queues") Signed-off-by:
Joshua Hay <joshua.a.hay@intel.com> Reviewed-by:
Madhu Chittim <madhu.chittim@intel.com> Tested-by:
Samuel Salin <Samuel.salin@intel.com> Signed-off-by:
Tony Nguyen <anthony.l.nguyen@intel.com>```> Signed-off-by:
José Ignacio Tornos Martínez <jtornosm@redhat.com> Approved-by:
-
Julio Faracco authored
MR: https://gitlab.com/redhat/centos-stream/src/kernel/centos-stream-10/-/merge_requests/501 # Merge Request Required Information JIRA: https://issues.redhat.com/browse/RHEL-80060 ## Summary of Changes Re-order code in `event_hist_trigger_parse` so that `hist_trigger_enable` is called before `event_trigger_unregister`, enabling the latter to function correctly and remove a histogram with failed trigger parsing from the list. ## Approved Development Ticket(s) All submissions to CentOS Stream must reference a ticket in [Red Hat Jira](https://issues.redhat.com/). <details><summary>Click for formatting instructions</summary> Please follow the CentOS Stream [contribution documentation](https://docs.centos.org/en-US/stream-contrib/quickstart/ ) for how to file this ticket and have it approved. List tickets each on their own line of this description using the format "Resolves: RHEL-76229", "Related: RHEL-76229" or "Reverts: RHEL-76229", as appropriate. </details> Signed-off-by:
Tomas Glozar <tglozar@redhat.com> Approved-by:
Joe Lawrence <joe.lawrence@redhat.com> Approved-by:
-
Julio Faracco authored
MR: https://gitlab.com/redhat/centos-stream/src/kernel/centos-stream-10/-/merge_requests/404 JIRA: https://issues.redhat.com/browse/RHEL-79809 commits; ``` c12b2704a678b8a116eeb03f5b91895b90b4dd6f ``` Signed-off-by:
Mete Durlu <mdurlu@redhat.com> Approved-by:
Tony Camuso <tcamuso@redhat.com> Approved-by:
-
Julio Faracco authored
MR: https://gitlab.com/redhat/centos-stream/src/kernel/centos-stream-10/-/merge_requests/198 JIRA: https://issues.redhat.com/browse/RHEL-74125 CVE: CVE-2024-57901 ``` af_packet: fix vlan_get_protocol_dgram() vs MSG_PEEK Blamed commit forgot MSG_PEEK case, allowing a crash [1] as found by syzbot. Rework vlan_get_protocol_dgram() to not touch skb at all, so that it can be used from many cpus on the same skb. Add a const qualifier to skb argument. [1] skbuff: skb_under_panic: text:ffffffff8a8ccd05 len:29 put:14 head:ffff88807fc8e400 data:ffff88807fc8e3f4 tail:0x11 end:0x140 dev:<NULL> ------------[ cut here ]------------ kernel BUG at net/core/skbuff.c:206 ! Oops: invalid opcode: 0000 [#1] PREEMPT SMP KASAN PTI CPU: 1 UID: 0 PID: 5892 Comm: syz-executor883 Not tainted 6.13.0-rc4-syzkaller-00054-gd6ef8b40d075 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/13/2024 RIP: 0010:skb_panic net/core/skbuff.c:206 [inline] RIP: 0010:skb_under_panic+0x14b/0x150 net/core/skbuff.c:216 Code: 0b 8d 48 c7 c6 86 d5 25 8e 48 8b 54 24 08 8b 0c 24 44 8b 44 24 04 4d 89 e9 50 41 54 41 57 41 56 e8 5a 69 79 f7 48 83 c4 20 90 <0f> 0b 0f 1f 00 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 f3 RSP: 0018:ffffc900038d7638 EFLAGS: 00010282 RAX: 0000000000000087 RBX: dffffc0000000000 RCX: 609ffd18ea660600 RDX: 0000000000000000 RSI: 0000000080000000 RDI: 0000000000000000 RBP: ffff88802483c8d0 R08: ffffffff817f0a8c R09: 1ffff9200071ae60 R10: dffffc0000000000 R11: fffff5200071ae61 R12: 0000000000000140 R13: ffff88807fc8e400 R14: ffff88807fc8e3f4 R15: 0000000000000011 FS: 00007fbac5e006c0(0000) GS:ffff8880b8700000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007fbac5e00d58 CR3: 000000001238e000 CR4: 00000000003526f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: <TASK> skb_push+0xe5/0x100 net/core/skbuff.c:2636 vlan_get_protocol_dgram+0x165/0x290 net/packet/af_packet.c:585 packet_recvmsg+0x948/0x1ef0 net/packet/af_packet.c:3552 sock_recvmsg_nosec net/socket.c:1033 [inline] sock_recvmsg+0x22f/0x280 net/socket.c:1055 ____sys_recvmsg+0x1c6/0x480 net/socket.c:2803 ___sys_recvmsg net/socket.c:2845 [inline] do_recvmmsg+0x426/0xab0 net/socket.c:2940 __sys_recvmmsg net/socket.c:3014 [inline] __do_sys_recvmmsg net/socket.c:3037 [inline] __se_sys_recvmmsg net/socket.c:3030 [inline] __x64_sys_recvmmsg+0x199/0x250 net/socket.c:3030 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f Fixes: 79eecf63 ("af_packet: Handle outgoing VLAN packets without hardware offloading") Reported-by:
<syzbot+74f70bb1cb968bf09e4f@syzkaller.appspotmail.com> Closes: https://lore.kernel.org/netdev/6772c485.050a0220.2f3838.04c5.GAE@google.com/T/#u Signed-off-by:
-
Julio Faracco authored
MR: https://gitlab.com/redhat/centos-stream/src/kernel/centos-stream-10/-/merge_requests/225 JIRA: https://issues.redhat.com/browse/RHEL-75473 ``` cxgb4: use port number to set mac addr t4_set_vf_mac_acl() uses pf to set mac addr, but t4vf_get_vf_mac_acl() uses port number to get mac addr, this leads to error when an attempt to set MAC address on VF's of PF2 and PF3. This patch fixes the issue by using port number to set mac address. Fixes: e0cdac65 ("cxgb4vf: configure ports accessible by the VF") Signed-off-by:
Anumula Murali Mohan Reddy <anumula@chelsio.com> Signed-off-by:
Potnuri Bharat Teja <bharat@chelsio.com> Reviewed-by:
Simon Horman <horms@kernel.org> Link: https://patch.msgid.link/20241206062014.49414-1-anumula@chelsio.com Signed-off-by:
-
Jan Stancek authored
JIRA: INTERNAL Upstream Status: RHEL only Don't bring in changes from Makefile.rhelver and self-tests. Signed-off-by:
-
- Mar 04, 2025
-
-
Nigel Croxon authored
JIRA: https://issues.redhat.com/browse/RHEL-73721 commit fbe8f2fa971c537571994a0df532c511c4fb5537 Author: Bart Van Assche <bvanassche@acm.org> Date: Wed Feb 12 09:11:07 2025 -0800 md/raid*: Fix the set_queue_limits implementations queue_limits_cancel_update() must only be called if queue_limits_start_update() is called first. Remove the queue_limits_cancel_update() calls from the raid*_set_limits() functions because there is no corresponding queue_limits_start_update() call. Cc: Christoph Hellwig <hch@lst.de> Fixes: c6e56cf6 ("block: move integrity information into queue_limits") Signed-off-by:
Bart Van Assche <bvanassche@acm.org> Reviewed-by:
Christoph Hellwig <hch@lst.de> Link: https://lore.kernel.org/linux-raid/20250212171108.3483150-1-bvanassche@acm.org/ Signed-off-by:
Yu Kuai <yukuai@kernel.org> (cherry picked from commit fbe8f2fa971c537571994a0df532c511c4fb5537) Signed-off-by:
-
Nigel Croxon authored
JIRA: https://issues.redhat.com/browse/RHEL-73721 commit a572593ac80e51eb69ecede7e614289fcccdbf8d Author: Bart Van Assche <bvanassche@acm.org> Date: Wed Jan 29 14:56:35 2025 -0800 md: Fix linear_set_limits() queue_limits_cancel_update() must only be called if queue_limits_start_update() is called first. Remove the queue_limits_cancel_update() call from linear_set_limits() because there is no corresponding queue_limits_start_update() call. This bug was discovered by annotating all mutex operations with clang thread-safety attributes and by building the kernel with clang and -Wthread-safety. Cc: Yu Kuai <yukuai3@huawei.com> Cc: Coly Li <colyli@kernel.org> Cc: Mike Snitzer <snitzer@kernel.org> Cc: Christoph Hellwig <hch@lst.de> Fixes: 127186cfb184 ("md: reintroduce md-linear") Signed-off-by:
Song Liu <song@kernel.org> Signed-off-by:
-
Nigel Croxon authored
JIRA: https://issues.redhat.com/browse/RHEL-73721 commit 8d28d0ddb986f56920ac97ae704cc3340a699a30 Author: Yu Kuai <yukuai3@huawei.com> Date: Fri Jan 24 17:20:55 2025 +0800 md/md-bitmap: Synchronize bitmap_get_stats() with bitmap lifetime After commit ec6bb299 ("md/md-bitmap: add 'sync_size' into struct md_bitmap_stats"), following panic is reported: Oops: general protection fault, probably for non-canonical address RIP: 0010:bitmap_get_stats+0x2b/0xa0 Call Trace: <TASK> md_seq_show+0x2d2/0x5b0 seq_read_iter+0x2b9/0x470 seq_read+0x12f/0x180 proc_reg_read+0x57/0xb0 vfs_read+0xf6/0x380 ksys_read+0x6c/0xf0 do_syscall_64+0x82/0x170 entry_SYSCALL_64_after_hwframe+0x76/0x7e Root cause is that bitmap_get_stats() can be called at anytime if mddev is still there, even if bitmap is destroyed, or not fully initialized. Deferenceing bitmap in this case can crash the kernel. Meanwhile, the above commit start to deferencing bitmap->storage, make the problem easier to trigger. Fix the problem by protecting bitmap_get_stats() with bitmap_info.mutex. Cc: stable@vger.kernel.org # v6.12+ Fixes: 32a7627c ("[PATCH] md: optimised resync using Bitmap based intent logging") Reported-and-tested-by:
-
Nigel Croxon authored
JIRA: https://issues.redhat.com/browse/RHEL-73721 commit 62c552070a980363d55a6082b432ebd1cade7a6e Author: Dan Carpenter <dan.carpenter@linaro.org> Date: Wed Jan 15 09:53:52 2025 +0300 md/md-linear: Fix a NULL vs IS_ERR() bug in linear_add() The linear_conf() returns error pointers, it doesn't return NULL. Update the error checking to match. Fixes: 127186cfb184 ("md: reintroduce md-linear") Signed-off-by:
Dan Carpenter <dan.carpenter@linaro.org> Reviewed-by:
-
Nigel Croxon authored
JIRA: https://issues.redhat.com/browse/RHEL-73721 commit cd5fc653381811f1e0ba65f5d169918cab61476f Author: Yu Kuai <yukuai3@huawei.com> Date: Thu Jan 9 09:51:45 2025 +0800 md/md-bitmap: move bitmap_{start, end}write to md upper layer There are two BUG reports that raid5 will hang at bitmap_startwrite([1],[2]), root cause is that bitmap start write and end write is unbalanced, it's not quite clear where, and while reviewing raid5 code, it's found that bitmap operations can be optimized. For example, for a 4 disks raid5, with chunksize=8k, if user issue a IO (0 + 48k) to the array: ┌────────────────────────────────────────────────────────────┐ │chunk 0 │ │ ┌────────────┬─────────────┬─────────────┬────────────┼ │ sh0 │A0: 0 + 4k │A1: 8k + 4k │A2: 16k + 4k │A3: P │ │ ┼────────────┼─────────────┼─────────────┼────────────┼ │ sh1 │B0: 4k + 4k │B1: 12k + 4k │B2: 20k + 4k │B3: P │ ┼──────┴────────────┴─────────────┴─────────────┴────────────┼ │chunk 1 │ │ ┌────────────┬─────────────┬─────────────┬────────────┤ │ sh2 │C0: 24k + 4k│C1: 32k + 4k │C2: P │C3: 40k + 4k│ │ ┼────────────┼─────────────┼─────────────┼────────────┼ │ sh3 │D0: 28k + 4k│D1: 36k + 4k │D2: P │D3: 44k + 4k│ └──────┴────────────┴─────────────┴─────────────┴────────────┘ Before this patch, 4 stripe head will be used, and each sh will attach bio for 3 disks, and each attached bio will trigger bitmap_startwrite() once, which means total 12 times. - 3 times (0 + 4k), for (A0, A1 and A2) - 3 times (4 + 4k), for (B0, B1 and B2) - 3 times (8 + 4k), for (C0, C1 and C3) - 3 times (12 + 4k), for (D0, D1 and D3) After this patch, md upper layer will calculate that IO range (0 + 48k) is corresponding to the bitmap (0 + 16k), and call bitmap_startwrite() just once. Noted that this patch will align bitmap ranges to the chunks, for example, if user issue a IO (0 + 4k) to array: - Before this patch, 1 time (0 + 4k), for A0; - After this patch, 1 time (0 + 8k) for chunk 0; Usually, one bitmap bit will represent more than one disk chunk, and this doesn't have any difference. And even if user really created a array that one chunk contain multiple bits, the overhead is that more data will be recovered after power failure. Also remove STRIPE_BITMAP_PENDING since it's not used anymore. [1] https://lore.kernel.org/all/CAJpMwyjmHQLvm6zg1cmQErttNNQPDAAXPKM3xgTjMhbfts986Q@mail.gmail.com/ [2] https://lore.kernel.org/all/ADF7D720-5764-4AF3-B68E-1845988737AA@flyingcircus.io/ Signed-off-by:
-
Nigel Croxon authored
JIRA: https://issues.redhat.com/browse/RHEL-73721 commit 9c89f604476cf15c31fbbdb043cff7fbf1dbe0cb Author: Yu Kuai <yukuai3@huawei.com> Date: Thu Jan 9 09:51:44 2025 +0800 md/raid5: implement pers->bitmap_sector() Bitmap is used for the whole array for raid1/raid10, hence IO for the array can be used directly for bitmap. However, bitmap is used for underlying disks for raid5, hence IO for the array can't be used directly for bitmap. Implement pers->bitmap_sector() for raid5 to convert IO ranges from the array to the underlying disks. Signed-off-by:
-
Nigel Croxon authored
JIRA: https://issues.redhat.com/browse/RHEL-73721 commit 0c984a283a3ea3f10bebecd6c57c1d41b2e4f518 Author: Yu Kuai <yukuai3@huawei.com> Date: Thu Jan 9 09:51:43 2025 +0800 md: add a new callback pers->bitmap_sector() This callback will be used in raid5 to convert io ranges from array to bitmap. Signed-off-by:
-
Nigel Croxon authored
JIRA: https://issues.redhat.com/browse/RHEL-73721 commit 4f0e7d0e03b7b80af84759a9e7cfb0f81ac4adae Author: Yu Kuai <yukuai3@huawei.com> Date: Thu Jan 9 09:51:42 2025 +0800 md/md-bitmap: remove the last parameter for bimtap_ops->endwrite() For the case that IO failed for one rdev, the bit will be mark as NEEDED in following cases: 1) If badblocks is set and rdev is not faulty; 2) If rdev is faulty; Case 1) is useless because synchronize data to badblocks make no sense. Case 2) can be replaced with mddev->degraded. Also remove R1BIO_Degraded, R10BIO_Degraded and STRIPE_DEGRADED since case 2) no longer use them. Signed-off-by:
-
Nigel Croxon authored
JIRA: https://issues.redhat.com/browse/RHEL-73721 commit 08c50142a128dcb2d7060aa3b4c5db8837f7a46a Author: Yu Kuai <yukuai3@huawei.com> Date: Thu Jan 9 09:51:41 2025 +0800 md/md-bitmap: factor behind write counters out from bitmap_{start/end}write() behind_write is only used in raid1, prepare to refactor bitmap_{start/end}write(), there are no functional changes. Signed-off-by:
-
Nigel Croxon authored
JIRA: https://issues.redhat.com/browse/RHEL-73721 commit 4fa91616c078c203f1ab6c43f9524b7e352c8217 Author: David Reaver <me@davidreaver.com> Date: Wed Jan 8 11:21:30 2025 -0800 md: Replace deprecated kmap_atomic() with kmap_local_page() kmap_atomic() is deprecated and should be replaced with kmap_local_page() [1][2]. kmap_local_page() is faster in kernels with HIGHMEM enabled, can take page faults, and allows preemption. According to [2], this is safe as long as the code between kmap_atomic() and kunmap_atomic() does not implicitly depend on disabling page faults or preemption. It appears to me that none of the call sites in this patch depend on disabling page faults or preemption; they are all mapping a page to simply extract some information from it or print some debug info. [1] https://lwn.net/Articles/836144/ [2] https://docs.kernel.org/mm/highmem.html#temporary-virtual-mappings Signed-off-by:
David Reaver <me@davidreaver.com> Link: https://lore.kernel.org/r/20250108192131.46843-1-me@davidreaver.com Signed-off-by:
-
Nigel Croxon authored
JIRA: https://issues.redhat.com/browse/RHEL-73721 commit a1d9b4fd42d93f46c11e7e9d919a55a3f6ca6126 Author: John Garry <john.g.garry@oracle.com> Date: Mon Nov 18 10:50:18 2024 +0000 md/raid10: Atomic write support Set BLK_FEAT_ATOMIC_WRITES_STACKED to enable atomic writes. For an attempt to atomic write to a region which has bad blocks, error the write as we just cannot do this. It is unlikely to find devices which support atomic writes and bad blocks. Reviewed-by:
John Garry <john.g.garry@oracle.com> Reviewed-by:
Martin K. Petersen <martin.petersen@oracle.com> Link: https://lore.kernel.org/r/20241118105018.1870052-6-john.g.garry@oracle.com Signed-off-by:
Jens Axboe <axboe@kernel.dk> Signed-off-by:
-
Nigel Croxon authored
JIRA: https://issues.redhat.com/browse/RHEL-73721 commit f2a38abf5f1c5aeb3be8e9f4d3d815c867fff7ca Author: John Garry <john.g.garry@oracle.com> Date: Mon Nov 18 10:50:17 2024 +0000 md/raid1: Atomic write support Set BLK_FEAT_ATOMIC_WRITES_STACKED to enable atomic writes. For an attempt to atomic write to a region which has bad blocks, error the write as we just cannot do this. It is unlikely to find devices which support atomic writes and bad blocks. Reviewed-by:
-
Nigel Croxon authored
JIRA: https://issues.redhat.com/browse/RHEL-73721 commit fa6fec82811bc6ebd3c4337ae4dae36c802c0fc1 Author: John Garry <john.g.garry@oracle.com> Date: Mon Nov 18 10:50:16 2024 +0000 md/raid0: Atomic write support Set BLK_FEAT_ATOMIC_WRITES_STACKED to enable atomic writes. All other stacked device request queue limits should automatically be set properly. With regards to atomic write max bytes limit, this will be set at hw_max_sectors and this is limited by the stripe width, which we want. Reviewed-by:
-
Nigel Croxon authored
JIRA: https://issues.redhat.com/browse/RHEL-73721 commit d7f36dc446e894e0f57b5f05c5628f03c5f9e2d2 Author: John Garry <john.g.garry@oracle.com> Date: Mon Nov 18 10:50:15 2024 +0000 block: Support atomic writes limits for stacked devices Allow stacked devices to support atomic writes by aggregating the minimum capability of all bottom devices. Flag BLK_FEAT_ATOMIC_WRITES_STACKED is set for stacked devices which have been enabled to support atomic writes. Some things to note on the implementation: - For simplicity, all bottom devices must have same atomic write boundary value (if any) - The atomic write boundary must be a power-of-2 already, but this restriction could be relaxed. Furthermore, it is now required that the chunk sectors for a top device must be aligned with this boundary. - If a bottom device atomic write unit min/max are not aligned with the top device chunk sectors, the top device atomic write unit min/max are reduced to a value which works for the chunk sectors. Reviewed-by:
-
Nigel Croxon authored
JIRA: https://issues.redhat.com/browse/RHEL-73721 commit ea90d270349d51086d0dddc55821a782040d68f5 Author: John Garry <john.g.garry@oracle.com> Date: Tue Nov 12 16:10:18 2024 +0000 md/raid5: Increase r5conf.cache_name size For compiling with W=1, the following warning can be seen: drivers/md/raid5.c: In function ‘setup_conf’: drivers/md/raid5.c:2423:12: error: ‘%s’ directive output may be truncated writing up to 31 bytes into a region of size between 16 and 26 [-Werror=format-truncation=] "raid%d-%s", conf->level, mdname(conf->mddev)); ^~ drivers/md/raid5.c:2422:3: note: ‘snprintf’ output between 7 and 48 bytes into a destination of size 32 snprintf(conf->cache_name[0], namelen, ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ "raid%d-%s", conf->level, mdname(conf->mddev)); ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ cc1: all warnings being treated as errors Increase the array size to avoid this warning. Signed-off-by:
-
Nigel Croxon authored
JIRA: https://issues.redhat.com/browse/RHEL-73721 commit 4cf58d9529097328b669e3c8693ed21e3a041903 Author: John Garry <john.g.garry@oracle.com> Date: Mon Nov 11 11:21:50 2024 +0000 md/raid10: Handle bio_split() errors Add proper bio_split() error handling. For any error, call raid_end_bio_io() and return. Except for discard, where we end the bio directly. Reviewed-by:
Hannes Reinecke <hare@suse.de> Signed-off-by:
-
Nigel Croxon authored
JIRA: https://issues.redhat.com/browse/RHEL-73721 commit b1a7ad8b5c4fa28325ee7b369a2d545d3e16ccde Author: John Garry <john.g.garry@oracle.com> Date: Mon Nov 11 11:21:49 2024 +0000 md/raid1: Handle bio_split() errors Add proper bio_split() error handling. For any error, call raid_end_bio_io() and return. For the case of an in the write path, we need to undo the increment in the rdev pending count and NULLify the r1_bio->bios[] pointers. For read path failure, we need to undo rdev pending count increment from the earlier read_balance() call. Reviewed-by:
-
Nigel Croxon authored
JIRA: https://issues.redhat.com/browse/RHEL-73721 commit 74538fdac3e85aae55eb4ed786478ed2384cb85d Author: John Garry <john.g.garry@oracle.com> Date: Mon Nov 11 11:21:48 2024 +0000 md/raid0: Handle bio_split() errors Add proper bio_split() error handling. For any error, set bi_status, end the bio, and return. Reviewed-by:
-
