- Kernel - mailweb.openeuler.org

[PATCH OLK-6.6] nvme: add missing SRCU grace period in error path
by Luo Gengkun 22 Sep '26

22 Sep '26

From: Tristan Madani <tristan(a)talencesecurity.com> mainline inclusion from mainline-v7.3-rc2 commit ef248d5de4469fb6bbaf8dbe0c4c47800080d648 category: bugfix bugzilla: https://atomgit.com/src-openeuler/kernel/issues/19101 CVE: CVE-2026-89972 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… ---------------------------------------------------------------------- nvme_alloc_ns() error path at out_unlink_ns removes ns from the namespace head siblings list with list_del_rcu(&ns->siblings) but does not wait for SRCU readers before freeing the namespace struct. Multipath code iterates the head->list under srcu_read_lock() in nvme_find_path() and nvme_mpath_revalidate_paths(), so a concurrent reader can still hold a reference to ns when kfree(ns) runs. The normal removal path in nvme_ns_remove() correctly calls synchronize_srcu(&ns->head->srcu) after list_del_rcu() to wait for in-progress readers. Add the same grace period in the error path. Fixes: ed754e5deeb1 ("nvme: track shared namespaces") Cc: stable(a)vger.kernel.org Signed-off-by: Tristan Madani <tristan(a)talencesecurity.com> Reviewed-by: Sagi Grimberg <sagi(a)grimberg.me> Reviewed-by: John Garry <john.g.garry(a)oracle.com> Reviewed-by: Christoph Hellwig <hch(a)lst.de> Signed-off-by: Keith Busch <kbusch(a)kernel.org> Conflicts: drivers/nvme/host/core.c [Adjusted patch context to account for missing last_path reference-counting code.] Signed-off-by: Luo Gengkun <luogengkun2(a)huawei.com> --- drivers/nvme/host/core.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/nvme/host/core.c b/drivers/nvme/host/core.c index f49ffa8daff5..6a60515e62b4 100644 --- a/drivers/nvme/host/core.c +++ b/drivers/nvme/host/core.c @@ -3757,6 +3757,9 @@ static void nvme_alloc_ns(struct nvme_ctrl *ctrl, struct nvme_ns_info *info) if (list_empty(&ns->head->list)) list_del_init(&ns->head->entry); mutex_unlock(&ctrl->subsys->lock); + + /* guarantee not available in head->list */ + synchronize_srcu(&ns->head->srcu); nvme_put_ns_head(ns->head); out_cleanup_disk: put_disk(disk); -- 2.34.1

2 1

[PATCH OLK-5.10] nvme: add missing SRCU grace period in error path
by Luo Gengkun 22 Sep '26

22 Sep '26

From: Tristan Madani <tristan(a)talencesecurity.com> mainline inclusion from mainline-v7.3-rc2 commit ef248d5de4469fb6bbaf8dbe0c4c47800080d648 category: bugfix bugzilla: https://atomgit.com/src-openeuler/kernel/issues/19101 CVE: CVE-2026-89972 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… ---------------------------------------------------------------------- nvme_alloc_ns() error path at out_unlink_ns removes ns from the namespace head siblings list with list_del_rcu(&ns->siblings) but does not wait for SRCU readers before freeing the namespace struct. Multipath code iterates the head->list under srcu_read_lock() in nvme_find_path() and nvme_mpath_revalidate_paths(), so a concurrent reader can still hold a reference to ns when kfree(ns) runs. The normal removal path in nvme_ns_remove() correctly calls synchronize_srcu(&ns->head->srcu) after list_del_rcu() to wait for in-progress readers. Add the same grace period in the error path. Fixes: ed754e5deeb1 ("nvme: track shared namespaces") Cc: stable(a)vger.kernel.org Signed-off-by: Tristan Madani <tristan(a)talencesecurity.com> Reviewed-by: Sagi Grimberg <sagi(a)grimberg.me> Reviewed-by: John Garry <john.g.garry(a)oracle.com> Reviewed-by: Christoph Hellwig <hch(a)lst.de> Signed-off-by: Keith Busch <kbusch(a)kernel.org> Conflicts: drivers/nvme/host/core.c [Adjusted patch context to account for missing last_path reference-counting code.] Signed-off-by: Luo Gengkun <luogengkun2(a)huawei.com> --- drivers/nvme/host/core.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/nvme/host/core.c b/drivers/nvme/host/core.c index cd2858916b64..caa0f1e900a0 100644 --- a/drivers/nvme/host/core.c +++ b/drivers/nvme/host/core.c @@ -4029,6 +4029,9 @@ static void nvme_alloc_ns(struct nvme_ctrl *ctrl, unsigned nsid, if (list_empty(&ns->head->list)) list_del_init(&ns->head->entry); mutex_unlock(&ctrl->subsys->lock); + + /* guarantee not available in head->list */ + synchronize_srcu(&ns->head->srcu); nvme_put_ns_head(ns->head); out_cleanup_disk: blk_cleanup_disk(disk); -- 2.34.1

