fix(dts): remove duplicate label on qnovo_fet_ctrl_default#3
Open
PeronGH wants to merge 356 commits into
Open
Conversation
Skip save and restore of GIC SPI configuration, if the GICV3 drivers hasn't been initialized. Change-Id: I1bc32f58eef349487b2096ea2c26d491ee45a433 Signed-off-by: Neeraj Upadhyay <neeraju@codeaurora.org>
Some of the GICD registers could be read in and stored as zeros if an intterupt is triggered around the same time as the system sleep. The pending state of the interrupt would be latched but the configuration registers for the interrupt is reset. To ensure that the interrupt triggers, restore the interrupts configuration around System sleep notification. Change-Id: Ib04720241e8fa4382383bd08897c4e19aaaded8c Signed-off-by: Mahesh Sivasubramanian <msivasub@codeaurora.org> Signed-off-by: Pavel Dubrova <pashadubrova@gmail.com>
This register is present only on new SoCs and shouldn't be present on older ones like MSM8998 or SDM630. For this reason, warn the user, but do not fail if this register is not found, as it's used only there and it's not necessary for core driver functionality.
The spss-util driver provides utilities required for the Secure Processor Subsystem (SPSS). It provides the fuse state for key selection and the SPSS HW version. Legacy spss not support load spss by UEFI and also not support CMAC/IAR feature. Change-Id: Iea0d66ed66a2817850f99f74bf716d33db956812 Signed-off-by: Santosh Dronamraju <sdronamr@codeaurora.org>
Legacy spss not support load spss by UEFI and also not support CMAC/IAR feature.
Add debug support for sdm845 target for sde driver. Signed-off-by: Pavel Dubrova <pashadubrova@gmail.com>
SID register may not be declared on the legacy SoCs (SDM660, SDM845, etc.), which will lead to the SDE driver fail, prevent this by adding the appropriate checks. Signed-off-by: Pavel Dubrova <pashadubrova@gmail.com>
SDM845's MDP manages the tear interrupts inside the MDP interrupt itself, so there's no external tear interrupt.
In 4.14 kernel the definition of the active interface for cont splash was changed[1], which is invalid for older SoCs (SDM845/660), for them a different bit[2] must be used to check the active interface. Hence add a proper check for these legacy SoCs to the get_ctl_intf function and protect it by checking the SDE HW revision. [1] https://source.codeaurora.org/quic/la/kernel/msm-4.14/commit/?h=LA.UM.9.1.r1-11400-SMxxx0.0&id=75cc47bfa5f8ffb8ee43d6597ac2e8c74093cd91 [2] https://source.codeaurora.org/quic/la/kernel/msm-4.9/tree/drivers/gpu/drm/msm/sde/sde_rm.c?h=LA.UM.10.3.r1-00500-sdm845.0#n1433 Signed-off-by: Pavel Dubrova <pashadubrova@gmail.com>
Legacy ways use no FSA4480 MUX chip: there you just pull GPIOs and call it a day. Handle this usecase. [Pavel Dubrova] Update snd_soc_codec to snd_soc_component API. Signed-off-by: Pavel Dubrova <pashadubrova@gmail.com>
Some SoCs were released with a DSP firmware using CVP v2.0 and CVD v2.3, but the same versions got a modification on later firmwares found on, for example, SM8150. Unfortunately, the new firmware doesn't declare a different version for CVP nor CVD, but the old one does not support the device_channels command, with the channel_info command being the only option to set the CVP channels right: this is found to happen on SDM845's DSP firmware. For this reason, check if the current machine is SDM845 and force sending the CVP channel info command on there: this way, the DSP doesn't return any error and we're able to use advanced features, like AEC and (A)ANC.
Add ALSA based machine driver for SDM845 target to provide initial audio support. Add audio config files and change Android.mk, Makefile and Kbuild to enable audio modules for SDM845 target. Signed-off-by: Pavel Dubrova <pashadubrova@gmail.com>
From msm-4.14 as of commit "msm: vidc: Release cvp buffer lock in invalid buffer case".
Signed-off-by: Sultan Alsawaf <sultan@kerneltoast.com> Change-Id: I3839d059c7666250519423c5417bcc4b3785d0e2
Currently we are returning 0 in SMMU fault handler. However, if we return -EINVAL, then smmu driver assumes page fault handler is not installed and prints a list of useful debug information. CRs-Fixed: 2344373 Change-Id: I3ca6731eb9a30b7d4ef03f4d580e622d9a8c6c0f Signed-off-by: Vaibhav Deshu Venkatesh <vdeshuve@codeaurora.org>
Non secure loading of firmware is not supported, hence removing the support. CRs-Fixed: 2358497 Change-Id: I1da79824deefd48f42570051be352de7649f1855 Signed-off-by: Chinmay Sawarkar <chinmays@codeaurora.org>
IOMMU initialization APIs have been deprecated and replaced by device tree properties. IOMMU driver will map/unmap and attach/detach device at bootup, based on the dtsi entries. CRs-Fixed: 2358497 Change-Id: I2be820ed406c46209e927e5f7f861e75d67e966a Signed-off-by: Chinmay Sawarkar <chinmays@codeaurora.org>
Stolen from techpack/video
Bus bandwidth voting can be achieved by directly call the bus apis. DevFreq functionality is not utilized nor necessary. Also, video bus bandwidth votes are dynamic and cannot conform to the OPP table entries. CRs-Fixed: 2384822 Change-Id: Ib83f51d7d07efe24a256e0287433e7a28e2ae057 Signed-off-by: Chinmay Sawarkar <chinmays@codeaurora.org> Signed-off-by: Vikash Garodia <vgarodia@codeaurora.org>
Avoid null pointer dereference to fix video SSR usecase failures. Change-Id: I8bf00673ed9fb2e013bd2c5e8be8860d9d741ec4 CRs-Fixed: 2438294 Signed-off-by: Amit Shekhar <ashekhar@codeaurora.org>
These register writes were missing on the VPU4 clock-on config, but they are needed for some SoCs to correctly initialize the Venus.
Legacy SoCs have got old VE firmwares and some of the features in this vidc driver release are unsupported by these. We need it working as soon as possible, so adopt this dirty way of dealing with it.
Add fw cycles and fw-vpp-cycles for correct calculation of HFR and VPP usecases. Also, fix the power collapse delay and hw response timeout for older firmwares.
kref_put causes crash if refcount is zero. This change prevents crash by checking if refcount value. CRs-Fixed: 2553290 Change-Id: Ie9a950b289cdb2b8fca8c5d025be540d926eadbd Signed-off-by: Trishansh Bhardwaj <tbhardwa@codeaurora.org>
- Change to dereference s_ctrl only after proper NULL Dereference Check. CRs-Fixed: 3875406 Change-Id: I8e2c717b22efff2a7d6503d38c048e30eff230da Signed-off-by: Swami Reddy Reddy <quic_swamired@quicinc.com>
Due to scheduling delays there is a possibility that the abort/destroy ACK from FW cannot be processed within the current timeout. Hence increasing the timeout to account for these delays. Change-Id: Ia8f670e67dfb3db47e71b1d1e9eeba79bde7f277 Signed-off-by: Karthik Anantha Ram <kartanan@codeaurora.org>
Bumping up the maximum number of ICP contexts from 36 to 54. Change-Id: I8da5a2fadae8a9a0a0814c73b82450f884217d1e Signed-off-by: Karthik Anantha Ram <kartanan@codeaurora.org>
Using last clk index doesn't gaurantee the src clock rates are populated properly, instead use src clock index which is already saved pointing to the correct src clock array. Change-Id: I90369bd2d0aefed74ba738a0deb5768d43e6e576 Signed-off-by: Jigarkumar Zala <jzala@codeaurora.org>
drivers/media/platform/msm/camera_oneplus/cam_sensor_module/cam_sensor_io/cam_sensor_cci_i2c.c:23:20: error: variable length arrays are a C99 feature [-Werror,-Wvla-extension]
Change-Id: I2c199704cef3e32d0c103876b3681d30ea22f316
Test: Open Settings -> Battery -> Battery information Change-Id: I755c1baf2045ecd14ca3f82544fe61a9a63f0b41
Test: Open Settings -> Battery -> Battery information after idling for
longer period of time.
Change-Id: I6326ea9589734aca370df1118492266c4e14e4bd
The node name was repeated as a label, causing a build error with strict DT compilers.
EdwinMoq
force-pushed
the
lineage-23.2-4.19
branch
from
May 3, 2026 13:27
7e8cb3e to
7881cc0
Compare
EdwinMoq
pushed a commit
that referenced
this pull request
May 3, 2026
[ Upstream commit df9ac55abd18628bd8cff687ea043660532a3654 ] If the export_binary parameter is disabled on runtime, profiles that were loaded before that will still have their rawdata stored in apparmorfs, with a symbolic link to the rawdata on the policy directory. When one of those profiles are replaced, the rawdata is set to NULL, but when trying to resolve the symbolic links to rawdata for that profile, it will try to dereference profile->rawdata->name when profile->rawdata is now NULL causing an oops. Fix it by checking if rawdata is set. [ 168.653080] BUG: kernel NULL pointer dereference, address: 0000000000000088 [ 168.657420] #PF: supervisor read access in kernel mode [ 168.660619] #PF: error_code(0x0000) - not-present page [ 168.663613] PGD 0 P4D 0 [ 168.665450] Oops: Oops: 0000 [#1] SMP NOPTI [ 168.667836] CPU: 1 UID: 0 PID: 1729 Comm: ls Not tainted 6.19.0-rc7+ #3 PREEMPT(voluntary) [ 168.672308] Hardware name: QEMU Ubuntu 24.04 PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 [ 168.679327] RIP: 0010:rawdata_get_link_base.isra.0+0x23/0x330 [ 168.682768] Code: 90 90 90 90 90 90 90 0f 1f 44 00 00 55 48 89 e5 41 57 41 56 41 55 41 54 53 48 83 ec 18 48 89 55 d0 48 85 ff 0f 84 e3 01 00 00 <48> 83 3c 25 88 00 00 00 00 0f 84 d4 01 00 00 49 89 f6 49 89 cc e8 [ 168.689818] RSP: 0018:ffffcdcb8200fb80 EFLAGS: 00010282 [ 168.690871] RAX: ffffffffaee74ec0 RBX: 0000000000000000 RCX: ffffffffb0120158 [ 168.692251] RDX: ffffcdcb8200fbe0 RSI: ffff88c187c9fa80 RDI: ffff88c186c98a80 [ 168.693593] RBP: ffffcdcb8200fbc0 R08: 0000000000000000 R09: 0000000000000000 [ 168.694941] R10: 0000000000000000 R11: 0000000000000000 R12: ffff88c186c98a80 [ 168.696289] R13: 00007fff005aaa20 R14: 0000000000000080 R15: ffff88c188f4fce0 [ 168.697637] FS: 0000790e81c58280(0000) GS:ffff88c20a957000(0000) knlGS:0000000000000000 [ 168.699227] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 168.700349] CR2: 0000000000000088 CR3: 000000012fd3e000 CR4: 0000000000350ef0 [ 168.701696] Call Trace: [ 168.702325] <TASK> [ 168.702995] rawdata_get_link_data+0x1c/0x30 [ 168.704145] vfs_readlink+0xd4/0x160 [ 168.705152] do_readlinkat+0x114/0x180 [ 168.706214] __x64_sys_readlink+0x1e/0x30 [ 168.708653] x64_sys_call+0x1d77/0x26b0 [ 168.709525] do_syscall_64+0x81/0x500 [ 168.710348] ? do_statx+0x72/0xb0 [ 168.711109] ? putname+0x3e/0x80 [ 168.711845] ? __x64_sys_statx+0xb7/0x100 [ 168.712711] ? x64_sys_call+0x10fc/0x26b0 [ 168.713577] ? do_syscall_64+0xbf/0x500 [ 168.714412] ? do_user_addr_fault+0x1d2/0x8d0 [ 168.715404] ? irqentry_exit+0xb2/0x740 [ 168.716359] ? exc_page_fault+0x90/0x1b0 [ 168.717307] entry_SYSCALL_64_after_hwframe+0x76/0x7e Fixes: 1180b4c ("apparmor: fix dangling symlinks to policy rawdata after replacement") Signed-off-by: Georgia Garcia <georgia.garcia@canonical.com> Signed-off-by: John Johansen <john.johansen@canonical.com> Signed-off-by: Sasha Levin <sashal@kernel.org> Signed-off-by: Ulrich Hecht <uli@kernel.org>
EdwinMoq
force-pushed
the
lineage-23.2-4.19
branch
from
May 4, 2026 21:17
8c6c54f to
686e118
Compare
EdwinMoq
force-pushed
the
lineage-23.2-4.19
branch
from
May 13, 2026 15:32
686e118 to
c874c80
Compare
EdwinMoq
pushed a commit
that referenced
this pull request
May 13, 2026
[ Upstream commit 5cb81eeda909dbb2def209dd10636b51549a3f8a ] ctnetlink_dump_exp_ct() stores a conntrack pointer in cb->data for the netlink dump callback ctnetlink_exp_ct_dump_table(), but drops the conntrack reference immediately after netlink_dump_start(). When the dump spans multiple rounds, the second recvmsg() triggers the dump callback which dereferences the now-freed conntrack via nfct_help(ct), leading to a use-after-free on ct->ext. The bug is that the netlink_dump_control has no .start or .done callbacks to manage the conntrack reference across dump rounds. Other dump functions in the same file (e.g. ctnetlink_get_conntrack) properly use .start/.done callbacks for this purpose. Fix this by adding .start and .done callbacks that hold and release the conntrack reference for the duration of the dump, and move the nfct_help() call after the cb->args[0] early-return check in the dump callback to avoid dereferencing ct->ext unnecessarily. BUG: KASAN: slab-use-after-free in ctnetlink_exp_ct_dump_table+0x4f/0x2e0 Read of size 8 at addr ffff88810597ebf0 by task ctnetlink_poc/133 CPU: 1 UID: 0 PID: 133 Comm: ctnetlink_poc Not tainted 7.0.0-rc2+ #3 PREEMPTLAZY Call Trace: <TASK> ctnetlink_exp_ct_dump_table+0x4f/0x2e0 netlink_dump+0x333/0x880 netlink_recvmsg+0x3e2/0x4b0 ? aa_sk_perm+0x184/0x450 sock_recvmsg+0xde/0xf0 Allocated by task 133: kmem_cache_alloc_noprof+0x134/0x440 __nf_conntrack_alloc+0xa8/0x2b0 ctnetlink_create_conntrack+0xa1/0x900 ctnetlink_new_conntrack+0x3cf/0x7d0 nfnetlink_rcv_msg+0x48e/0x510 netlink_rcv_skb+0xc9/0x1f0 nfnetlink_rcv+0xdb/0x220 netlink_unicast+0x3ec/0x590 netlink_sendmsg+0x397/0x690 __sys_sendmsg+0xf4/0x180 Freed by task 0: slab_free_after_rcu_debug+0xad/0x1e0 rcu_core+0x5c3/0x9c0 Fixes: e844a92 ("netfilter: ctnetlink: allow to dump expectation per master conntrack") Signed-off-by: Hyunwoo Kim <imv4bel@gmail.com> Signed-off-by: Florian Westphal <fw@strlen.de> Signed-off-by: Sasha Levin <sashal@kernel.org> [uli: backport to 4.19] Signed-off-by: Ulrich Hecht <uli@kernel.org>
EdwinMoq
force-pushed
the
lineage-23.2-4.19
branch
from
May 23, 2026 14:01
c874c80 to
b4c4d67
Compare
EdwinMoq
force-pushed
the
lineage-23.2-4.19
branch
2 times, most recently
from
June 7, 2026 00:11
1adba2a to
cc4771c
Compare
EdwinMoq
force-pushed
the
lineage-23.2-4.19
branch
2 times, most recently
from
June 14, 2026 22:33
a1bfd03 to
628a754
Compare
EdwinMoq
force-pushed
the
lineage-23.2-4.19
branch
2 times, most recently
from
July 8, 2026 15:45
9dd75b2 to
23dd3b2
Compare
EdwinMoq
force-pushed
the
lineage-23.2-4.19
branch
from
July 12, 2026 20:44
23dd3b2 to
91178f0
Compare
EdwinMoq
pushed a commit
that referenced
this pull request
Jul 12, 2026
commit 0b16e69d17d8c35c5c9d5918bf596c75a44655d3 upstream. When exiting to userspace to service an emulated MMIO write, copy the to-be-written value to a scratch field in the MMIO fragment if the size of the data payload is 8 bytes or less, i.e. can fit in a single chunk, instead of pointing the fragment directly at the source value. This fixes a class of use-after-free bugs that occur when the emulator initiates a write using an on-stack, local variable as the source, the write splits a page boundary, *and* both pages are MMIO pages. Because KVM's ABI only allows for physically contiguous MMIO requests, accesses that split MMIO pages are separated into two fragments, and are sent to userspace one at a time. When KVM attempts to complete userspace MMIO in response to KVM_RUN after the first fragment, KVM will detect the second fragment and generate a second userspace exit, and reference the on-stack variable. The issue is most visible if the second KVM_RUN is performed by a separate task, in which case the stack of the initiating task can show up as truly freed data. ================================================================== BUG: KASAN: use-after-free in complete_emulated_mmio+0x305/0x420 Read of size 1 at addr ffff888009c378d1 by task syz-executor417/984 CPU: 1 PID: 984 Comm: syz-executor417 Not tainted 5.10.0-182.0.0.95.h2627.eulerosv2r13.x86_64 #3 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.15.0-0-g2dd4b9b3f840-prebuilt.qemu.org 04/01/2014 Call Trace: dump_stack+0xbe/0xfd print_address_description.constprop.0+0x19/0x170 __kasan_report.cold+0x6c/0x84 kasan_report+0x3a/0x50 check_memory_region+0xfd/0x1f0 memcpy+0x20/0x60 complete_emulated_mmio+0x305/0x420 kvm_arch_vcpu_ioctl_run+0x63f/0x6d0 kvm_vcpu_ioctl+0x413/0xb20 __se_sys_ioctl+0x111/0x160 do_syscall_64+0x30/0x40 entry_SYSCALL_64_after_hwframe+0x67/0xd1 RIP: 0033:0x42477d Code: <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 b0 ff ff ff f7 d8 64 89 01 48 RSP: 002b:00007faa8e6890e8 EFLAGS: 00000246 ORIG_RAX: 0000000000000010 RAX: ffffffffffffffda RBX: 00000000004d7338 RCX: 000000000042477d RDX: 0000000000000000 RSI: 000000000000ae80 RDI: 0000000000000005 RBP: 00000000004d7330 R08: 00007fff28d546df R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000246 R12: 00000000004d733c R13: 0000000000000000 R14: 000000000040a200 R15: 00007fff28d54720 The buggy address belongs to the page: page:0000000029f6a428 refcount:0 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x9c37 flags: 0xfffffc0000000(node=0|zone=1|lastcpupid=0x1fffff) raw: 000fffffc0000000 0000000000000000 ffffea0000270dc8 0000000000000000 raw: 0000000000000000 0000000000000000 00000000ffffffff 0000000000000000 page dumped because: kasan: bad access detected Memory state around the buggy address: ffff888009c37780: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ffff888009c37800: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff >ffff888009c37880: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ^ ffff888009c37900: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ffff888009c37980: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ================================================================== The bug can also be reproduced with a targeted KVM-Unit-Test by hacking KVM to fill a large on-stack variable in complete_emulated_mmio(), i.e. by overwrite the data value with garbage. Limit the use of the scratch fields to 8-byte or smaller accesses, and to just writes, as larger accesses and reads are not affected thanks to implementation details in the emulator, but add a sanity check to ensure those details don't change in the future. Specifically, KVM never uses on-stack variables for accesses larger that 8 bytes, e.g. uses an operand in the emulator context, and *all* reads are buffered through the mem_read cache. Note! Using the scratch field for reads is not only unnecessary, it's also extremely difficult to handle correctly. As above, KVM buffers all reads through the mem_read cache, and heavily relies on that behavior when re-emulating the instruction after a userspace MMIO read exit. If a read splits a page, the first page is NOT an MMIO page, and the second page IS an MMIO page, then the MMIO fragment needs to point at _just_ the second chunk of the destination, i.e. its position in the mem_read cache. Taking the "obvious" approach of copying the fragment value into the destination when re-emulating the instruction would clobber the first chunk of the destination, i.e. would clobber the data that was read from guest memory. Fixes: f78146b ("KVM: Fix page-crossing MMIO") Suggested-by: Yashu Zhang <zhangjiaji1@huawei.com> Reported-by: Yashu Zhang <zhangjiaji1@huawei.com> Closes: https://lore.kernel.org/all/369eaaa2b3c1425c85e8477066391bc7@huawei.com Cc: stable@vger.kernel.org Tested-by: Tom Lendacky <thomas.lendacky@gmail.com> Tested-by: Rick Edgecombe <rick.p.edgecombe@intel.com> Link: https://patch.msgid.link/20260225012049.920665-2-seanjc@google.com Signed-off-by: Sean Christopherson <seanjc@google.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Ulrich Hecht <uli@kernel.org>
EdwinMoq
pushed a commit
that referenced
this pull request
Jul 12, 2026
…equeue_peeked commit 458d5615272d3de535748342eb68ca492343048c upstream. When red qdisc has children (eg qfq qdisc) whose peek() callback is qdisc_peek_dequeued(), we could get a kernel panic. When the parent of such qdiscs (eg illustrated in patch #3 as tbf) wants to retrieve an skb from its child (red in this case), it will do the following: 1a. do a peek() - and when sensing there's an skb the child can offer, then - the child in this case(red) calls its child's (qfq) peek. qfq does the right thing and will return the gso_skb queue packet. Note: if there wasnt a gso_skb entry then qfq will store it there. 1b. invoke a dequeue() on the child (red). And herein lies the problem. - red will call the child's dequeue() which will essentially just try to grab something of qfq's queue. [ 78.667668][ T363] KASAN: null-ptr-deref in range [0x0000000000000048-0x000000000000004f] [ 78.667927][ T363] CPU: 1 UID: 0 PID: 363 Comm: ping Not tainted 7.1.0-rc1-00033-g46f74a3f7d57-dirty #790 PREEMPT(full) [ 78.668263][ T363] Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011 [ 78.668486][ T363] RIP: 0010:qfq_dequeue+0x446/0xc90 [sch_qfq] [ 78.668718][ T363] Code: 54 c0 e8 dd 90 00 f1 48 c7 c7 e0 03 54 c0 48 89 de e8 ce 90 00 f1 48 8d 7b 48 b8 ff ff 37 00 48 89 fa 48 c1 e0 2a 48 c1 ea 03 <80> 3c 02 00 74 05 e8 ef a1 e1 f1 48 8b 7b 48 48 8d 54 24 58 48 8d [ 78.669312][ T363] RSP: 0018:ffff88810de573e0 EFLAGS: 00010216 [ 78.669533][ T363] RAX: dffffc0000000000 RBX: 0000000000000000 RCX: 0000000000000000 [ 78.669790][ T363] RDX: 0000000000000009 RSI: 0000000000000004 RDI: 0000000000000048 [ 78.670044][ T363] RBP: ffff888110dc4000 R08: ffffffffb1b0885a R09: fffffbfff6ba9078 [ 78.670297][ T363] R10: 0000000000000003 R11: ffff888110e31c80 R12: 0000001880000000 [ 78.670560][ T363] R13: ffff888110dc4150 R14: ffff888110dc42b8 R15: 0000000000000200 [ 78.670814][ T363] FS: 00007f66a8f09c40(0000) GS:ffff888163428000(0000) knlGS:0000000000000000 [ 78.671110][ T363] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 78.671324][ T363] CR2: 000055db4c6a30a8 CR3: 000000010da67000 CR4: 0000000000750ef0 [ 78.671585][ T363] PKRU: 55555554 [ 78.671713][ T363] Call Trace: [ 78.671843][ T363] <TASK> [ 78.671936][ T363] ? __pfx_qfq_dequeue+0x10/0x10 [sch_qfq] [ 78.672148][ T363] ? __pfx__printk+0x10/0x10 [ 78.672322][ T363] ? srso_alias_return_thunk+0x5/0xfbef5 [ 78.672496][ T363] ? lockdep_hardirqs_on_prepare+0xa8/0x1a0 [ 78.672706][ T363] ? srso_alias_return_thunk+0x5/0xfbef5 [ 78.672875][ T363] ? trace_hardirqs_on+0x19/0x1a0 [ 78.673047][ T363] red_dequeue+0x65/0x270 [sch_red] [ 78.673217][ T363] ? srso_alias_return_thunk+0x5/0xfbef5 [ 78.673385][ T363] tbf_dequeue.cold+0xb0/0x70c [sch_tbf] [ 78.673566][ T363] __qdisc_run+0x169/0x1900 The right thing to do in #1b is to grab the skb off gso_skb queue. This patchset fixes that issue by changing #1b to use qdisc_dequeue_peeked() method instead. Fixes: 77be155 ("pkt_sched: Add peek emulation for non-work-conserving qdiscs.") Reported-by: Manas <ghandatmanas@gmail.com> Reported-by: Rakshit Awasthi <rakshitawasthi17@gmail.com> Signed-off-by: Jamal Hadi Salim <jhs@mojatatu.com> Reviewed-by: Eric Dumazet <edumazet@google.com> Link: https://patch.msgid.link/20260430152957.194015-2-jhs@mojatatu.com Signed-off-by: Jakub Kicinski <kuba@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Ulrich Hecht <uli@kernel.org>
EdwinMoq
pushed a commit
that referenced
this pull request
Jul 12, 2026
[ Upstream commit 7d1f98d668ee34c1d15bdc0420fdd062f24a27c0 ] In passthrough mode, when dm-cache starts to invalidate a cache entry and bio prison cell lock fails due to concurrent write to the same cached block, mg->cell remains NULL. The error path in invalidate_complete() attempts to unlock and free the cell unconditionally, causing a NULL pointer dereference: KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007] CPU: 0 UID: 0 PID: 134 Comm: fio Not tainted 6.19.0-rc7 #3 PREEMPT RIP: 0010:dm_cell_unlock_v2+0x3f/0x210 <snip> Call Trace: invalidate_complete+0xef/0x430 map_bio+0x130f/0x1a10 cache_map+0x320/0x6b0 __map_bio+0x458/0x510 dm_submit_bio+0x40e/0x16d0 __submit_bio+0x419/0x870 <snip> Reproduce steps: 1. Create a cache device dmsetup create cmeta --table "0 8192 linear /dev/sdc 0" dmsetup create cdata --table "0 131072 linear /dev/sdc 8192" dmsetup create corig --table "0 262144 linear /dev/sdc 262144" dd if=/dev/zero of=/dev/mapper/cmeta bs=4k count=1 oflag=direct dmsetup create cache --table "0 262144 cache /dev/mapper/cmeta \ /dev/mapper/cdata /dev/mapper/corig 128 2 metadata2 writethrough smq 0" 2. Promote the first data block into cache fio --filename=/dev/mapper/cache --name=populate --rw=write --bs=4k \ --direct=1 --size=64k 3. Reload the cache into passthrough mode dmsetup suspend cache dmsetup reload cache --table "0 262144 cache /dev/mapper/cmeta \ /dev/mapper/cdata /dev/mapper/corig 128 2 metadata2 passthrough smq 0" dmsetup resume cache 4. Write to the first cached block concurrently fio --filename=/dev/mapper/cache --name test --rw=randwrite --bs=4k \ --randrepeat=0 --direct=1 --numjobs=2 --size 64k Fix by checking if mg->cell is valid before attempting to unlock it. Fixes: b29d498 ("dm cache: significant rework to leverage dm-bio-prison-v2") Signed-off-by: Ming-Hung Tsai <mtsai@redhat.com> Signed-off-by: Mikulas Patocka <mpatocka@redhat.com> Signed-off-by: Sasha Levin <sashal@kernel.org> Signed-off-by: Ulrich Hecht <uli@kernel.org>
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
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
19 participants
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.
The node name was repeated as a label, causing a build error with strict DT compilers.