April 2024 - Linux-stable-mirror

[PATCH for 5.15.y] nvme: fix miss command type check

by Tokunori Ikegami

From: "min15.li" <min15.li(a)samsung.com> commit 31a5978243d24d77be4bacca56c78a0fbc43b00d upstream. In the function nvme_passthru_end(), only the value of the command opcode is checked, without checking the command type (IO command or Admin command). When we send a Dataset Management command (The opcode of the Dataset Management command is the same as the Set Feature command), kernel thinks it is a set feature command, then sets the controller's keep alive interval, and calls nvme_keep_alive_work(). Signed-off-by: min15.li <min15.li(a)samsung.com> Reviewed-by: Kanchan Joshi <joshi.k(a)samsung.com> Reviewed-by: Christoph Hellwig <hch(a)lst.de> Signed-off-by: Keith Busch <kbusch(a)kernel.org> Fixes: b58da2d270db ("nvme: update keep alive interval when kato is modified") Signed-off-by: Tokunori Ikegami <ikegami.t(a)gmail.com> --- drivers/nvme/host/core.c | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/drivers/nvme/host/core.c b/drivers/nvme/host/core.c index 8f06e5c1706b..960a31e3307a 100644 --- a/drivers/nvme/host/core.c +++ b/drivers/nvme/host/core.c @@ -1185,7 +1185,7 @@ static u32 nvme_passthru_start(struct nvme_ctrl *ctrl, struct nvme_ns *ns, return effects; } -static void nvme_passthru_end(struct nvme_ctrl *ctrl, u32 effects, +static void nvme_passthru_end(struct nvme_ctrl *ctrl, struct nvme_ns *ns, u32 effects, struct nvme_command *cmd, int status) { if (effects & NVME_CMD_EFFECTS_CSE_MASK) { @@ -1201,6 +1201,8 @@ static void nvme_passthru_end(struct nvme_ctrl *ctrl, u32 effects, nvme_queue_scan(ctrl); flush_work(&ctrl->scan_work); } + if (ns) + return; switch (cmd->common.opcode) { case nvme_admin_set_features: @@ -1235,7 +1237,7 @@ int nvme_execute_passthru_rq(struct request *rq) effects = nvme_passthru_start(ctrl, ns, cmd->common.opcode); ret = nvme_execute_rq(disk, rq, false); if (effects) /* nothing to be done for zero cmd effects */ - nvme_passthru_end(ctrl, effects, cmd, ret); + nvme_passthru_end(ctrl, ns, effects, cmd, ret); return ret; } -- 2.40.1

1 year

2
1
0 0