2 1

[PATCH OLK-6.6 0/5] arm64: Fix NMI/DAIF handling in hibernate,
by Qinxin Xia 22 Sep '26

22 Sep '26

From: Xia Qinxin <xiaqinxin(a)opencode.com> arm64: Fix NMI/DAIF handling in hibernate, suspend and kprobes Ada Couprie Diaz (2): arm64: hibernate: mask DAIF before restoring hibernated kernel arm64: irq: Report FEAT_NMI masking local IRQs Vladimir Murzin (3): arm64: hibernate: Restore DAIF state on error arm64: suspend: Always initialise PSTATE.ALLINT arm64: kprobes: Disable NMIs arch/arm64/include/asm/irqflags.h | 21 +++++++++++++++++---- arch/arm64/include/asm/ptrace.h | 8 +++++--- arch/arm64/include/uapi/asm/ptrace.h | 1 + arch/arm64/kernel/hibernate.c | 16 +++++++++++++++- arch/arm64/kernel/probes/kprobes.c | 12 +++++++----- 5 files changed, 45 insertions(+), 13 deletions(-) -- 2.25.1

2 6

[OLK-5.10 v2] fuse: fix invalidate lock leak on open O_TRUNC DAX failure
by Yang Erkun 22 Sep '26

22 Sep '26

From: Baokun Li <libaokun(a)linux.alibaba.com> mainline inclusion from mainline-v7.3-rc1 commit a927f1867e61b78f39f9da0bbba3c98c2ca151fe category: bugfix bugzilla: https://atomgit.com/src-openeuler/kernel/issues/18697 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- fuse_open() takes filemap_invalidate_lock() for a DAX truncate (dax_truncate = true) and releases it before the out_inode_unlock label. But when fuse_dax_break_layouts() fails, the goto out_inode_unlock skips the unlock and leaks the rwsem, so any later fault or truncate on the file stalls on the stale lock. fuse_dax_break_layouts() can fail with -ERESTARTSYS when a signal interrupts the wait for busy DAX pages to drain: open("file", O_RDWR | O_TRUNC) └─ fuse_open() ├─ filemap_invalidate_lock() # dax_truncate └─ fuse_dax_break_layouts() └─ dax_break_layout() └─ wait_page_idle() # TASK_INTERRUPTIBLE └─ fuse_wait_dax_page() # unlock, schedule, re-lock └─ signal → -ERESTARTSYS goto out_inode_unlock # <- lock leaked Fix this by moving filemap_invalidate_unlock() below the label so that all error paths release the lock, and rename the label to out_unlock as it now covers more than just the inode lock. Fixes: 2fdbb8dd0155 ("fuse: fix deadlock between atomic O_TRUNC and page invalidation") Cc: stable(a)vger.kernel.org # v6.0+ Signed-off-by: Baokun Li <libaokun(a)linux.alibaba.com> Signed-off-by: Miklos Szeredi <mszeredi(a)redhat.com> Conflicts: fs/fuse/file.c [The target tree still uses i_mmap_sem instead of filemap_invalidate_lock(), so relocate up_write(&i_mmap_sem) below the renamed out_unlock label.] Signed-off-by: Yang Erkun <yangerkun(a)huawei.com> --- fs/fuse/file.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/fs/fuse/file.c b/fs/fuse/file.c index 87c8272d0e17..91fb1f67d6af 100644 --- a/fs/fuse/file.c +++ b/fs/fuse/file.c @@ -245,7 +245,7 @@ int fuse_open_common(struct inode *inode, struct file *file, bool isdir) down_write(&get_fuse_inode(inode)->i_mmap_sem); err = fuse_dax_break_layouts(inode, 0, 0); if (err) - goto out_inode_unlock; + goto out_unlock; } if (is_wb_truncate || dax_truncate) @@ -265,10 +265,10 @@ int fuse_open_common(struct inode *inode, struct file *file, bool isdir) else if (!(ff->open_flags & FOPEN_KEEP_CACHE)) invalidate_inode_pages2(inode->i_mapping); } +out_unlock: if (dax_truncate) up_write(&get_fuse_inode(inode)->i_mmap_sem); -out_inode_unlock: if (is_wb_truncate || dax_truncate) inode_unlock(inode); -- 2.52.0

1 0

[PATCH OLK-6.6] nvmet-tcp: reject unsolicited H2CData PDUs
by Luo Gengkun 22 Sep '26

22 Sep '26

From: Shivam Kumar <kumar.shivam43666(a)gmail.com> stable inclusion from stable-v6.6.157 commit 9fb527103e53fd43a8e802c2eca407869c204f7a category: bugfix bugzilla: https://atomgit.com/src-openeuler/kernel/issues/19098 CVE: CVE-2026-89968 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… ---------------------------------------------------------------------- commit db62b35cbca052860c519cbcabe7650708528738 upstream. nvmet_tcp_handle_h2c_data_pdu() accepts an H2CData PDU after only checking that its TTAG is a valid in-range command index and that the command's data buffers are mapped. It never checks that the target has actually solicited that data by sending an R2T for the command. A remote host can abuse this. It submits a write command that takes the R2T path and, before the target transmits the R2T, sends an H2CData PDU for that command's tag. The data completes the command early, and when the command then fails synchronously (e.g. a length mismatch caught by nvmet_check_transfer_len()), it is completed a second time. Each completion calls nvmet_tcp_queue_response(), so the same command is added to queue->resp_list twice while it is still linked; the second llist_add() makes the node point to itself (lentry->next == lentry). nvmet_tcp_process_resp_list() then walks that self-referential node and adds the command to resp_send_list twice. With CONFIG_DEBUG_LIST this trips the "list_add double add" check (kernel BUG); without it the loop never terminates and the nvmet_tcp workqueue wedges (soft-lockup). It is remotely triggerable and needs no authentication on an allow_any_host subsystem. Track whether an R2T has been transmitted for a command and reject an H2CData PDU that arrives before it. The flag is cleared on command reuse (nvmet_tcp_get_cmd() zeroes cmd->flags) and stays set across the multiple H2CData PDUs of a single solicited transfer. Fixes: 872d26a391da ("nvmet-tcp: add NVMe over TCP target driver") Cc: stable(a)vger.kernel.org Reviewed-by: Sagi Grimberg <sagi(a)grimberg.me> Signed-off-by: Shivam Kumar <kumar.shivam43666(a)gmail.com> Signed-off-by: Keith Busch <kbusch(a)kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Signed-off-by: Luo Gengkun <luogengkun2(a)huawei.com> --- drivers/nvme/target/tcp.c | 8 ++++++++ 1 file changed, 8 insertions(+) diff --git a/drivers/nvme/target/tcp.c b/drivers/nvme/target/tcp.c index 01da7c497c93..3af4c9e99571 100644 --- a/drivers/nvme/target/tcp.c +++ b/drivers/nvme/target/tcp.c @@ -88,6 +88,7 @@ enum nvmet_tcp_recv_state { enum { NVMET_TCP_F_INIT_FAILED = (1 << 0), + NVMET_TCP_F_R2T_SENT = (1 << 1), }; struct nvmet_tcp_cmd { @@ -761,6 +762,7 @@ static int nvmet_try_send_r2t(struct nvmet_tcp_cmd *cmd, bool last_in_batch) return -EAGAIN; cmd->queue->snd_cmd = NULL; + cmd->flags |= NVMET_TCP_F_R2T_SENT; return 1; } @@ -1029,6 +1031,12 @@ static int nvmet_tcp_handle_h2c_data_pdu(struct nvmet_tcp_queue *queue) cmd = &queue->connect; } + if (unlikely(!(cmd->flags & NVMET_TCP_F_R2T_SENT))) { + pr_err("queue %d: unsolicited H2CData (ttag %u)\n", + queue->idx, data->ttag); + goto err_proto; + } + if (le32_to_cpu(data->data_offset) != cmd->rbytes_done) { pr_err("ttag %u unexpected data offset %u (expected %u)\n", data->ttag, le32_to_cpu(data->data_offset), -- 2.34.1