FAILED: patch "[PATCH] gro: fix ownership transfer" failed to apply to 5.15-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 5.15-stable tree. If someone wants it applied there, or to any other stable or longterm tree, then please email the backport, including the original git commit id to <stable(a)vger.kernel.org>. To reproduce the conflict and resubmit, you may use the following commands: git fetch https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/ linux-5.15.y git checkout FETCH_HEAD git cherry-pick -x ed4cccef64c1d0d5b91e69f7a8a6697c3a865486 # <resolve conflicts, build, test, etc.> git commit -s git send-email --to '<stable(a)vger.kernel.org>' --in-reply-to '2024040543-backdrop-sequester-2458@gregkh' --subject-prefix 'PATCH 5.15.y' HEAD^.. Possible dependencies: thanks, greg k-h ------------------ original commit in Linus's tree ------------------ From ed4cccef64c1d0d5b91e69f7a8a6697c3a865486 Mon Sep 17 00:00:00 2001 From: Antoine Tenart <atenart(a)kernel.org> Date: Tue, 26 Mar 2024 12:33:59 +0100 Subject: [PATCH] gro: fix ownership transfer If packets are GROed with fraglist they might be segmented later on and continue their journey in the stack. In skb_segment_list those skbs can be reused as-is. This is an issue as their destructor was removed in skb_gro_receive_list but not the reference to their socket, and then they can't be orphaned. Fix this by also removing the reference to the socket. For example this could be observed, kernel BUG at include/linux/skbuff.h:3131! (skb_orphan) RIP: 0010:ip6_rcv_core+0x11bc/0x19a0 Call Trace: ipv6_list_rcv+0x250/0x3f0 __netif_receive_skb_list_core+0x49d/0x8f0 netif_receive_skb_list_internal+0x634/0xd40 napi_complete_done+0x1d2/0x7d0 gro_cell_poll+0x118/0x1f0 A similar construction is found in skb_gro_receive, apply the same change there. Fixes: 5e10da5385d2 ("skbuff: allow 'slow_gro' for skb carring sock reference") Signed-off-by: Antoine Tenart <atenart(a)kernel.org> Reviewed-by: Willem de Bruijn <willemb(a)google.com> Signed-off-by: David S. Miller <davem(a)davemloft.net> diff --git a/net/core/gro.c b/net/core/gro.c index ee30d4f0c038..83f35d99a682 100644 --- a/net/core/gro.c +++ b/net/core/gro.c @@ -192,8 +192,9 @@ int skb_gro_receive(struct sk_buff *p, struct sk_buff *skb) } merge: - /* sk owenrship - if any - completely transferred to the aggregated packet */ + /* sk ownership - if any - completely transferred to the aggregated packet */ skb->destructor = NULL; + skb->sk = NULL; delta_truesize = skb->truesize; if (offset > headlen) { unsigned int eat = offset - headlen; diff --git a/net/ipv4/udp_offload.c b/net/ipv4/udp_offload.c index e9719afe91cf..3bb69464930b 100644 --- a/net/ipv4/udp_offload.c +++ b/net/ipv4/udp_offload.c @@ -449,8 +449,9 @@ static int skb_gro_receive_list(struct sk_buff *p, struct sk_buff *skb) NAPI_GRO_CB(p)->count++; p->data_len += skb->len; - /* sk owenrship - if any - completely transferred to the aggregated packet */ + /* sk ownership - if any - completely transferred to the aggregated packet */ skb->destructor = NULL; + skb->sk = NULL; p->truesize += skb->truesize; p->len += skb->len;

1 year

3
2
0 0

FAILED: patch "[PATCH] mm/secretmem: fix GUP-fast succeeding on secretmem folios" failed to apply to 6.1-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 6.1-stable tree. If someone wants it applied there, or to any other stable or longterm tree, then please email the backport, including the original git commit id to <stable(a)vger.kernel.org>. To reproduce the conflict and resubmit, you may use the following commands: git fetch https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/ linux-6.1.y git checkout FETCH_HEAD git cherry-pick -x 65291dcfcf8936e1b23cfd7718fdfde7cfaf7706 # <resolve conflicts, build, test, etc.> git commit -s git send-email --to '<stable(a)vger.kernel.org>' --in-reply-to '2024040819-elf-bamboo-00f6@gregkh' --subject-prefix 'PATCH 6.1.y' HEAD^.. Possible dependencies: 65291dcfcf89 ("mm/secretmem: fix GUP-fast succeeding on secretmem folios") 8f9ff2deb8b9 ("secretmem: convert page_is_secretmem() to folio_is_secretmem()") thanks, greg k-h ------------------ original commit in Linus's tree ------------------ From 65291dcfcf8936e1b23cfd7718fdfde7cfaf7706 Mon Sep 17 00:00:00 2001 From: David Hildenbrand <david(a)redhat.com> Date: Tue, 26 Mar 2024 15:32:08 +0100 Subject: [PATCH] mm/secretmem: fix GUP-fast succeeding on secretmem folios folio_is_secretmem() currently relies on secretmem folios being LRU folios, to save some cycles. However, folios might reside in a folio batch without the LRU flag set, or temporarily have their LRU flag cleared. Consequently, the LRU flag is unreliable for this purpose. In particular, this is the case when secretmem_fault() allocates a fresh page and calls filemap_add_folio()->folio_add_lru(). The folio might be added to the per-cpu folio batch and won't get the LRU flag set until the batch was drained using e.g., lru_add_drain(). Consequently, folio_is_secretmem() might not detect secretmem folios and GUP-fast can succeed in grabbing a secretmem folio, crashing the kernel when we would later try reading/writing to the folio, because the folio has been unmapped from the directmap. Fix it by removing that unreliable check. Link: https://lkml.kernel.org/r/20240326143210.291116-2-david@redhat.com Fixes: 1507f51255c9 ("mm: introduce memfd_secret system call to create "secret" memory areas") Signed-off-by: David Hildenbrand <david(a)redhat.com> Reported-by: xingwei lee <xrivendell7(a)gmail.com> Reported-by: yue sun <samsun1006219(a)gmail.com> Closes: https://lore.kernel.org/lkml/CABOYnLyevJeravW=QrH0JUPYEcDN160aZFb7kwndm-J2r… Debugged-by: Miklos Szeredi <miklos(a)szeredi.hu> Tested-by: Miklos Szeredi <mszeredi(a)redhat.com> Reviewed-by: Mike Rapoport (IBM) <rppt(a)kernel.org> Cc: Lorenzo Stoakes <lstoakes(a)gmail.com> Cc: <stable(a)vger.kernel.org> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> diff --git a/include/linux/secretmem.h b/include/linux/secretmem.h index 35f3a4a8ceb1..acf7e1a3f3de 100644 --- a/include/linux/secretmem.h +++ b/include/linux/secretmem.h @@ -13,10 +13,10 @@ static inline bool folio_is_secretmem(struct folio *folio) /* * Using folio_mapping() is quite slow because of the actual call * instruction. - * We know that secretmem pages are not compound and LRU so we can + * We know that secretmem pages are not compound, so we can * save a couple of cycles here. */ - if (folio_test_large(folio) || !folio_test_lru(folio)) + if (folio_test_large(folio)) return false; mapping = (struct address_space *)

1 year

3
4
0 0

FAILED: patch "[PATCH] x86/bugs: Fix the SRSO mitigation on Zen3/4" failed to apply to 5.15-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 5.15-stable tree. If someone wants it applied there, or to any other stable or longterm tree, then please email the backport, including the original git commit id to <stable(a)vger.kernel.org>. To reproduce the conflict and resubmit, you may use the following commands: git fetch https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/ linux-5.15.y git checkout FETCH_HEAD git cherry-pick -x 4535e1a4174c4111d92c5a9a21e542d232e0fcaa # <resolve conflicts, build, test, etc.> git commit -s git send-email --to '<stable(a)vger.kernel.org>' --in-reply-to '2024033031-efficient-gallows-6872@gregkh' --subject-prefix 'PATCH 5.15.y' HEAD^.. Possible dependencies: thanks, greg k-h ------------------ original commit in Linus's tree ------------------ From 4535e1a4174c4111d92c5a9a21e542d232e0fcaa Mon Sep 17 00:00:00 2001 From: "Borislav Petkov (AMD)" <bp(a)alien8.de> Date: Thu, 28 Mar 2024 13:59:05 +0100 Subject: [PATCH] x86/bugs: Fix the SRSO mitigation on Zen3/4 The original version of the mitigation would patch in the calls to the untraining routines directly. That is, the alternative() in UNTRAIN_RET will patch in the CALL to srso_alias_untrain_ret() directly. However, even if commit e7c25c441e9e ("x86/cpu: Cleanup the untrain mess") meant well in trying to clean up the situation, due to micro- architectural reasons, the untraining routine srso_alias_untrain_ret() must be the target of a CALL instruction and not of a JMP instruction as it is done now. Reshuffle the alternative macros to accomplish that. Fixes: e7c25c441e9e ("x86/cpu: Cleanup the untrain mess") Signed-off-by: Borislav Petkov (AMD) <bp(a)alien8.de> Reviewed-by: Ingo Molnar <mingo(a)kernel.org> Cc: stable(a)kernel.org Signed-off-by: Linus Torvalds <torvalds(a)linux-foundation.org> diff --git a/arch/x86/include/asm/asm-prototypes.h b/arch/x86/include/asm/asm-prototypes.h index 076bf8dee702..25466c4d2134 100644 --- a/arch/x86/include/asm/asm-prototypes.h +++ b/arch/x86/include/asm/asm-prototypes.h @@ -14,6 +14,7 @@ #include <asm/asm.h> #include <asm/fred.h> #include <asm/gsseg.h> +#include <asm/nospec-branch.h> #ifndef CONFIG_X86_CMPXCHG64 extern void cmpxchg8b_emu(void); diff --git a/arch/x86/include/asm/nospec-branch.h b/arch/x86/include/asm/nospec-branch.h index fc3a8a3c7ffe..170c89ed22fc 100644 --- a/arch/x86/include/asm/nospec-branch.h +++ b/arch/x86/include/asm/nospec-branch.h @@ -262,11 +262,20 @@ .Lskip_rsb_\@: .endm +/* + * The CALL to srso_alias_untrain_ret() must be patched in directly at + * the spot where untraining must be done, ie., srso_alias_untrain_ret() + * must be the target of a CALL instruction instead of indirectly + * jumping to a wrapper which then calls it. Therefore, this macro is + * called outside of __UNTRAIN_RET below, for the time being, before the + * kernel can support nested alternatives with arbitrary nesting. + */ +.macro CALL_UNTRAIN_RET #if defined(CONFIG_MITIGATION_UNRET_ENTRY) || defined(CONFIG_MITIGATION_SRSO) -#define CALL_UNTRAIN_RET "call entry_untrain_ret" -#else -#define CALL_UNTRAIN_RET "" + ALTERNATIVE_2 "", "call entry_untrain_ret", X86_FEATURE_UNRET, \ + "call srso_alias_untrain_ret", X86_FEATURE_SRSO_ALIAS #endif +.endm /* * Mitigate RETBleed for AMD/Hygon Zen uarch. Requires KERNEL CR3 because the @@ -282,8 +291,8 @@ .macro __UNTRAIN_RET ibpb_feature, call_depth_insns #if defined(CONFIG_MITIGATION_RETHUNK) || defined(CONFIG_MITIGATION_IBPB_ENTRY) VALIDATE_UNRET_END - ALTERNATIVE_3 "", \ - CALL_UNTRAIN_RET, X86_FEATURE_UNRET, \ + CALL_UNTRAIN_RET + ALTERNATIVE_2 "", \ "call entry_ibpb", \ibpb_feature, \ __stringify(\call_depth_insns), X86_FEATURE_CALL_DEPTH #endif @@ -342,6 +351,8 @@ extern void retbleed_return_thunk(void); static inline void retbleed_return_thunk(void) {} #endif +extern void srso_alias_untrain_ret(void); + #ifdef CONFIG_MITIGATION_SRSO extern void srso_return_thunk(void); extern void srso_alias_return_thunk(void); diff --git a/arch/x86/lib/retpoline.S b/arch/x86/lib/retpoline.S index 721b528da9ac..02cde194a99e 100644 --- a/arch/x86/lib/retpoline.S +++ b/arch/x86/lib/retpoline.S @@ -163,6 +163,7 @@ SYM_CODE_START_NOALIGN(srso_alias_untrain_ret) lfence jmp srso_alias_return_thunk SYM_FUNC_END(srso_alias_untrain_ret) +__EXPORT_THUNK(srso_alias_untrain_ret) .popsection .pushsection .text..__x86.rethunk_safe @@ -224,10 +225,12 @@ SYM_CODE_START(srso_return_thunk) SYM_CODE_END(srso_return_thunk) #define JMP_SRSO_UNTRAIN_RET "jmp srso_untrain_ret" -#define JMP_SRSO_ALIAS_UNTRAIN_RET "jmp srso_alias_untrain_ret" #else /* !CONFIG_MITIGATION_SRSO */ +/* Dummy for the alternative in CALL_UNTRAIN_RET. */ +SYM_CODE_START(srso_alias_untrain_ret) + RET +SYM_FUNC_END(srso_alias_untrain_ret) #define JMP_SRSO_UNTRAIN_RET "ud2" -#define JMP_SRSO_ALIAS_UNTRAIN_RET "ud2" #endif /* CONFIG_MITIGATION_SRSO */ #ifdef CONFIG_MITIGATION_UNRET_ENTRY @@ -319,9 +322,7 @@ SYM_FUNC_END(retbleed_untrain_ret) #if defined(CONFIG_MITIGATION_UNRET_ENTRY) || defined(CONFIG_MITIGATION_SRSO) SYM_FUNC_START(entry_untrain_ret) - ALTERNATIVE_2 JMP_RETBLEED_UNTRAIN_RET, \ - JMP_SRSO_UNTRAIN_RET, X86_FEATURE_SRSO, \ - JMP_SRSO_ALIAS_UNTRAIN_RET, X86_FEATURE_SRSO_ALIAS + ALTERNATIVE JMP_RETBLEED_UNTRAIN_RET, JMP_SRSO_UNTRAIN_RET, X86_FEATURE_SRSO SYM_FUNC_END(entry_untrain_ret) __EXPORT_THUNK(entry_untrain_ret)