2 1

[PATCH OLK-5.10] nvmet-tcp: reject unsolicited H2CData PDUs
by Luo Gengkun 22 Sep '26

22 Sep '26

From: Shivam Kumar <kumar.shivam43666(a)gmail.com> stable inclusion from stable-v5.10.270 commit 02341ee424fb2eed16b5b8a9d247492e49335c21 category: bugfix bugzilla: https://atomgit.com/src-openeuler/kernel/issues/19098 CVE: CVE-2026-89968 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… ---------------------------------------------------------------------- commit db62b35cbca052860c519cbcabe7650708528738 upstream. nvmet_tcp_handle_h2c_data_pdu() accepts an H2CData PDU after only checking that its TTAG is a valid in-range command index and that the command's data buffers are mapped. It never checks that the target has actually solicited that data by sending an R2T for the command. A remote host can abuse this. It submits a write command that takes the R2T path and, before the target transmits the R2T, sends an H2CData PDU for that command's tag. The data completes the command early, and when the command then fails synchronously (e.g. a length mismatch caught by nvmet_check_transfer_len()), it is completed a second time. Each completion calls nvmet_tcp_queue_response(), so the same command is added to queue->resp_list twice while it is still linked; the second llist_add() makes the node point to itself (lentry->next == lentry). nvmet_tcp_process_resp_list() then walks that self-referential node and adds the command to resp_send_list twice. With CONFIG_DEBUG_LIST this trips the "list_add double add" check (kernel BUG); without it the loop never terminates and the nvmet_tcp workqueue wedges (soft-lockup). It is remotely triggerable and needs no authentication on an allow_any_host subsystem. Track whether an R2T has been transmitted for a command and reject an H2CData PDU that arrives before it. The flag is cleared on command reuse (nvmet_tcp_get_cmd() zeroes cmd->flags) and stays set across the multiple H2CData PDUs of a single solicited transfer. Fixes: 872d26a391da ("nvmet-tcp: add NVMe over TCP target driver") Cc: stable(a)vger.kernel.org Reviewed-by: Sagi Grimberg <sagi(a)grimberg.me> Signed-off-by: Shivam Kumar <kumar.shivam43666(a)gmail.com> Signed-off-by: Keith Busch <kbusch(a)kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Signed-off-by: Luo Gengkun <luogengkun2(a)huawei.com> --- drivers/nvme/target/tcp.c | 8 ++++++++ 1 file changed, 8 insertions(+) diff --git a/drivers/nvme/target/tcp.c b/drivers/nvme/target/tcp.c index 3e04f3391943..b30556ee8729 100644 --- a/drivers/nvme/target/tcp.c +++ b/drivers/nvme/target/tcp.c @@ -51,6 +51,7 @@ enum nvmet_tcp_recv_state { enum { NVMET_TCP_F_INIT_FAILED = (1 << 0), + NVMET_TCP_F_R2T_SENT = (1 << 1), }; struct nvmet_tcp_cmd { @@ -697,6 +698,7 @@ static int nvmet_try_send_r2t(struct nvmet_tcp_cmd *cmd, bool last_in_batch) return -EAGAIN; cmd->queue->snd_cmd = NULL; + cmd->flags |= NVMET_TCP_F_R2T_SENT; return 1; } @@ -957,6 +959,12 @@ static int nvmet_tcp_handle_h2c_data_pdu(struct nvmet_tcp_queue *queue) cmd = &queue->connect; } + if (unlikely(!(cmd->flags & NVMET_TCP_F_R2T_SENT))) { + pr_err("queue %d: unsolicited H2CData (ttag %u)\n", + queue->idx, data->ttag); + goto err_proto; + } + if (le32_to_cpu(data->data_offset) != cmd->rbytes_done) { pr_err("ttag %u unexpected data offset %u (expected %u)\n", data->ttag, le32_to_cpu(data->data_offset), -- 2.34.1

2 1

[PATCH OLK-5.10] nvmet-tcp: fix out-of-bounds write when receiving an over-long PDU
by Luo Gengkun 22 Sep '26

22 Sep '26

From: Shivam Kumar <kumar.shivam43666(a)gmail.com> stable inclusion from stable-v5.10.270 commit a3f0bcfbaf3312a5754d1ce020a07d394669eb25 category: bugfix bugzilla: https://atomgit.com/src-openeuler/kernel/issues/19099 CVE: CVE-2026-89969 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… ---------------------------------------------------------------------- commit 14cc5a7e77731497d5bea70f3bb05df7eda982e4 upstream. nvmet_tcp_try_recv_pdu() reads a PDU header into the fixed 128-byte queue->pdu union, then computes the remaining payload length as queue->left = hdr->hlen - queue->offset + hdgst; and reads that many more bytes into &queue->pdu + queue->offset, without ever bounding the result against sizeof(queue->pdu). A struct nvme_tcp_icreq_pdu is itself 128 bytes, exactly the size of the union. Once a header digest has been negotiated (hdgst = 4), a second ICReq passes the hlen == nvmet_tcp_pdu_size() check but yields queue->left = 128 - 8 + 4 = 124, so bytes 8..132 are written into the 128-byte buffer -- 4 bytes past its end, over queue->hdr_digest and queue->data_digest. Those bytes are attacker-controlled (an ICReq carries no digest), and the duplicate ICReq is only rejected later, after the overflow. A remote unauthenticated host can thus corrupt kernel memory adjacent to the receive buffer. Reject any PDU whose declared length would read past the end of queue->pdu before the second recv. Fixes: 872d26a391da ("nvmet-tcp: add NVMe over TCP target driver") Assisted-by: Claude:claude-opus-4-8 Signed-off-by: Shivam Kumar <kumar.shivam43666(a)gmail.com> Cc: stable(a)vger.kernel.org Reviewed-by: Sagi Grimberg <sagi(a)grimberg.me> Signed-off-by: Keith Busch <kbusch(a)kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Signed-off-by: Luo Gengkun <luogengkun2(a)huawei.com> --- drivers/nvme/target/tcp.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/nvme/target/tcp.c b/drivers/nvme/target/tcp.c index 929049f421e3..3e04f3391943 100644 --- a/drivers/nvme/target/tcp.c +++ b/drivers/nvme/target/tcp.c @@ -1145,6 +1145,8 @@ static int nvmet_tcp_try_recv_pdu(struct nvmet_tcp_queue *queue) } queue->left = hdr->hlen - queue->offset + hdgst; + if (queue->left > sizeof(queue->pdu) - queue->offset) + return -EPROTO; goto recv; } -- 2.34.1

2 1

[PATCH OLK-6.6] nvmet-tcp: fix out-of-bounds write when receiving an over-long PDU
by Luo Gengkun 22 Sep '26

22 Sep '26

From: Shivam Kumar <kumar.shivam43666(a)gmail.com> stable inclusion from stable-v6.6.157 commit cf5f39d2b58f97e0cd1829c4a6aeef17f1607cca category: bugfix bugzilla: https://atomgit.com/src-openeuler/kernel/issues/19099 CVE: CVE-2026-89969 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… ---------------------------------------------------------------------- commit 14cc5a7e77731497d5bea70f3bb05df7eda982e4 upstream. nvmet_tcp_try_recv_pdu() reads a PDU header into the fixed 128-byte queue->pdu union, then computes the remaining payload length as queue->left = hdr->hlen - queue->offset + hdgst; and reads that many more bytes into &queue->pdu + queue->offset, without ever bounding the result against sizeof(queue->pdu). A struct nvme_tcp_icreq_pdu is itself 128 bytes, exactly the size of the union. Once a header digest has been negotiated (hdgst = 4), a second ICReq passes the hlen == nvmet_tcp_pdu_size() check but yields queue->left = 128 - 8 + 4 = 124, so bytes 8..132 are written into the 128-byte buffer -- 4 bytes past its end, over queue->hdr_digest and queue->data_digest. Those bytes are attacker-controlled (an ICReq carries no digest), and the duplicate ICReq is only rejected later, after the overflow. A remote unauthenticated host can thus corrupt kernel memory adjacent to the receive buffer. Reject any PDU whose declared length would read past the end of queue->pdu before the second recv. Fixes: 872d26a391da ("nvmet-tcp: add NVMe over TCP target driver") Assisted-by: Claude:claude-opus-4-8 Signed-off-by: Shivam Kumar <kumar.shivam43666(a)gmail.com> Cc: stable(a)vger.kernel.org Reviewed-by: Sagi Grimberg <sagi(a)grimberg.me> Signed-off-by: Keith Busch <kbusch(a)kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Signed-off-by: Luo Gengkun <luogengkun2(a)huawei.com> --- drivers/nvme/target/tcp.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/nvme/target/tcp.c b/drivers/nvme/target/tcp.c index a5a4443241cd..01da7c497c93 100644 --- a/drivers/nvme/target/tcp.c +++ b/drivers/nvme/target/tcp.c @@ -1224,6 +1224,8 @@ static int nvmet_tcp_try_recv_pdu(struct nvmet_tcp_queue *queue) } queue->left = hdr->hlen - queue->offset + hdgst; + if (queue->left > sizeof(queue->pdu) - queue->offset) + return -EPROTO; goto recv; } -- 2.34.1