1 year

3
3
0 0

stable v6.6.24 regression: boot fails: bisected to "x86/mpparse: Register APIC address only once"

by Wolfgang Walter

Hello, after upgrading to v6.6.24 from v6.6.23 some old boxes (i686; Intel Celeron M) stop to boot: They hang after: Decompressing Linux... Parsing ELF... No relocation needed... done. Booting the kernel (entry_offset: 0x00000000). After some minutes they reboot. I bisected this down to commit bebb5af001dc6cb4f505bb21c4d5e2efbdc112e2 Author: Thomas Gleixner <tglx(a)linutronix.de> Date: Fri Mar 22 19:56:39 2024 +0100 x86/mpparse: Register APIC address only once [ Upstream commit f2208aa12c27bfada3c15c550c03ca81d42dcac2 ] The APIC address is registered twice. First during the early detection and afterwards when actually scanning the table for APIC IDs. The APIC and topology core warn about the second attempt. Restrict it to the early detection call. Fixes: 81287ad65da5 ("x86/apic: Sanitize APIC address setup") Signed-off-by: Thomas Gleixner <tglx(a)linutronix.de> Signed-off-by: Borislav Petkov (AMD) <bp(a)alien8.de> Tested-by: Guenter Roeck <linux(a)roeck-us.net> Link: https://lore.kernel.org/r/20240322185305.297774848@linutronix.de Signed-off-by: Sasha Levin <sashal(a)kernel.org> Reverting this commit in v6.6.24 solves the problem. Regards, -- Wolfgang Walter Studierendenwerk München Oberbayern Anstalt des öffentlichen Rechts

1 year

3
9
0 0

FAILED: patch "[PATCH] mm/secretmem: fix GUP-fast succeeding on secretmem folios" failed to apply to 5.15-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 5.15-stable tree. If someone wants it applied there, or to any other stable or longterm tree, then please email the backport, including the original git commit id to <stable(a)vger.kernel.org>. To reproduce the conflict and resubmit, you may use the following commands: git fetch https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/ linux-5.15.y git checkout FETCH_HEAD git cherry-pick -x 65291dcfcf8936e1b23cfd7718fdfde7cfaf7706 # <resolve conflicts, build, test, etc.> git commit -s git send-email --to '<stable(a)vger.kernel.org>' --in-reply-to '2024040823-spilt-marsupial-8d2f@gregkh' --subject-prefix 'PATCH 5.15.y' HEAD^.. Possible dependencies: 65291dcfcf89 ("mm/secretmem: fix GUP-fast succeeding on secretmem folios") 8f9ff2deb8b9 ("secretmem: convert page_is_secretmem() to folio_is_secretmem()") b0496fe4effd ("mm/gup: Convert gup_pte_range() to use a folio") thanks, greg k-h ------------------ original commit in Linus's tree ------------------ From 65291dcfcf8936e1b23cfd7718fdfde7cfaf7706 Mon Sep 17 00:00:00 2001 From: David Hildenbrand <david(a)redhat.com> Date: Tue, 26 Mar 2024 15:32:08 +0100 Subject: [PATCH] mm/secretmem: fix GUP-fast succeeding on secretmem folios folio_is_secretmem() currently relies on secretmem folios being LRU folios, to save some cycles. However, folios might reside in a folio batch without the LRU flag set, or temporarily have their LRU flag cleared. Consequently, the LRU flag is unreliable for this purpose. In particular, this is the case when secretmem_fault() allocates a fresh page and calls filemap_add_folio()->folio_add_lru(). The folio might be added to the per-cpu folio batch and won't get the LRU flag set until the batch was drained using e.g., lru_add_drain(). Consequently, folio_is_secretmem() might not detect secretmem folios and GUP-fast can succeed in grabbing a secretmem folio, crashing the kernel when we would later try reading/writing to the folio, because the folio has been unmapped from the directmap. Fix it by removing that unreliable check. Link: https://lkml.kernel.org/r/20240326143210.291116-2-david@redhat.com Fixes: 1507f51255c9 ("mm: introduce memfd_secret system call to create "secret" memory areas") Signed-off-by: David Hildenbrand <david(a)redhat.com> Reported-by: xingwei lee <xrivendell7(a)gmail.com> Reported-by: yue sun <samsun1006219(a)gmail.com> Closes: https://lore.kernel.org/lkml/CABOYnLyevJeravW=QrH0JUPYEcDN160aZFb7kwndm-J2r… Debugged-by: Miklos Szeredi <miklos(a)szeredi.hu> Tested-by: Miklos Szeredi <mszeredi(a)redhat.com> Reviewed-by: Mike Rapoport (IBM) <rppt(a)kernel.org> Cc: Lorenzo Stoakes <lstoakes(a)gmail.com> Cc: <stable(a)vger.kernel.org> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> diff --git a/include/linux/secretmem.h b/include/linux/secretmem.h index 35f3a4a8ceb1..acf7e1a3f3de 100644 --- a/include/linux/secretmem.h +++ b/include/linux/secretmem.h @@ -13,10 +13,10 @@ static inline bool folio_is_secretmem(struct folio *folio) /* * Using folio_mapping() is quite slow because of the actual call * instruction. - * We know that secretmem pages are not compound and LRU so we can + * We know that secretmem pages are not compound, so we can * save a couple of cycles here. */ - if (folio_test_large(folio) || !folio_test_lru(folio)) + if (folio_test_large(folio)) return false; mapping = (struct address_space *)