2 1

[PATCH OLK-6.6] nvmet-auth: Synchronize timeout work during SQ teardown
by Luo Gengkun 22 Sep '26

22 Sep '26

From: Kazuki Hanai <hnkz.64(a)gmail.com> stable inclusion from stable-v6.6.157 commit c3c126a6142a1335bc8c34a5607c39cf01daf295 category: bugfix bugzilla: https://atomgit.com/src-openeuler/kernel/issues/19100 CVE: CVE-2026-89970 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… ---------------------------------------------------------------------- [ Upstream commit eaa948c0e19b1bb2d93262207bca0c3d19cc3406 ] nvmet_auth_sq_free() cancels auth_expired_work with cancel_delayed_work(). If the work has already started, cancellation does not wait for the callback. Transport teardown can consequently free or reuse the queue containing struct nvmet_sq while nvmet_auth_expired_work() still accesses that SQ. Add a teardown-specific helper that synchronously drains the delayed work before freeing authentication state, and use it from nvmet_sq_destroy(). Keep the non-synchronous helper for in-band authentication state cleanup, where the SQ owner remains alive. Fixes: 1a70200f404a ("nvmet-auth: expire authentication sessions") Cc: stable(a)vger.kernel.org Signed-off-by: Kazuki Hanai <hnkz.64(a)gmail.com> Reviewed-by: Sagi Grimberg <sagi(a)grimberg.me> Reviewed-by: Christoph Hellwig <hch(a)lst.de> Signed-off-by: Keith Busch <kbusch(a)kernel.org> Signed-off-by: Kazuki Hanai <hnkz.64(a)gmail.com> Signed-off-by: Sasha Levin <sashal(a)kernel.org> Signed-off-by: Luo Gengkun <luogengkun2(a)huawei.com> --- drivers/nvme/target/auth.c | 6 ++++++ drivers/nvme/target/core.c | 2 +- drivers/nvme/target/nvmet.h | 2 ++ 3 files changed, 9 insertions(+), 1 deletion(-) diff --git a/drivers/nvme/target/auth.c b/drivers/nvme/target/auth.c index 74791078fdeb..636a37130b22 100644 --- a/drivers/nvme/target/auth.c +++ b/drivers/nvme/target/auth.c @@ -231,6 +231,12 @@ void nvmet_auth_sq_free(struct nvmet_sq *sq) sq->dhchap_skey = NULL; } +void nvmet_auth_sq_destroy(struct nvmet_sq *sq) +{ + cancel_delayed_work_sync(&sq->auth_expired_work); + nvmet_auth_sq_free(sq); +} + void nvmet_destroy_auth(struct nvmet_ctrl *ctrl) { ctrl->shash_id = 0; diff --git a/drivers/nvme/target/core.c b/drivers/nvme/target/core.c index 12ff32cad6bd..e76394dc38f6 100644 --- a/drivers/nvme/target/core.c +++ b/drivers/nvme/target/core.c @@ -806,7 +806,7 @@ void nvmet_sq_destroy(struct nvmet_sq *sq) wait_for_completion(&sq->confirm_done); wait_for_completion(&sq->free_done); percpu_ref_exit(&sq->ref); - nvmet_auth_sq_free(sq); + nvmet_auth_sq_destroy(sq); /* * we must reference the ctrl again after waiting for inflight IO diff --git a/drivers/nvme/target/nvmet.h b/drivers/nvme/target/nvmet.h index 1a874ba90d1b..87033c8bd7b9 100644 --- a/drivers/nvme/target/nvmet.h +++ b/drivers/nvme/target/nvmet.h @@ -706,6 +706,7 @@ int nvmet_setup_auth(struct nvmet_ctrl *ctrl); void nvmet_auth_sq_init(struct nvmet_sq *sq); void nvmet_destroy_auth(struct nvmet_ctrl *ctrl); void nvmet_auth_sq_free(struct nvmet_sq *sq); +void nvmet_auth_sq_destroy(struct nvmet_sq *sq); int nvmet_setup_dhgroup(struct nvmet_ctrl *ctrl, u8 dhgroup_id); bool nvmet_check_auth_status(struct nvmet_req *req); int nvmet_auth_host_hash(struct nvmet_req *req, u8 *response, @@ -730,6 +731,7 @@ static inline void nvmet_auth_sq_init(struct nvmet_sq *sq) } static inline void nvmet_destroy_auth(struct nvmet_ctrl *ctrl) {}; static inline void nvmet_auth_sq_free(struct nvmet_sq *sq) {}; +static inline void nvmet_auth_sq_destroy(struct nvmet_sq *sq) {}; static inline bool nvmet_check_auth_status(struct nvmet_req *req) { return true; -- 2.34.1