1 year

2
1
0 0

[PATCH v6.1.y 0/14 ] ACPI: resource: Add IRQ override quirks (backport changes from v6.9-rc3)

by kovalev＠altlinux.org

Added support internal keyboard for the following models: Asus ExpertBook (B1502CBA, B1502CGA, B1502CVA, B2402FBA, B2502FBA), Asus Vivobook (E1504GA, E1504GA, E1504GAB), TongFang GM6BGEQ / PCSpecialist Elimina Pro 16 M, RTX 3050, TongFang GM6BG5Q, RTX 4050, TongFang GM6BG0Q / PCSpecialist Elimina Pro 16 M, RTX 4060, Maibenben X565. Successfully tested on the available Asus ExpertBook B1502CVA model. [PATCH 6.1.y 01/14] ACPI: resource: Skip IRQ override on Asus Expertbook [PATCH 6.1.y 02/14] ACPI: resource: Skip IRQ override on ASUS ExpertBook [PATCH 6.1.y 03/14] ACPI: resource: Always use MADT override IRQ settings [PATCH 6.1.y 04/14] ACPI: resource: Honor MADT INT_SRC_OVR settings for [PATCH 6.1.y 05/14] ACPI: resource: Add IRQ override quirk for PCSpecialist [PATCH 6.1.y 06/14] ACPI: resource: Fix IRQ override quirk for PCSpecialist [PATCH 6.1.y 07/14] ACPI: resource: Consolidate IRQ trigger-type override [PATCH 6.1.y 08/14] ACPI: resource: Drop .ident values from dmi_system_id [PATCH 6.1.y 09/14] ACPI: resource: Add TongFang GM6BGEQ, GM6BG5Q and [PATCH 6.1.y 10/14] ACPI: resource: Add DMI quirks for ASUS Vivobook [PATCH 6.1.y 11/14] ACPI: resource: Skip IRQ override on ASUS ExpertBook [PATCH 6.1.y 12/14] ACPI: resource: Skip IRQ override on ASUS ExpertBook [PATCH 6.1.y 13/14] ACPI: resource: Add IRQ override quirk for ASUS [PATCH 6.1.y 14/14] ACPI: resource: Use IRQ override on Maibenben X565

1 year

1
14
0 0

[PATCH v6.6.y 0/7 ] ACPI: resource: Add IRQ override quirks (backport changes from v6.9-rc3)

by kovalev＠altlinux.org

Added support internal keyboard for the following models: Asus ExpertBook (B1502CGA, B1502CVA, B2502FBA), Asus Vivobook (E1504GA, E1504GAB), Maibenben X565. Successfully tested on the available Asus ExpertBook B1502CVA model. [PATCH 6.6.y 1/7] ACPI: resource: Consolidate IRQ trigger-type override DMI [PATCH 6.6.y 2/7] ACPI: resource: Drop .ident values from dmi_system_id [PATCH 6.6.y 3/7] ACPI: resource: Add DMI quirks for ASUS Vivobook E1504GA [PATCH 6.6.y 4/7] ACPI: resource: Skip IRQ override on ASUS ExpertBook [PATCH 6.6.y 5/7] ACPI: resource: Skip IRQ override on ASUS ExpertBook [PATCH 6.6.y 6/7] ACPI: resource: Add IRQ override quirk for ASUS [PATCH 6.6.y 7/7] ACPI: resource: Use IRQ override on Maibenben X565

1 year

1
7
0 0

[PATCH v6.8.y 0/3 ] ACPI: resource: Add IRQ override quirks (backport changes from v6.9-rc3)

by kovalev＠altlinux.org

Added support internal keyboard for the following models: Asus ExpertBook (B1502CVA, B2502FBA), Maibenben X565. Successfully tested on the available Asus ExpertBook B1502CVA model. [PATCH 6.8.y 1/3] ACPI: resource: Skip IRQ override on ASUS ExpertBook [PATCH 6.8.y 2/3] ACPI: resource: Add IRQ override quirk for ASUS [PATCH 6.8.y 3/3] ACPI: resource: Use IRQ override on Maibenben X565

1 year

1
3
0 0