2 1

[PATCH OLK-6.6 v2 0/4] arm64: smt: Introduce VIP-SMT QoS mode for SMT
by Yipeng Zou 22 Sep '26

22 Sep '26

This patchset introduces VIP-SMT, an Hisilicon-specific SMT QoS enhancement for Arm64. It allows marking specific hardware threads as "VIP" (high-priority) and others as non-VIP within the same physical core, enabling differentiated resource allocation (instruction fetch, execution pipeline, and out-of-order resources) for latency-sensitive workloads while background tasks run on non-VIP threads. Use cases include running real-time/network packet processing on VIP threads, performance isolation for mixed-criticality tasks, and QoS enforcement for cloud/virtualization scenarios. The series is organized as follows: Patch 1 refactors arch_cpu_idle_{enter,exit}() so the SMT measurement and the VIP-SMT hooks can be shared cleanly across all configs; the ACTLR_XCALL_XINT register save/restore is moved under its own config guard. Patch 2 is the core feature. It adds CONFIG_ARM64_VIP_SMT and a new vip_smt.c driver exposing per-CPU sysfs entries under /sys/devices/system/cpu/cpuN/regs/vip-smt/ to configure three ACTLR system registers (IFU_ACTLR1_EL1, OOO_DEC_ROB_SHA_CTLR_EL1, and OOO_DEC_DSP_CTLR_EL1). Feature detection is based on MIDR (HIP13), restricted to EL2 at the moment, and requires SMT to be enabled on the physical core. Per-CPU register values are shadowed and restored on idle exit so they survive core power-down. Patch 3 adds a "novipsmt" kernel command line parameter (with an optional "force" value) that disables the feature at boot time and prevents the vip_smt sysfs directory from being created. Since V1: Define ARM64_VIP_SMT in Kconfig.turbo to keep openeuler_defconfig aligned. Yipeng Zou (4): arm64: idle: make arch_cpu_idle_{enter,exit} more refactorable arm64: smt: Introduce VIP-SMT a QoS Mode for SMT arm64: smt: Add novipsmt kernel command line parameter arm64: configs: Enable ARM64_VIP_SMT in openeuler_defconfig .../admin-guide/kernel-parameters.txt | 4 + arch/arm64/Kconfig.turbo | 16 + arch/arm64/configs/openeuler_defconfig | 1 + arch/arm64/include/asm/vip_smt.h | 109 ++++ arch/arm64/kernel/Makefile | 1 + arch/arm64/kernel/cpufeature.c | 9 + arch/arm64/kernel/cpuinfo.c | 7 + arch/arm64/kernel/idle.c | 51 +- arch/arm64/kernel/vip_smt.c | 483 ++++++++++++++++++ arch/arm64/tools/cpucaps | 2 +- 10 files changed, 653 insertions(+), 30 deletions(-) create mode 100644 arch/arm64/include/asm/vip_smt.h create mode 100644 arch/arm64/kernel/vip_smt.c -- 2.34.1

2 5