FAILED: patch "[PATCH] drm/xe: Make TLB invalidation fences unordered" failed to apply to 6.8-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 6.8-stable tree. If someone wants it applied there, or to any other stable or longterm tree, then please email the backport, including the original git commit id to <stable(a)vger.kernel.org>. To reproduce the conflict and resubmit, you may use the following commands: git fetch https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/ linux-6.8.y git checkout FETCH_HEAD git cherry-pick -x fd1c8085113fb7c803fd81280f7e0bb25a5797ab # <resolve conflicts, build, test, etc.> git commit -s git send-email --to '<stable(a)vger.kernel.org>' --in-reply-to '2024040820-unfocused-ricotta-37e3@gregkh' --subject-prefix 'PATCH 6.8.y' HEAD^.. Possible dependencies: fd1c8085113f ("drm/xe: Make TLB invalidation fences unordered") 6240c2c43fd0 ("drm/xe: Document nested struct members according to guidelines") 997a55caa1c3 ("drm/xe/gsc: Initialize GSC proxy") 7c0f97cb62dc ("drm/xe: Invert access counter queue head / tail") 1fd77ceaf0d8 ("drm/xe: Invert page fault queue head / tail") 6ae24344e2e3 ("drm/xe: Add exec_queue.sched_props.job_timeout_ms") a8004af338f6 ("drm/xe: Fix modifying exec_queue priority in xe_migrate_init") b16483f9f812 ("drm/xe: Fix guc_exec_queue_set_priority") 9d612ee52c60 ("drm/xe: Annotate multiple mmio pointers with __iomem") fa78e188d8d1 ("drm/xe/dgfx: Release mmap mappings on rpm suspend") thanks, greg k-h ------------------ original commit in Linus's tree ------------------ From fd1c8085113fb7c803fd81280f7e0bb25a5797ab Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Thomas=20Hellstr=C3=B6m?= <thomas.hellstrom(a)linux.intel.com> Date: Wed, 27 Mar 2024 10:11:35 +0100 Subject: [PATCH] drm/xe: Make TLB invalidation fences unordered MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit They can actually complete out-of-order, so allocate a unique fence context for each fence. Fixes: 5387e865d90e ("drm/xe: Add TLB invalidation fence after rebinds issued from execs") Cc: Matthew Brost <matthew.brost(a)intel.com> Cc: <stable(a)vger.kernel.org> # v6.8+ Signed-off-by: Thomas Hellström <thomas.hellstrom(a)linux.intel.com> Reviewed-by: Matthew Brost <matthew.brost(a)intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240327091136.3271-4-thomas.… (cherry picked from commit 0453f1757501df2e82b66b3183a24bba5a6f8fa3) Signed-off-by: Lucas De Marchi <lucas.demarchi(a)intel.com> diff --git a/drivers/gpu/drm/xe/xe_gt_tlb_invalidation.c b/drivers/gpu/drm/xe/xe_gt_tlb_invalidation.c index f03e077f81a0..e598a4363d01 100644 --- a/drivers/gpu/drm/xe/xe_gt_tlb_invalidation.c +++ b/drivers/gpu/drm/xe/xe_gt_tlb_invalidation.c @@ -61,7 +61,6 @@ int xe_gt_tlb_invalidation_init(struct xe_gt *gt) INIT_LIST_HEAD(&gt->tlb_invalidation.pending_fences); spin_lock_init(&gt->tlb_invalidation.pending_lock); spin_lock_init(&gt->tlb_invalidation.lock); - gt->tlb_invalidation.fence_context = dma_fence_context_alloc(1); INIT_DELAYED_WORK(&gt->tlb_invalidation.fence_tdr, xe_gt_tlb_fence_timeout); diff --git a/drivers/gpu/drm/xe/xe_gt_types.h b/drivers/gpu/drm/xe/xe_gt_types.h index 70c615dd1498..07b2f724ec45 100644 --- a/drivers/gpu/drm/xe/xe_gt_types.h +++ b/drivers/gpu/drm/xe/xe_gt_types.h @@ -177,13 +177,6 @@ struct xe_gt { * xe_gt_tlb_fence_timeout after the timeut interval is over. */ struct delayed_work fence_tdr; - /** @tlb_invalidation.fence_context: context for TLB invalidation fences */ - u64 fence_context; - /** - * @tlb_invalidation.fence_seqno: seqno to TLB invalidation fences, protected by - * tlb_invalidation.lock - */ - u32 fence_seqno; /** @tlb_invalidation.lock: protects TLB invalidation fences */ spinlock_t lock; } tlb_invalidation; diff --git a/drivers/gpu/drm/xe/xe_pt.c b/drivers/gpu/drm/xe/xe_pt.c index 5fc4ad1e4298..29d1a31f9804 100644 --- a/drivers/gpu/drm/xe/xe_pt.c +++ b/drivers/gpu/drm/xe/xe_pt.c @@ -1135,8 +1135,7 @@ static int invalidation_fence_init(struct xe_gt *gt, spin_lock_irq(&gt->tlb_invalidation.lock); dma_fence_init(&ifence->base.base, &invalidation_fence_ops, &gt->tlb_invalidation.lock, - gt->tlb_invalidation.fence_context, - ++gt->tlb_invalidation.fence_seqno); + dma_fence_context_alloc(1), 1); spin_unlock_irq(&gt->tlb_invalidation.lock); INIT_LIST_HEAD(&ifence->base.link);

1 year

1
0
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror April 2024