* [PATCH 5.10 01/15] pinctrl: core: handle radix_tree_insert() errors in pinctrl_register_one_pin()
2024-05-23 13:12 [PATCH 5.10 00/15] 5.10.218-rc1 review Greg Kroah-Hartman
@ 2024-05-23 13:12 ` Greg Kroah-Hartman
2024-05-23 13:12 ` [PATCH 5.10 02/15] x86/xen: Drop USERGS_SYSRET64 paravirt call Greg Kroah-Hartman
` (19 subsequent siblings)
20 siblings, 0 replies; 22+ messages in thread
From: Greg Kroah-Hartman @ 2024-05-23 13:12 UTC (permalink / raw)
To: stable
Cc: Greg Kroah-Hartman, patches, Sergey Shtylyov, Linus Walleij,
Hemdan, Hagar Gamal Halim
5.10-stable review patch. If anyone has any objections, please let me know.
------------------
From: Sergey Shtylyov <s.shtylyov@omp.ru>
commit ecfe9a015d3e1e46504d5b3de7eef1f2d186194a upstream.
pinctrl_register_one_pin() doesn't check the result of radix_tree_insert()
despite they both may return a negative error code. Linus Walleij said he
has copied the radix tree code from kernel/irq/ where the functions calling
radix_tree_insert() are *void* themselves; I think it makes more sense to
propagate the errors from radix_tree_insert() upstream if we can do that...
Found by Linux Verification Center (linuxtesting.org) with the Svace static
analysis tool.
Signed-off-by: Sergey Shtylyov <s.shtylyov@omp.ru>
Link: https://lore.kernel.org/r/20230719202253.13469-3-s.shtylyov@omp.ru
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Cc: "Hemdan, Hagar Gamal Halim" <hagarhem@amazon.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/pinctrl/core.c | 14 +++++++++++---
1 file changed, 11 insertions(+), 3 deletions(-)
--- a/drivers/pinctrl/core.c
+++ b/drivers/pinctrl/core.c
@@ -205,6 +205,7 @@ static int pinctrl_register_one_pin(stru
const struct pinctrl_pin_desc *pin)
{
struct pin_desc *pindesc;
+ int error;
pindesc = pin_desc_get(pctldev, pin->number);
if (pindesc) {
@@ -226,18 +227,25 @@ static int pinctrl_register_one_pin(stru
} else {
pindesc->name = kasprintf(GFP_KERNEL, "PIN%u", pin->number);
if (!pindesc->name) {
- kfree(pindesc);
- return -ENOMEM;
+ error = -ENOMEM;
+ goto failed;
}
pindesc->dynamic_name = true;
}
pindesc->drv_data = pin->drv_data;
- radix_tree_insert(&pctldev->pin_desc_tree, pin->number, pindesc);
+ error = radix_tree_insert(&pctldev->pin_desc_tree, pin->number, pindesc);
+ if (error)
+ goto failed;
+
pr_debug("registered pin %d (%s) on %s\n",
pin->number, pindesc->name, pctldev->desc->name);
return 0;
+
+failed:
+ kfree(pindesc);
+ return error;
}
static int pinctrl_register_pins(struct pinctrl_dev *pctldev,
^ permalink raw reply [flat|nested] 22+ messages in thread* [PATCH 5.10 02/15] x86/xen: Drop USERGS_SYSRET64 paravirt call
2024-05-23 13:12 [PATCH 5.10 00/15] 5.10.218-rc1 review Greg Kroah-Hartman
2024-05-23 13:12 ` [PATCH 5.10 01/15] pinctrl: core: handle radix_tree_insert() errors in pinctrl_register_one_pin() Greg Kroah-Hartman
@ 2024-05-23 13:12 ` Greg Kroah-Hartman
2024-05-23 13:12 ` [PATCH 5.10 03/15] Revert "selftests: mm: fix map_hugetlb failure on 64K page size systems" Greg Kroah-Hartman
` (18 subsequent siblings)
20 siblings, 0 replies; 22+ messages in thread
From: Greg Kroah-Hartman @ 2024-05-23 13:12 UTC (permalink / raw)
To: stable
Cc: Greg Kroah-Hartman, patches, Juergen Gross, Borislav Petkov,
Pawan Gupta
5.10-stable review patch. If anyone has any objections, please let me know.
------------------
From: Juergen Gross <jgross@suse.com>
commit afd30525a659ac0ae0904f0cb4a2ca75522c3123 upstream.
USERGS_SYSRET64 is used to return from a syscall via SYSRET, but
a Xen PV guest will nevertheless use the IRET hypercall, as there
is no sysret PV hypercall defined.
So instead of testing all the prerequisites for doing a sysret and
then mangling the stack for Xen PV again for doing an iret just use
the iret exit from the beginning.
This can easily be done via an ALTERNATIVE like it is done for the
sysenter compat case already.
It should be noted that this drops the optimization in Xen for not
restoring a few registers when returning to user mode, but it seems
as if the saved instructions in the kernel more than compensate for
this drop (a kernel build in a Xen PV guest was slightly faster with
this patch applied).
While at it remove the stale sysret32 remnants.
[ pawan: Brad Spengler and Salvatore Bonaccorso <carnil@debian.org>
reported a problem with the 5.10 backport commit edc702b4a820
("x86/entry_64: Add VERW just before userspace transition").
When CONFIG_PARAVIRT_XXL=y, CLEAR_CPU_BUFFERS is not executed in
syscall_return_via_sysret path as USERGS_SYSRET64 is runtime
patched to:
.cpu_usergs_sysret64 = { 0x0f, 0x01, 0xf8,
0x48, 0x0f, 0x07 }, // swapgs; sysretq
which is missing CLEAR_CPU_BUFFERS. It turns out dropping
USERGS_SYSRET64 simplifies the code, allowing CLEAR_CPU_BUFFERS
to be explicitly added to syscall_return_via_sysret path. Below
is with CONFIG_PARAVIRT_XXL=y and this patch applied:
syscall_return_via_sysret:
...
<+342>: swapgs
<+345>: xchg %ax,%ax
<+347>: verw -0x1a2(%rip) <------
<+354>: sysretq
]
Signed-off-by: Juergen Gross <jgross@suse.com>
Signed-off-by: Borislav Petkov <bp@suse.de>
Signed-off-by: Pawan Gupta <pawan.kumar.gupta@linux.intel.com>
Link: https://lkml.kernel.org/r/20210120135555.32594-6-jgross@suse.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
arch/x86/entry/entry_64.S | 17 ++++++++---------
arch/x86/include/asm/irqflags.h | 7 -------
arch/x86/include/asm/paravirt.h | 5 -----
arch/x86/include/asm/paravirt_types.h | 8 --------
arch/x86/kernel/asm-offsets_64.c | 2 --
arch/x86/kernel/paravirt.c | 5 +----
arch/x86/kernel/paravirt_patch.c | 4 ----
arch/x86/xen/enlighten_pv.c | 1 -
arch/x86/xen/xen-asm.S | 21 ---------------------
arch/x86/xen/xen-ops.h | 2 --
10 files changed, 9 insertions(+), 63 deletions(-)
--- a/arch/x86/entry/entry_64.S
+++ b/arch/x86/entry/entry_64.S
@@ -46,14 +46,6 @@
.code64
.section .entry.text, "ax"
-#ifdef CONFIG_PARAVIRT_XXL
-SYM_CODE_START(native_usergs_sysret64)
- UNWIND_HINT_EMPTY
- swapgs
- sysretq
-SYM_CODE_END(native_usergs_sysret64)
-#endif /* CONFIG_PARAVIRT_XXL */
-
/*
* 64-bit SYSCALL instruction entry. Up to 6 arguments in registers.
*
@@ -128,7 +120,12 @@ SYM_INNER_LABEL(entry_SYSCALL_64_after_h
* Try to use SYSRET instead of IRET if we're returning to
* a completely clean 64-bit userspace context. If we're not,
* go to the slow exit path.
+ * In the Xen PV case we must use iret anyway.
*/
+
+ ALTERNATIVE "", "jmp swapgs_restore_regs_and_return_to_usermode", \
+ X86_FEATURE_XENPV
+
movq RCX(%rsp), %rcx
movq RIP(%rsp), %r11
@@ -220,7 +217,9 @@ syscall_return_via_sysret:
popq %rdi
popq %rsp
- USERGS_SYSRET64
+ swapgs
+ CLEAR_CPU_BUFFERS
+ sysretq
SYM_CODE_END(entry_SYSCALL_64)
/*
--- a/arch/x86/include/asm/irqflags.h
+++ b/arch/x86/include/asm/irqflags.h
@@ -132,13 +132,6 @@ static __always_inline unsigned long arc
#endif
#define INTERRUPT_RETURN jmp native_iret
-#define USERGS_SYSRET64 \
- swapgs; \
- CLEAR_CPU_BUFFERS; \
- sysretq;
-#define USERGS_SYSRET32 \
- swapgs; \
- sysretl
#else
#define INTERRUPT_RETURN iret
--- a/arch/x86/include/asm/paravirt.h
+++ b/arch/x86/include/asm/paravirt.h
@@ -776,11 +776,6 @@ extern void default_banner(void);
#ifdef CONFIG_X86_64
#ifdef CONFIG_PARAVIRT_XXL
-#define USERGS_SYSRET64 \
- PARA_SITE(PARA_PATCH(PV_CPU_usergs_sysret64), \
- ANNOTATE_RETPOLINE_SAFE; \
- jmp PARA_INDIRECT(pv_ops+PV_CPU_usergs_sysret64);)
-
#ifdef CONFIG_DEBUG_ENTRY
#define SAVE_FLAGS(clobbers) \
PARA_SITE(PARA_PATCH(PV_IRQ_save_fl), \
--- a/arch/x86/include/asm/paravirt_types.h
+++ b/arch/x86/include/asm/paravirt_types.h
@@ -157,14 +157,6 @@ struct pv_cpu_ops {
u64 (*read_pmc)(int counter);
- /*
- * Switch to usermode gs and return to 64-bit usermode using
- * sysret. Only used in 64-bit kernels to return to 64-bit
- * processes. Usermode register state, including %rsp, must
- * already be restored.
- */
- void (*usergs_sysret64)(void);
-
/* Normal iret. Jump to this with the standard iret stack
frame set up. */
void (*iret)(void);
--- a/arch/x86/kernel/asm-offsets_64.c
+++ b/arch/x86/kernel/asm-offsets_64.c
@@ -13,8 +13,6 @@ int main(void)
{
#ifdef CONFIG_PARAVIRT
#ifdef CONFIG_PARAVIRT_XXL
- OFFSET(PV_CPU_usergs_sysret64, paravirt_patch_template,
- cpu.usergs_sysret64);
#ifdef CONFIG_DEBUG_ENTRY
OFFSET(PV_IRQ_save_fl, paravirt_patch_template, irq.save_fl);
#endif
--- a/arch/x86/kernel/paravirt.c
+++ b/arch/x86/kernel/paravirt.c
@@ -124,8 +124,7 @@ unsigned paravirt_patch_default(u8 type,
else if (opfunc == _paravirt_ident_64)
ret = paravirt_patch_ident_64(insn_buff, len);
- else if (type == PARAVIRT_PATCH(cpu.iret) ||
- type == PARAVIRT_PATCH(cpu.usergs_sysret64))
+ else if (type == PARAVIRT_PATCH(cpu.iret))
/* If operation requires a jmp, then jmp */
ret = paravirt_patch_jmp(insn_buff, opfunc, addr, len);
#endif
@@ -159,7 +158,6 @@ static u64 native_steal_clock(int cpu)
/* These are in entry.S */
extern void native_iret(void);
-extern void native_usergs_sysret64(void);
static struct resource reserve_ioports = {
.start = 0,
@@ -299,7 +297,6 @@ struct paravirt_patch_template pv_ops =
.cpu.load_sp0 = native_load_sp0,
- .cpu.usergs_sysret64 = native_usergs_sysret64,
.cpu.iret = native_iret,
#ifdef CONFIG_X86_IOPL_IOPERM
--- a/arch/x86/kernel/paravirt_patch.c
+++ b/arch/x86/kernel/paravirt_patch.c
@@ -27,7 +27,6 @@ struct patch_xxl {
const unsigned char mmu_write_cr3[3];
const unsigned char irq_restore_fl[2];
const unsigned char cpu_wbinvd[2];
- const unsigned char cpu_usergs_sysret64[6];
const unsigned char mov64[3];
};
@@ -40,8 +39,6 @@ static const struct patch_xxl patch_data
.mmu_write_cr3 = { 0x0f, 0x22, 0xdf }, // mov %rdi, %cr3
.irq_restore_fl = { 0x57, 0x9d }, // push %rdi; popfq
.cpu_wbinvd = { 0x0f, 0x09 }, // wbinvd
- .cpu_usergs_sysret64 = { 0x0f, 0x01, 0xf8,
- 0x48, 0x0f, 0x07 }, // swapgs; sysretq
.mov64 = { 0x48, 0x89, 0xf8 }, // mov %rdi, %rax
};
@@ -83,7 +80,6 @@ unsigned int native_patch(u8 type, void
PATCH_CASE(mmu, read_cr3, xxl, insn_buff, len);
PATCH_CASE(mmu, write_cr3, xxl, insn_buff, len);
- PATCH_CASE(cpu, usergs_sysret64, xxl, insn_buff, len);
PATCH_CASE(cpu, wbinvd, xxl, insn_buff, len);
#endif
--- a/arch/x86/xen/enlighten_pv.c
+++ b/arch/x86/xen/enlighten_pv.c
@@ -1059,7 +1059,6 @@ static const struct pv_cpu_ops xen_cpu_o
.read_pmc = xen_read_pmc,
.iret = xen_iret,
- .usergs_sysret64 = xen_sysret64,
.load_tr_desc = paravirt_nop,
.set_ldt = xen_set_ldt,
--- a/arch/x86/xen/xen-asm.S
+++ b/arch/x86/xen/xen-asm.S
@@ -220,27 +220,6 @@ SYM_CODE_START(xen_iret)
jmp hypercall_iret
SYM_CODE_END(xen_iret)
-SYM_CODE_START(xen_sysret64)
- UNWIND_HINT_EMPTY
- /*
- * We're already on the usermode stack at this point, but
- * still with the kernel gs, so we can easily switch back.
- *
- * tss.sp2 is scratch space.
- */
- movq %rsp, PER_CPU_VAR(cpu_tss_rw + TSS_sp2)
- movq PER_CPU_VAR(cpu_current_top_of_stack), %rsp
-
- pushq $__USER_DS
- pushq PER_CPU_VAR(cpu_tss_rw + TSS_sp2)
- pushq %r11
- pushq $__USER_CS
- pushq %rcx
-
- pushq $VGCF_in_syscall
- jmp hypercall_iret
-SYM_CODE_END(xen_sysret64)
-
/*
* XEN pv doesn't use trampoline stack, PER_CPU_VAR(cpu_tss_rw + TSS_sp0) is
* also the kernel stack. Reusing swapgs_restore_regs_and_return_to_usermode()
--- a/arch/x86/xen/xen-ops.h
+++ b/arch/x86/xen/xen-ops.h
@@ -138,8 +138,6 @@ __visible unsigned long xen_read_cr2_dir
/* These are not functions, and cannot be called normally */
__visible void xen_iret(void);
-__visible void xen_sysret32(void);
-__visible void xen_sysret64(void);
extern int xen_panic_handler_init(void);
^ permalink raw reply [flat|nested] 22+ messages in thread* [PATCH 5.10 03/15] Revert "selftests: mm: fix map_hugetlb failure on 64K page size systems"
2024-05-23 13:12 [PATCH 5.10 00/15] 5.10.218-rc1 review Greg Kroah-Hartman
2024-05-23 13:12 ` [PATCH 5.10 01/15] pinctrl: core: handle radix_tree_insert() errors in pinctrl_register_one_pin() Greg Kroah-Hartman
2024-05-23 13:12 ` [PATCH 5.10 02/15] x86/xen: Drop USERGS_SYSRET64 paravirt call Greg Kroah-Hartman
@ 2024-05-23 13:12 ` Greg Kroah-Hartman
2024-05-23 13:12 ` [PATCH 5.10 04/15] net: bcmgenet: synchronize EXT_RGMII_OOB_CTRL access Greg Kroah-Hartman
` (17 subsequent siblings)
20 siblings, 0 replies; 22+ messages in thread
From: Greg Kroah-Hartman @ 2024-05-23 13:12 UTC (permalink / raw)
To: stable
Cc: Greg Kroah-Hartman, patches,
sashal@kernel.org, vegard.nossum@oracle.com, darren.kenny@oracle.com, Harshit Mogalapalli,
Harshit Mogalapalli
5.10-stable review patch. If anyone has any objections, please let me know.
------------------
This reverts commit c9c3cc6a13bddc76bb533ad8147a5528cac5ba5a which is
commit 91b80cc5b39f00399e8e2d17527cad2c7fa535e2 upstream.
map_hugetlb.c:18:10: fatal error: vm_util.h: No such file or directory
18 | #include "vm_util.h"
| ^~~~~~~~~~~
compilation terminated.
vm_util.h is not present in 5.10.y, as commit:642bc52aed9c ("selftests:
vm: bring common functions to a new file") is not present in stable
kernels <=6.1.y
Signed-off-by: Harshit Mogalapalli <harshit.m.mogalapalli@oracle.com>
---
tools/testing/selftests/vm/map_hugetlb.c | 7 -------
1 file changed, 7 deletions(-)
--- a/tools/testing/selftests/vm/map_hugetlb.c
+++ b/tools/testing/selftests/vm/map_hugetlb.c
@@ -15,7 +15,6 @@
#include <unistd.h>
#include <sys/mman.h>
#include <fcntl.h>
-#include "vm_util.h"
#define LENGTH (256UL*1024*1024)
#define PROTECTION (PROT_READ | PROT_WRITE)
@@ -71,16 +70,10 @@ int main(int argc, char **argv)
{
void *addr;
int ret;
- size_t hugepage_size;
size_t length = LENGTH;
int flags = FLAGS;
int shift = 0;
- hugepage_size = default_huge_page_size();
- /* munmap with fail if the length is not page aligned */
- if (hugepage_size > length)
- length = hugepage_size;
-
if (argc > 1)
length = atol(argv[1]) << 20;
if (argc > 2) {
^ permalink raw reply [flat|nested] 22+ messages in thread* [PATCH 5.10 04/15] net: bcmgenet: synchronize EXT_RGMII_OOB_CTRL access
2024-05-23 13:12 [PATCH 5.10 00/15] 5.10.218-rc1 review Greg Kroah-Hartman
` (2 preceding siblings ...)
2024-05-23 13:12 ` [PATCH 5.10 03/15] Revert "selftests: mm: fix map_hugetlb failure on 64K page size systems" Greg Kroah-Hartman
@ 2024-05-23 13:12 ` Greg Kroah-Hartman
2024-05-23 13:12 ` [PATCH 5.10 05/15] net: bcmgenet: synchronize UMAC_CMD access Greg Kroah-Hartman
` (16 subsequent siblings)
20 siblings, 0 replies; 22+ messages in thread
From: Greg Kroah-Hartman @ 2024-05-23 13:12 UTC (permalink / raw)
To: stable
Cc: Greg Kroah-Hartman, patches, Doug Berger, Florian Fainelli,
David S. Miller
5.10-stable review patch. If anyone has any objections, please let me know.
------------------
From: Doug Berger <opendmb@gmail.com>
commit d85cf67a339685beae1d0aee27b7f61da95455be upstream.
The EXT_RGMII_OOB_CTRL register can be written from different
contexts. It is predominantly written from the adjust_link
handler which is synchronized by the phydev->lock, but can
also be written from a different context when configuring the
mii in bcmgenet_mii_config().
The chances of contention are quite low, but it is conceivable
that adjust_link could occur during resume when WoL is enabled
so use the phydev->lock synchronizer in bcmgenet_mii_config()
to be sure.
Fixes: afe3f907d20f ("net: bcmgenet: power on MII block for all MII modes")
Cc: stable@vger.kernel.org
Signed-off-by: Doug Berger <opendmb@gmail.com>
Acked-by: Florian Fainelli <florian.fainelli@broadcom.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/net/ethernet/broadcom/genet/bcmmii.c | 2 ++
1 file changed, 2 insertions(+)
--- a/drivers/net/ethernet/broadcom/genet/bcmmii.c
+++ b/drivers/net/ethernet/broadcom/genet/bcmmii.c
@@ -264,6 +264,7 @@ int bcmgenet_mii_config(struct net_devic
* block for the interface to work
*/
if (priv->ext_phy) {
+ mutex_lock(&phydev->lock);
reg = bcmgenet_ext_readl(priv, EXT_RGMII_OOB_CTRL);
reg &= ~ID_MODE_DIS;
reg |= id_mode_dis;
@@ -272,6 +273,7 @@ int bcmgenet_mii_config(struct net_devic
else
reg |= RGMII_MODE_EN;
bcmgenet_ext_writel(priv, reg, EXT_RGMII_OOB_CTRL);
+ mutex_unlock(&phydev->lock);
}
if (init)
^ permalink raw reply [flat|nested] 22+ messages in thread* [PATCH 5.10 05/15] net: bcmgenet: synchronize UMAC_CMD access
2024-05-23 13:12 [PATCH 5.10 00/15] 5.10.218-rc1 review Greg Kroah-Hartman
` (3 preceding siblings ...)
2024-05-23 13:12 ` [PATCH 5.10 04/15] net: bcmgenet: synchronize EXT_RGMII_OOB_CTRL access Greg Kroah-Hartman
@ 2024-05-23 13:12 ` Greg Kroah-Hartman
2024-05-23 13:12 ` [PATCH 5.10 06/15] ima: fix deadlock when traversing "ima_default_rules" Greg Kroah-Hartman
` (15 subsequent siblings)
20 siblings, 0 replies; 22+ messages in thread
From: Greg Kroah-Hartman @ 2024-05-23 13:12 UTC (permalink / raw)
To: stable
Cc: Greg Kroah-Hartman, patches, Doug Berger, Florian Fainelli,
David S. Miller
5.10-stable review patch. If anyone has any objections, please let me know.
------------------
From: Doug Berger <opendmb@gmail.com>
commit 0d5e2a82232605b337972fb2c7d0cbc46898aca1 upstream.
The UMAC_CMD register is written from different execution
contexts and has insufficient synchronization protections to
prevent possible corruption. Of particular concern are the
acceses from the phy_device delayed work context used by the
adjust_link call and the BH context that may be used by the
ndo_set_rx_mode call.
A spinlock is added to the driver to protect contended register
accesses (i.e. reg_lock) and it is used to synchronize accesses
to UMAC_CMD.
Fixes: 1c1008c793fa ("net: bcmgenet: add main driver file")
Cc: stable@vger.kernel.org
Signed-off-by: Doug Berger <opendmb@gmail.com>
Acked-by: Florian Fainelli <florian.fainelli@broadcom.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/net/ethernet/broadcom/genet/bcmgenet.c | 12 +++++++++++-
drivers/net/ethernet/broadcom/genet/bcmgenet.h | 2 ++
drivers/net/ethernet/broadcom/genet/bcmgenet_wol.c | 6 ++++++
drivers/net/ethernet/broadcom/genet/bcmmii.c | 2 ++
4 files changed, 21 insertions(+), 1 deletion(-)
--- a/drivers/net/ethernet/broadcom/genet/bcmgenet.c
+++ b/drivers/net/ethernet/broadcom/genet/bcmgenet.c
@@ -2420,14 +2420,18 @@ static void umac_enable_set(struct bcmge
{
u32 reg;
+ spin_lock_bh(&priv->reg_lock);
reg = bcmgenet_umac_readl(priv, UMAC_CMD);
- if (reg & CMD_SW_RESET)
+ if (reg & CMD_SW_RESET) {
+ spin_unlock_bh(&priv->reg_lock);
return;
+ }
if (enable)
reg |= mask;
else
reg &= ~mask;
bcmgenet_umac_writel(priv, reg, UMAC_CMD);
+ spin_unlock_bh(&priv->reg_lock);
/* UniMAC stops on a packet boundary, wait for a full-size packet
* to be processed
@@ -2443,8 +2447,10 @@ static void reset_umac(struct bcmgenet_p
udelay(10);
/* issue soft reset and disable MAC while updating its registers */
+ spin_lock_bh(&priv->reg_lock);
bcmgenet_umac_writel(priv, CMD_SW_RESET, UMAC_CMD);
udelay(2);
+ spin_unlock_bh(&priv->reg_lock);
}
static void bcmgenet_intr_disable(struct bcmgenet_priv *priv)
@@ -3572,16 +3578,19 @@ static void bcmgenet_set_rx_mode(struct
* 3. The number of filters needed exceeds the number filters
* supported by the hardware.
*/
+ spin_lock(&priv->reg_lock);
reg = bcmgenet_umac_readl(priv, UMAC_CMD);
if ((dev->flags & (IFF_PROMISC | IFF_ALLMULTI)) ||
(nfilter > MAX_MDF_FILTER)) {
reg |= CMD_PROMISC;
bcmgenet_umac_writel(priv, reg, UMAC_CMD);
+ spin_unlock(&priv->reg_lock);
bcmgenet_umac_writel(priv, 0, UMAC_MDF_CTRL);
return;
} else {
reg &= ~CMD_PROMISC;
bcmgenet_umac_writel(priv, reg, UMAC_CMD);
+ spin_unlock(&priv->reg_lock);
}
/* update MDF filter */
@@ -3975,6 +3984,7 @@ static int bcmgenet_probe(struct platfor
goto err;
}
+ spin_lock_init(&priv->reg_lock);
spin_lock_init(&priv->lock);
SET_NETDEV_DEV(dev, &pdev->dev);
--- a/drivers/net/ethernet/broadcom/genet/bcmgenet.h
+++ b/drivers/net/ethernet/broadcom/genet/bcmgenet.h
@@ -627,6 +627,8 @@ struct bcmgenet_rxnfc_rule {
/* device context */
struct bcmgenet_priv {
void __iomem *base;
+ /* reg_lock: lock to serialize access to shared registers */
+ spinlock_t reg_lock;
enum bcmgenet_version version;
struct net_device *dev;
--- a/drivers/net/ethernet/broadcom/genet/bcmgenet_wol.c
+++ b/drivers/net/ethernet/broadcom/genet/bcmgenet_wol.c
@@ -134,6 +134,7 @@ int bcmgenet_wol_power_down_cfg(struct b
}
/* Can't suspend with WoL if MAC is still in reset */
+ spin_lock_bh(&priv->reg_lock);
reg = bcmgenet_umac_readl(priv, UMAC_CMD);
if (reg & CMD_SW_RESET)
reg &= ~CMD_SW_RESET;
@@ -141,6 +142,7 @@ int bcmgenet_wol_power_down_cfg(struct b
/* disable RX */
reg &= ~CMD_RX_EN;
bcmgenet_umac_writel(priv, reg, UMAC_CMD);
+ spin_unlock_bh(&priv->reg_lock);
mdelay(10);
if (priv->wolopts & (WAKE_MAGIC | WAKE_MAGICSECURE)) {
@@ -186,6 +188,7 @@ int bcmgenet_wol_power_down_cfg(struct b
}
/* Enable CRC forward */
+ spin_lock_bh(&priv->reg_lock);
reg = bcmgenet_umac_readl(priv, UMAC_CMD);
priv->crc_fwd_en = 1;
reg |= CMD_CRC_FWD;
@@ -193,6 +196,7 @@ int bcmgenet_wol_power_down_cfg(struct b
/* Receiver must be enabled for WOL MP detection */
reg |= CMD_RX_EN;
bcmgenet_umac_writel(priv, reg, UMAC_CMD);
+ spin_unlock_bh(&priv->reg_lock);
reg = UMAC_IRQ_MPD_R;
if (hfb_enable)
@@ -239,7 +243,9 @@ void bcmgenet_wol_power_up_cfg(struct bc
}
/* Disable CRC Forward */
+ spin_lock_bh(&priv->reg_lock);
reg = bcmgenet_umac_readl(priv, UMAC_CMD);
reg &= ~CMD_CRC_FWD;
bcmgenet_umac_writel(priv, reg, UMAC_CMD);
+ spin_unlock_bh(&priv->reg_lock);
}
--- a/drivers/net/ethernet/broadcom/genet/bcmmii.c
+++ b/drivers/net/ethernet/broadcom/genet/bcmmii.c
@@ -91,6 +91,7 @@ void bcmgenet_mii_setup(struct net_devic
reg |= RGMII_LINK;
bcmgenet_ext_writel(priv, reg, EXT_RGMII_OOB_CTRL);
+ spin_lock_bh(&priv->reg_lock);
reg = bcmgenet_umac_readl(priv, UMAC_CMD);
reg &= ~((CMD_SPEED_MASK << CMD_SPEED_SHIFT) |
CMD_HD_EN |
@@ -103,6 +104,7 @@ void bcmgenet_mii_setup(struct net_devic
reg |= CMD_TX_EN | CMD_RX_EN;
}
bcmgenet_umac_writel(priv, reg, UMAC_CMD);
+ spin_unlock_bh(&priv->reg_lock);
priv->eee.eee_active = phy_init_eee(phydev, 0) >= 0;
bcmgenet_eee_enable_set(dev,
^ permalink raw reply [flat|nested] 22+ messages in thread* [PATCH 5.10 06/15] ima: fix deadlock when traversing "ima_default_rules".
2024-05-23 13:12 [PATCH 5.10 00/15] 5.10.218-rc1 review Greg Kroah-Hartman
` (4 preceding siblings ...)
2024-05-23 13:12 ` [PATCH 5.10 05/15] net: bcmgenet: synchronize UMAC_CMD access Greg Kroah-Hartman
@ 2024-05-23 13:12 ` Greg Kroah-Hartman
2024-05-23 13:12 ` [PATCH 5.10 07/15] netlink: annotate lockless accesses to nlk->max_recvmsg_len Greg Kroah-Hartman
` (14 subsequent siblings)
20 siblings, 0 replies; 22+ messages in thread
From: Greg Kroah-Hartman @ 2024-05-23 13:12 UTC (permalink / raw)
To: stable
Cc: Greg Kroah-Hartman, patches, liqiong, THOBY Simon, Mimi Zohar,
GUO Zihua, kernel test robot
5.10-stable review patch. If anyone has any objections, please let me know.
------------------
From: liqiong <liqiong@nfschina.com>
commit eb0782bbdfd0d7c4786216659277c3fd585afc0e upstream.
The current IMA ruleset is identified by the variable "ima_rules"
that default to "&ima_default_rules". When loading a custom policy
for the first time, the variable is updated to "&ima_policy_rules"
instead. That update isn't RCU-safe, and deadlocks are possible.
Indeed, some functions like ima_match_policy() may loop indefinitely
when traversing "ima_default_rules" with list_for_each_entry_rcu().
When iterating over the default ruleset back to head, if the list
head is "ima_default_rules", and "ima_rules" have been updated to
"&ima_policy_rules", the loop condition (&entry->list != ima_rules)
stays always true, traversing won't terminate, causing a soft lockup
and RCU stalls.
Introduce a temporary value for "ima_rules" when iterating over
the ruleset to avoid the deadlocks.
Signed-off-by: liqiong <liqiong@nfschina.com>
Reviewed-by: THOBY Simon <Simon.THOBY@viveris.fr>
Fixes: 38d859f991f3 ("IMA: policy can now be updated multiple times")
Reported-by: kernel test robot <lkp@intel.com> (Fix sparse: incompatible types in comparison expression.)
Signed-off-by: Mimi Zohar <zohar@linux.ibm.com>
Signed-off-by: GUO Zihua <guozihua@huawei.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
security/integrity/ima/ima_policy.c | 29 ++++++++++++++++++++---------
1 file changed, 20 insertions(+), 9 deletions(-)
--- a/security/integrity/ima/ima_policy.c
+++ b/security/integrity/ima/ima_policy.c
@@ -210,7 +210,7 @@ static struct ima_rule_entry *arch_polic
static LIST_HEAD(ima_default_rules);
static LIST_HEAD(ima_policy_rules);
static LIST_HEAD(ima_temp_rules);
-static struct list_head *ima_rules = &ima_default_rules;
+static struct list_head __rcu *ima_rules = (struct list_head __rcu *)(&ima_default_rules);
static int ima_policy __initdata;
@@ -648,12 +648,14 @@ int ima_match_policy(struct inode *inode
{
struct ima_rule_entry *entry;
int action = 0, actmask = flags | (flags << 1);
+ struct list_head *ima_rules_tmp;
if (template_desc)
*template_desc = ima_template_desc_current();
rcu_read_lock();
- list_for_each_entry_rcu(entry, ima_rules, list) {
+ ima_rules_tmp = rcu_dereference(ima_rules);
+ list_for_each_entry_rcu(entry, ima_rules_tmp, list) {
if (!(entry->action & actmask))
continue;
@@ -701,11 +703,15 @@ int ima_match_policy(struct inode *inode
void ima_update_policy_flag(void)
{
struct ima_rule_entry *entry;
+ struct list_head *ima_rules_tmp;
- list_for_each_entry(entry, ima_rules, list) {
+ rcu_read_lock();
+ ima_rules_tmp = rcu_dereference(ima_rules);
+ list_for_each_entry_rcu(entry, ima_rules_tmp, list) {
if (entry->action & IMA_DO_MASK)
ima_policy_flag |= entry->action;
}
+ rcu_read_unlock();
ima_appraise |= (build_ima_appraise | temp_ima_appraise);
if (!ima_appraise)
@@ -898,10 +904,10 @@ void ima_update_policy(void)
list_splice_tail_init_rcu(&ima_temp_rules, policy, synchronize_rcu);
- if (ima_rules != policy) {
+ if (ima_rules != (struct list_head __rcu *)policy) {
ima_policy_flag = 0;
- ima_rules = policy;
+ rcu_assign_pointer(ima_rules, policy);
/*
* IMA architecture specific policy rules are specified
* as strings and converted to an array of ima_entry_rules
@@ -989,7 +995,7 @@ static int ima_lsm_rule_init(struct ima_
pr_warn("rule for LSM \'%s\' is undefined\n",
entry->lsm[lsm_rule].args_p);
- if (ima_rules == &ima_default_rules) {
+ if (ima_rules == (struct list_head __rcu *)(&ima_default_rules)) {
kfree(entry->lsm[lsm_rule].args_p);
entry->lsm[lsm_rule].args_p = NULL;
result = -EINVAL;
@@ -1598,9 +1604,11 @@ void *ima_policy_start(struct seq_file *
{
loff_t l = *pos;
struct ima_rule_entry *entry;
+ struct list_head *ima_rules_tmp;
rcu_read_lock();
- list_for_each_entry_rcu(entry, ima_rules, list) {
+ ima_rules_tmp = rcu_dereference(ima_rules);
+ list_for_each_entry_rcu(entry, ima_rules_tmp, list) {
if (!l--) {
rcu_read_unlock();
return entry;
@@ -1619,7 +1627,8 @@ void *ima_policy_next(struct seq_file *m
rcu_read_unlock();
(*pos)++;
- return (&entry->list == ima_rules) ? NULL : entry;
+ return (&entry->list == &ima_default_rules ||
+ &entry->list == &ima_policy_rules) ? NULL : entry;
}
void ima_policy_stop(struct seq_file *m, void *v)
@@ -1823,6 +1832,7 @@ bool ima_appraise_signature(enum kernel_
struct ima_rule_entry *entry;
bool found = false;
enum ima_hooks func;
+ struct list_head *ima_rules_tmp;
if (id >= READING_MAX_ID)
return false;
@@ -1834,7 +1844,8 @@ bool ima_appraise_signature(enum kernel_
func = read_idmap[id] ?: FILE_CHECK;
rcu_read_lock();
- list_for_each_entry_rcu(entry, ima_rules, list) {
+ ima_rules_tmp = rcu_dereference(ima_rules);
+ list_for_each_entry_rcu(entry, ima_rules_tmp, list) {
if (entry->action != APPRAISE)
continue;
^ permalink raw reply [flat|nested] 22+ messages in thread* [PATCH 5.10 07/15] netlink: annotate lockless accesses to nlk->max_recvmsg_len
2024-05-23 13:12 [PATCH 5.10 00/15] 5.10.218-rc1 review Greg Kroah-Hartman
` (5 preceding siblings ...)
2024-05-23 13:12 ` [PATCH 5.10 06/15] ima: fix deadlock when traversing "ima_default_rules" Greg Kroah-Hartman
@ 2024-05-23 13:12 ` Greg Kroah-Hartman
2024-05-23 13:12 ` [PATCH 5.10 08/15] KVM: x86: Clear "has_error_code", not "error_code", for RM exception injection Greg Kroah-Hartman
` (13 subsequent siblings)
20 siblings, 0 replies; 22+ messages in thread
From: Greg Kroah-Hartman @ 2024-05-23 13:12 UTC (permalink / raw)
To: stable
Cc: Greg Kroah-Hartman, patches, syzbot, Eric Dumazet, Simon Horman,
Jakub Kicinski, yenchia.chen
5.10-stable review patch. If anyone has any objections, please let me know.
------------------
From: Eric Dumazet <edumazet@google.com>
commit a1865f2e7d10dde00d35a2122b38d2e469ae67ed upstream.
syzbot reported a data-race in data-race in netlink_recvmsg() [1]
Indeed, netlink_recvmsg() can be run concurrently,
and netlink_dump() also needs protection.
[1]
BUG: KCSAN: data-race in netlink_recvmsg / netlink_recvmsg
read to 0xffff888141840b38 of 8 bytes by task 23057 on cpu 0:
netlink_recvmsg+0xea/0x730 net/netlink/af_netlink.c:1988
sock_recvmsg_nosec net/socket.c:1017 [inline]
sock_recvmsg net/socket.c:1038 [inline]
__sys_recvfrom+0x1ee/0x2e0 net/socket.c:2194
__do_sys_recvfrom net/socket.c:2212 [inline]
__se_sys_recvfrom net/socket.c:2208 [inline]
__x64_sys_recvfrom+0x78/0x90 net/socket.c:2208
do_syscall_x64 arch/x86/entry/common.c:50 [inline]
do_syscall_64+0x41/0xc0 arch/x86/entry/common.c:80
entry_SYSCALL_64_after_hwframe+0x63/0xcd
write to 0xffff888141840b38 of 8 bytes by task 23037 on cpu 1:
netlink_recvmsg+0x114/0x730 net/netlink/af_netlink.c:1989
sock_recvmsg_nosec net/socket.c:1017 [inline]
sock_recvmsg net/socket.c:1038 [inline]
____sys_recvmsg+0x156/0x310 net/socket.c:2720
___sys_recvmsg net/socket.c:2762 [inline]
do_recvmmsg+0x2e5/0x710 net/socket.c:2856
__sys_recvmmsg net/socket.c:2935 [inline]
__do_sys_recvmmsg net/socket.c:2958 [inline]
__se_sys_recvmmsg net/socket.c:2951 [inline]
__x64_sys_recvmmsg+0xe2/0x160 net/socket.c:2951
do_syscall_x64 arch/x86/entry/common.c:50 [inline]
do_syscall_64+0x41/0xc0 arch/x86/entry/common.c:80
entry_SYSCALL_64_after_hwframe+0x63/0xcd
value changed: 0x0000000000000000 -> 0x0000000000001000
Reported by Kernel Concurrency Sanitizer on:
CPU: 1 PID: 23037 Comm: syz-executor.2 Not tainted 6.3.0-rc4-syzkaller-00195-g5a57b48fdfcb #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 03/02/2023
Fixes: 9063e21fb026 ("netlink: autosize skb lengthes")
Reported-by: syzbot <syzkaller@googlegroups.com>
Signed-off-by: Eric Dumazet <edumazet@google.com>
Reviewed-by: Simon Horman <simon.horman@corigine.com>
Link: https://lore.kernel.org/r/20230403214643.768555-1-edumazet@google.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Signed-off-by: yenchia.chen <yenchia.chen@mediatek.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
net/netlink/af_netlink.c | 15 +++++++++------
1 file changed, 9 insertions(+), 6 deletions(-)
--- a/net/netlink/af_netlink.c
+++ b/net/netlink/af_netlink.c
@@ -1927,7 +1927,7 @@ static int netlink_recvmsg(struct socket
struct sock *sk = sock->sk;
struct netlink_sock *nlk = nlk_sk(sk);
int noblock = flags & MSG_DONTWAIT;
- size_t copied;
+ size_t copied, max_recvmsg_len;
struct sk_buff *skb, *data_skb;
int err, ret;
@@ -1960,9 +1960,10 @@ static int netlink_recvmsg(struct socket
#endif
/* Record the max length of recvmsg() calls for future allocations */
- nlk->max_recvmsg_len = max(nlk->max_recvmsg_len, len);
- nlk->max_recvmsg_len = min_t(size_t, nlk->max_recvmsg_len,
- SKB_WITH_OVERHEAD(32768));
+ max_recvmsg_len = max(READ_ONCE(nlk->max_recvmsg_len), len);
+ max_recvmsg_len = min_t(size_t, max_recvmsg_len,
+ SKB_WITH_OVERHEAD(32768));
+ WRITE_ONCE(nlk->max_recvmsg_len, max_recvmsg_len);
copied = data_skb->len;
if (len < copied) {
@@ -2211,6 +2212,7 @@ static int netlink_dump(struct sock *sk)
struct netlink_ext_ack extack = {};
struct netlink_callback *cb;
struct sk_buff *skb = NULL;
+ size_t max_recvmsg_len;
struct module *module;
int err = -ENOBUFS;
int alloc_min_size;
@@ -2233,8 +2235,9 @@ static int netlink_dump(struct sock *sk)
cb = &nlk->cb;
alloc_min_size = max_t(int, cb->min_dump_alloc, NLMSG_GOODSIZE);
- if (alloc_min_size < nlk->max_recvmsg_len) {
- alloc_size = nlk->max_recvmsg_len;
+ max_recvmsg_len = READ_ONCE(nlk->max_recvmsg_len);
+ if (alloc_min_size < max_recvmsg_len) {
+ alloc_size = max_recvmsg_len;
skb = alloc_skb(alloc_size,
(GFP_KERNEL & ~__GFP_DIRECT_RECLAIM) |
__GFP_NOWARN | __GFP_NORETRY);
^ permalink raw reply [flat|nested] 22+ messages in thread* [PATCH 5.10 08/15] KVM: x86: Clear "has_error_code", not "error_code", for RM exception injection
2024-05-23 13:12 [PATCH 5.10 00/15] 5.10.218-rc1 review Greg Kroah-Hartman
` (6 preceding siblings ...)
2024-05-23 13:12 ` [PATCH 5.10 07/15] netlink: annotate lockless accesses to nlk->max_recvmsg_len Greg Kroah-Hartman
@ 2024-05-23 13:12 ` Greg Kroah-Hartman
2024-05-23 13:12 ` [PATCH 5.10 09/15] firmware: arm_scmi: Harden accesses to the reset domains Greg Kroah-Hartman
` (12 subsequent siblings)
20 siblings, 0 replies; 22+ messages in thread
From: Greg Kroah-Hartman @ 2024-05-23 13:12 UTC (permalink / raw)
To: stable
Cc: Greg Kroah-Hartman, patches, Maxim Levitsky, Sean Christopherson,
Paolo Bonzini, Nicolas Saenz Julienne
5.10-stable review patch. If anyone has any objections, please let me know.
------------------
From: Sean Christopherson <seanjc@google.com>
commit 6c41468c7c12d74843bb414fc00307ea8a6318c3 upstream.
When injecting an exception into a vCPU in Real Mode, suppress the error
code by clearing the flag that tracks whether the error code is valid, not
by clearing the error code itself. The "typo" was introduced by recent
fix for SVM's funky Paged Real Mode.
Opportunistically hoist the logic above the tracepoint so that the trace
is coherent with respect to what is actually injected (this was also the
behavior prior to the buggy commit).
Fixes: b97f07458373 ("KVM: x86: determine if an exception has an error code only when injecting it.")
Cc: stable@vger.kernel.org
Cc: Maxim Levitsky <mlevitsk@redhat.com>
Signed-off-by: Sean Christopherson <seanjc@google.com>
Message-Id: <20230322143300.2209476-2-seanjc@google.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
[nsaenz: backport to 5.10.y]
Signed-off-by: Nicolas Saenz Julienne <nsaenz@amazon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Acked-by: Sean Christopherson <seanjc@google.com>
---
arch/x86/kvm/x86.c | 11 +++++++++--
1 file changed, 9 insertions(+), 2 deletions(-)
--- a/arch/x86/kvm/x86.c
+++ b/arch/x86/kvm/x86.c
@@ -8501,13 +8501,20 @@ static void update_cr8_intercept(struct
static void kvm_inject_exception(struct kvm_vcpu *vcpu)
{
+ /*
+ * Suppress the error code if the vCPU is in Real Mode, as Real Mode
+ * exceptions don't report error codes. The presence of an error code
+ * is carried with the exception and only stripped when the exception
+ * is injected as intercepted #PF VM-Exits for AMD's Paged Real Mode do
+ * report an error code despite the CPU being in Real Mode.
+ */
+ vcpu->arch.exception.has_error_code &= is_protmode(vcpu);
+
trace_kvm_inj_exception(vcpu->arch.exception.nr,
vcpu->arch.exception.has_error_code,
vcpu->arch.exception.error_code,
vcpu->arch.exception.injected);
- if (vcpu->arch.exception.error_code && !is_protmode(vcpu))
- vcpu->arch.exception.error_code = false;
kvm_x86_ops.queue_exception(vcpu);
}
^ permalink raw reply [flat|nested] 22+ messages in thread* [PATCH 5.10 09/15] firmware: arm_scmi: Harden accesses to the reset domains
2024-05-23 13:12 [PATCH 5.10 00/15] 5.10.218-rc1 review Greg Kroah-Hartman
` (7 preceding siblings ...)
2024-05-23 13:12 ` [PATCH 5.10 08/15] KVM: x86: Clear "has_error_code", not "error_code", for RM exception injection Greg Kroah-Hartman
@ 2024-05-23 13:12 ` Greg Kroah-Hartman
2024-05-23 13:12 ` [PATCH 5.10 10/15] mptcp: ensure snd_nxt is properly initialized on connect Greg Kroah-Hartman
` (11 subsequent siblings)
20 siblings, 0 replies; 22+ messages in thread
From: Greg Kroah-Hartman @ 2024-05-23 13:12 UTC (permalink / raw)
To: stable
Cc: Greg Kroah-Hartman, patches, Cristian Marussi, Sudeep Holla,
Dominique Martinet
5.10-stable review patch. If anyone has any objections, please let me know.
------------------
From: Cristian Marussi <cristian.marussi@arm.com>
commit e9076ffbcaed5da6c182b144ef9f6e24554af268 upstream.
Accessing reset domains descriptors by the index upon the SCMI drivers
requests through the SCMI reset operations interface can potentially
lead to out-of-bound violations if the SCMI driver misbehave.
Add an internal consistency check before any such domains descriptors
accesses.
Link: https://lore.kernel.org/r/20220817172731.1185305-5-cristian.marussi@arm.com
Signed-off-by: Cristian Marussi <cristian.marussi@arm.com>
Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
Signed-off-by: Dominique Martinet <dominique.martinet@atmark-techno.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/firmware/arm_scmi/reset.c | 6 +++++-
1 file changed, 5 insertions(+), 1 deletion(-)
--- a/drivers/firmware/arm_scmi/reset.c
+++ b/drivers/firmware/arm_scmi/reset.c
@@ -149,8 +149,12 @@ static int scmi_domain_reset(const struc
struct scmi_xfer *t;
struct scmi_msg_reset_domain_reset *dom;
struct scmi_reset_info *pi = handle->reset_priv;
- struct reset_dom_info *rdom = pi->dom_info + domain;
+ struct reset_dom_info *rdom;
+ if (domain >= pi->num_domains)
+ return -EINVAL;
+
+ rdom = pi->dom_info + domain;
if (rdom->async_reset)
flags |= ASYNCHRONOUS_RESET;
^ permalink raw reply [flat|nested] 22+ messages in thread* [PATCH 5.10 10/15] mptcp: ensure snd_nxt is properly initialized on connect
2024-05-23 13:12 [PATCH 5.10 00/15] 5.10.218-rc1 review Greg Kroah-Hartman
` (8 preceding siblings ...)
2024-05-23 13:12 ` [PATCH 5.10 09/15] firmware: arm_scmi: Harden accesses to the reset domains Greg Kroah-Hartman
@ 2024-05-23 13:12 ` Greg Kroah-Hartman
2024-05-23 13:12 ` [PATCH 5.10 11/15] btrfs: add missing mutex_unlock in btrfs_relocate_sys_chunks() Greg Kroah-Hartman
` (10 subsequent siblings)
20 siblings, 0 replies; 22+ messages in thread
From: Greg Kroah-Hartman @ 2024-05-23 13:12 UTC (permalink / raw)
To: stable
Cc: Greg Kroah-Hartman, patches, Christoph Paasch, Paolo Abeni,
Mat Martineau, Matthieu Baerts (NGI0), Jakub Kicinski
5.10-stable review patch. If anyone has any objections, please let me know.
------------------
From: Paolo Abeni <pabeni@redhat.com>
commit fb7a0d334894206ae35f023a82cad5a290fd7386 upstream.
Christoph reported a splat hinting at a corrupted snd_una:
WARNING: CPU: 1 PID: 38 at net/mptcp/protocol.c:1005 __mptcp_clean_una+0x4b3/0x620 net/mptcp/protocol.c:1005
Modules linked in:
CPU: 1 PID: 38 Comm: kworker/1:1 Not tainted 6.9.0-rc1-gbbeac67456c9 #59
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.11.0-2.el7 04/01/2014
Workqueue: events mptcp_worker
RIP: 0010:__mptcp_clean_una+0x4b3/0x620 net/mptcp/protocol.c:1005
Code: be 06 01 00 00 bf 06 01 00 00 e8 a8 12 e7 fe e9 00 fe ff ff e8
8e 1a e7 fe 0f b7 ab 3e 02 00 00 e9 d3 fd ff ff e8 7d 1a e7 fe
<0f> 0b 4c 8b bb e0 05 00 00 e9 74 fc ff ff e8 6a 1a e7 fe 0f 0b e9
RSP: 0018:ffffc9000013fd48 EFLAGS: 00010293
RAX: 0000000000000000 RBX: ffff8881029bd280 RCX: ffffffff82382fe4
RDX: ffff8881003cbd00 RSI: ffffffff823833c3 RDI: 0000000000000001
RBP: 0000000000000000 R08: 0000000000000001 R09: 0000000000000000
R10: 0000000000000000 R11: fefefefefefefeff R12: ffff888138ba8000
R13: 0000000000000106 R14: ffff8881029bd908 R15: ffff888126560000
FS: 0000000000000000(0000) GS:ffff88813bd00000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00007f604a5dae38 CR3: 0000000101dac002 CR4: 0000000000170ef0
Call Trace:
<TASK>
__mptcp_clean_una_wakeup net/mptcp/protocol.c:1055 [inline]
mptcp_clean_una_wakeup net/mptcp/protocol.c:1062 [inline]
__mptcp_retrans+0x7f/0x7e0 net/mptcp/protocol.c:2615
mptcp_worker+0x434/0x740 net/mptcp/protocol.c:2767
process_one_work+0x1e0/0x560 kernel/workqueue.c:3254
process_scheduled_works kernel/workqueue.c:3335 [inline]
worker_thread+0x3c7/0x640 kernel/workqueue.c:3416
kthread+0x121/0x170 kernel/kthread.c:388
ret_from_fork+0x44/0x50 arch/x86/kernel/process.c:147
ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:243
</TASK>
When fallback to TCP happens early on a client socket, snd_nxt
is not yet initialized and any incoming ack will copy such value
into snd_una. If the mptcp worker (dumbly) tries mptcp-level
re-injection after such ack, that would unconditionally trigger a send
buffer cleanup using 'bad' snd_una values.
We could easily disable re-injection for fallback sockets, but such
dumb behavior already helped catching a few subtle issues and a very
low to zero impact in practice.
Instead address the issue always initializing snd_nxt (and write_seq,
for consistency) at connect time.
Fixes: 8fd738049ac3 ("mptcp: fallback in case of simultaneous connect")
Cc: stable@vger.kernel.org
Reported-by: Christoph Paasch <cpaasch@apple.com>
Closes: https://github.com/multipath-tcp/mptcp_net-next/issues/485
Tested-by: Christoph Paasch <cpaasch@apple.com>
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
Reviewed-by: Mat Martineau <martineau@kernel.org>
Signed-off-by: Matthieu Baerts (NGI0) <matttbe@kernel.org>
Link: https://lore.kernel.org/r/20240429-upstream-net-20240429-mptcp-snd_nxt-init-connect-v1-1-59ceac0a7dcb@kernel.org
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
[ snd_nxt field is not available in v5.10.y: before, only write_seq was
used, see commit eaa2ffabfc35 ("mptcp: introduce MPTCP snd_nxt") for
more details about that. ]
Signed-off-by: Matthieu Baerts (NGI0) <matttbe@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
net/mptcp/protocol.c | 2 ++
1 file changed, 2 insertions(+)
--- a/net/mptcp/protocol.c
+++ b/net/mptcp/protocol.c
@@ -2645,6 +2645,8 @@ static int mptcp_stream_connect(struct s
if (subflow->request_mptcp && mptcp_token_new_connect(ssock->sk))
mptcp_subflow_early_fallback(msk, subflow);
+ WRITE_ONCE(msk->write_seq, subflow->idsn);
+
do_connect:
err = ssock->ops->connect(ssock, uaddr, addr_len, flags);
sock->state = ssock->state;
^ permalink raw reply [flat|nested] 22+ messages in thread* [PATCH 5.10 11/15] btrfs: add missing mutex_unlock in btrfs_relocate_sys_chunks()
2024-05-23 13:12 [PATCH 5.10 00/15] 5.10.218-rc1 review Greg Kroah-Hartman
` (9 preceding siblings ...)
2024-05-23 13:12 ` [PATCH 5.10 10/15] mptcp: ensure snd_nxt is properly initialized on connect Greg Kroah-Hartman
@ 2024-05-23 13:12 ` Greg Kroah-Hartman
2024-05-23 13:12 ` [PATCH 5.10 12/15] drm/amdgpu: Fix possible NULL dereference in amdgpu_ras_query_error_status_helper() Greg Kroah-Hartman
` (9 subsequent siblings)
20 siblings, 0 replies; 22+ messages in thread
From: Greg Kroah-Hartman @ 2024-05-23 13:12 UTC (permalink / raw)
To: stable
Cc: Greg Kroah-Hartman, patches, Pavel Machek, Dominique Martinet,
David Sterba
5.10-stable review patch. If anyone has any objections, please let me know.
------------------
From: Dominique Martinet <dominique.martinet@atmark-techno.com>
commit 9af503d91298c3f2945e73703f0e00995be08c30 upstream.
The previous patch that replaced BUG_ON by error handling forgot to
unlock the mutex in the error path.
Link: https://lore.kernel.org/all/Zh%2fHpAGFqa7YAFuM@duo.ucw.cz
Reported-by: Pavel Machek <pavel@denx.de>
Fixes: 7411055db5ce ("btrfs: handle chunk tree lookup error in btrfs_relocate_sys_chunks()")
CC: stable@vger.kernel.org
Reviewed-by: Pavel Machek <pavel@denx.de>
Signed-off-by: Dominique Martinet <dominique.martinet@atmark-techno.com>
Reviewed-by: David Sterba <dsterba@suse.com>
Signed-off-by: David Sterba <dsterba@suse.com>
Signed-off-by: Dominique Martinet <dominique.martinet@atmark-techno.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
fs/btrfs/volumes.c | 1 +
1 file changed, 1 insertion(+)
--- a/fs/btrfs/volumes.c
+++ b/fs/btrfs/volumes.c
@@ -3194,6 +3194,7 @@ again:
* alignment and size).
*/
ret = -EUCLEAN;
+ mutex_unlock(&fs_info->delete_unused_bgs_mutex);
goto error;
}
^ permalink raw reply [flat|nested] 22+ messages in thread* [PATCH 5.10 12/15] drm/amdgpu: Fix possible NULL dereference in amdgpu_ras_query_error_status_helper()
2024-05-23 13:12 [PATCH 5.10 00/15] 5.10.218-rc1 review Greg Kroah-Hartman
` (10 preceding siblings ...)
2024-05-23 13:12 ` [PATCH 5.10 11/15] btrfs: add missing mutex_unlock in btrfs_relocate_sys_chunks() Greg Kroah-Hartman
@ 2024-05-23 13:12 ` Greg Kroah-Hartman
2024-05-23 13:12 ` [PATCH 5.10 13/15] usb: typec: ucsi: displayport: Fix potential deadlock Greg Kroah-Hartman
` (8 subsequent siblings)
20 siblings, 0 replies; 22+ messages in thread
From: Greg Kroah-Hartman @ 2024-05-23 13:12 UTC (permalink / raw)
To: stable
Cc: Greg Kroah-Hartman, patches, Hawking Zhang, Tao Zhou,
Christian König, Alex Deucher, Srinivasan Shanmugam,
Ajay Kaher
5.10-stable review patch. If anyone has any objections, please let me know.
------------------
From: Srinivasan Shanmugam <srinivasan.shanmugam@amd.com>
commit b8d55a90fd55b767c25687747e2b24abd1ef8680 upstream.
Return invalid error code -EINVAL for invalid block id.
Fixes the below:
drivers/gpu/drm/amd/amdgpu/amdgpu_ras.c:1183 amdgpu_ras_query_error_status_helper() error: we previously assumed 'info' could be null (see line 1176)
Suggested-by: Hawking Zhang <Hawking.Zhang@amd.com>
Cc: Tao Zhou <tao.zhou1@amd.com>
Cc: Hawking Zhang <Hawking.Zhang@amd.com>
Cc: Christian König <christian.koenig@amd.com>
Cc: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Srinivasan Shanmugam <srinivasan.shanmugam@amd.com>
Reviewed-by: Hawking Zhang <Hawking.Zhang@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
[Ajay: applied AMDGPU_RAS_BLOCK_COUNT condition to amdgpu_ras_error_query()
as amdgpu_ras_query_error_status_helper() not present in v5.10, v5.4
amdgpu_ras_query_error_status_helper() was introduced in 8cc0f5669eb6]
Signed-off-by: Ajay Kaher <ajay.kaher@broadcom.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/gpu/drm/amd/amdgpu/amdgpu_ras.c | 3 +++
1 file changed, 3 insertions(+)
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ras.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ras.c
@@ -765,6 +765,9 @@ int amdgpu_ras_error_query(struct amdgpu
if (!obj)
return -EINVAL;
+ if (!info || info->head.block == AMDGPU_RAS_BLOCK_COUNT)
+ return -EINVAL;
+
switch (info->head.block) {
case AMDGPU_RAS_BLOCK__UMC:
if (adev->umc.funcs->query_ras_error_count)
^ permalink raw reply [flat|nested] 22+ messages in thread* [PATCH 5.10 13/15] usb: typec: ucsi: displayport: Fix potential deadlock
2024-05-23 13:12 [PATCH 5.10 00/15] 5.10.218-rc1 review Greg Kroah-Hartman
` (11 preceding siblings ...)
2024-05-23 13:12 ` [PATCH 5.10 12/15] drm/amdgpu: Fix possible NULL dereference in amdgpu_ras_query_error_status_helper() Greg Kroah-Hartman
@ 2024-05-23 13:12 ` Greg Kroah-Hartman
2024-05-23 13:12 ` [PATCH 5.10 14/15] serial: kgdboc: Fix NMI-safety problems from keyboard reset code Greg Kroah-Hartman
` (7 subsequent siblings)
20 siblings, 0 replies; 22+ messages in thread
From: Greg Kroah-Hartman @ 2024-05-23 13:12 UTC (permalink / raw)
To: stable; +Cc: Greg Kroah-Hartman, patches, Mathias Nyman, Heikki Krogerus
5.10-stable review patch. If anyone has any objections, please let me know.
------------------
From: Heikki Krogerus <heikki.krogerus@linux.intel.com>
commit b791a67f68121d69108640d4a3e591d210ffe850 upstream.
The function ucsi_displayport_work() does not access the
connector, so it also must not acquire the connector lock.
This fixes a potential deadlock scenario:
ucsi_displayport_work() -> lock(&con->lock)
typec_altmode_vdm()
dp_altmode_vdm()
dp_altmode_work()
typec_altmode_enter()
ucsi_displayport_enter() -> lock(&con->lock)
Reported-by: Mathias Nyman <mathias.nyman@linux.intel.com>
Fixes: af8622f6a585 ("usb: typec: ucsi: Support for DisplayPort alt mode")
Cc: stable@vger.kernel.org
Signed-off-by: Heikki Krogerus <heikki.krogerus@linux.intel.com>
Link: https://lore.kernel.org/r/20240507134316.161999-1-heikki.krogerus@linux.intel.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/usb/typec/ucsi/displayport.c | 4 ----
1 file changed, 4 deletions(-)
--- a/drivers/usb/typec/ucsi/displayport.c
+++ b/drivers/usb/typec/ucsi/displayport.c
@@ -249,8 +249,6 @@ static void ucsi_displayport_work(struct
struct ucsi_dp *dp = container_of(work, struct ucsi_dp, work);
int ret;
- mutex_lock(&dp->con->lock);
-
ret = typec_altmode_vdm(dp->alt, dp->header,
dp->vdo_data, dp->vdo_size);
if (ret)
@@ -259,8 +257,6 @@ static void ucsi_displayport_work(struct
dp->vdo_data = NULL;
dp->vdo_size = 0;
dp->header = 0;
-
- mutex_unlock(&dp->con->lock);
}
void ucsi_displayport_remove_partner(struct typec_altmode *alt)
^ permalink raw reply [flat|nested] 22+ messages in thread* [PATCH 5.10 14/15] serial: kgdboc: Fix NMI-safety problems from keyboard reset code
2024-05-23 13:12 [PATCH 5.10 00/15] 5.10.218-rc1 review Greg Kroah-Hartman
` (12 preceding siblings ...)
2024-05-23 13:12 ` [PATCH 5.10 13/15] usb: typec: ucsi: displayport: Fix potential deadlock Greg Kroah-Hartman
@ 2024-05-23 13:12 ` Greg Kroah-Hartman
2024-05-23 13:12 ` [PATCH 5.10 15/15] docs: kernel_include.py: Cope with docutils 0.21 Greg Kroah-Hartman
` (6 subsequent siblings)
20 siblings, 0 replies; 22+ messages in thread
From: Greg Kroah-Hartman @ 2024-05-23 13:12 UTC (permalink / raw)
To: stable
Cc: Greg Kroah-Hartman, patches, Liuye, Douglas Anderson,
Daniel Thompson
5.10-stable review patch. If anyone has any objections, please let me know.
------------------
From: Daniel Thompson <daniel.thompson@linaro.org>
commit b2aba15ad6f908d1a620fd97f6af5620c3639742 upstream.
Currently, when kdb is compiled with keyboard support, then we will use
schedule_work() to provoke reset of the keyboard status. Unfortunately
schedule_work() gets called from the kgdboc post-debug-exception
handler. That risks deadlock since schedule_work() is not NMI-safe and,
even on platforms where the NMI is not directly used for debugging, the
debug trap can have NMI-like behaviour depending on where breakpoints
are placed.
Fix this by using the irq work system, which is NMI-safe, to defer the
call to schedule_work() to a point when it is safe to call.
Reported-by: Liuye <liu.yeC@h3c.com>
Closes: https://lore.kernel.org/all/20240228025602.3087748-1-liu.yeC@h3c.com/
Cc: stable@vger.kernel.org
Reviewed-by: Douglas Anderson <dianders@chromium.org>
Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Link: https://lore.kernel.org/r/20240424-kgdboc_fix_schedule_work-v2-1-50f5a490aec5@linaro.org
Signed-off-by: Daniel Thompson <daniel.thompson@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/tty/serial/kgdboc.c | 30 +++++++++++++++++++++++++++++-
1 file changed, 29 insertions(+), 1 deletion(-)
--- a/drivers/tty/serial/kgdboc.c
+++ b/drivers/tty/serial/kgdboc.c
@@ -19,6 +19,7 @@
#include <linux/console.h>
#include <linux/vt_kern.h>
#include <linux/input.h>
+#include <linux/irq_work.h>
#include <linux/module.h>
#include <linux/platform_device.h>
#include <linux/serial_core.h>
@@ -48,6 +49,25 @@ static struct kgdb_io kgdboc_earlycon_i
static int (*earlycon_orig_exit)(struct console *con);
#endif /* IS_BUILTIN(CONFIG_KGDB_SERIAL_CONSOLE) */
+/*
+ * When we leave the debug trap handler we need to reset the keyboard status
+ * (since the original keyboard state gets partially clobbered by kdb use of
+ * the keyboard).
+ *
+ * The path to deliver the reset is somewhat circuitous.
+ *
+ * To deliver the reset we register an input handler, reset the keyboard and
+ * then deregister the input handler. However, to get this done right, we do
+ * have to carefully manage the calling context because we can only register
+ * input handlers from task context.
+ *
+ * In particular we need to trigger the action from the debug trap handler with
+ * all its NMI and/or NMI-like oddities. To solve this the kgdboc trap exit code
+ * (the "post_exception" callback) uses irq_work_queue(), which is NMI-safe, to
+ * schedule a callback from a hardirq context. From there we have to defer the
+ * work again, this time using schedule_work(), to get a callback using the
+ * system workqueue, which runs in task context.
+ */
#ifdef CONFIG_KDB_KEYBOARD
static int kgdboc_reset_connect(struct input_handler *handler,
struct input_dev *dev,
@@ -99,10 +119,17 @@ static void kgdboc_restore_input_helper(
static DECLARE_WORK(kgdboc_restore_input_work, kgdboc_restore_input_helper);
+static void kgdboc_queue_restore_input_helper(struct irq_work *unused)
+{
+ schedule_work(&kgdboc_restore_input_work);
+}
+
+static DEFINE_IRQ_WORK(kgdboc_restore_input_irq_work, kgdboc_queue_restore_input_helper);
+
static void kgdboc_restore_input(void)
{
if (likely(system_state == SYSTEM_RUNNING))
- schedule_work(&kgdboc_restore_input_work);
+ irq_work_queue(&kgdboc_restore_input_irq_work);
}
static int kgdboc_register_kbd(char **cptr)
@@ -133,6 +160,7 @@ static void kgdboc_unregister_kbd(void)
i--;
}
}
+ irq_work_sync(&kgdboc_restore_input_irq_work);
flush_work(&kgdboc_restore_input_work);
}
#else /* ! CONFIG_KDB_KEYBOARD */
^ permalink raw reply [flat|nested] 22+ messages in thread* [PATCH 5.10 15/15] docs: kernel_include.py: Cope with docutils 0.21
2024-05-23 13:12 [PATCH 5.10 00/15] 5.10.218-rc1 review Greg Kroah-Hartman
` (13 preceding siblings ...)
2024-05-23 13:12 ` [PATCH 5.10 14/15] serial: kgdboc: Fix NMI-safety problems from keyboard reset code Greg Kroah-Hartman
@ 2024-05-23 13:12 ` Greg Kroah-Hartman
2024-05-23 18:20 ` [PATCH 5.10 00/15] 5.10.218-rc1 review Mark Brown
` (5 subsequent siblings)
20 siblings, 0 replies; 22+ messages in thread
From: Greg Kroah-Hartman @ 2024-05-23 13:12 UTC (permalink / raw)
To: stable; +Cc: Greg Kroah-Hartman, patches, Akira Yokosawa, Jonathan Corbet
5.10-stable review patch. If anyone has any objections, please let me know.
------------------
From: Akira Yokosawa <akiyks@gmail.com>
commit d43ddd5c91802a46354fa4c4381416ef760676e2 upstream.
Running "make htmldocs" on a newly installed Sphinx 7.3.7 ends up in
a build error:
Sphinx parallel build error:
AttributeError: module 'docutils.nodes' has no attribute 'reprunicode'
docutils 0.21 has removed nodes.reprunicode, quote from release note [1]:
* Removed objects:
docutils.nodes.reprunicode, docutils.nodes.ensure_str()
Python 2 compatibility hacks
Sphinx 7.3.0 supports docutils 0.21 [2]:
kernel_include.py, whose origin is misc.py of docutils, uses reprunicode.
Upstream docutils removed the offending line from the corresponding file
(docutils/docutils/parsers/rst/directives/misc.py) in January 2022.
Quoting the changelog [3]:
Deprecate `nodes.reprunicode` and `nodes.ensure_str()`.
Drop uses of the deprecated constructs (not required with Python 3).
Do the same for kernel_include.py.
Tested against:
- Sphinx 2.4.5 (docutils 0.17.1)
- Sphinx 3.4.3 (docutils 0.17.1)
- Sphinx 5.3.0 (docutils 0.18.1)
- Sphinx 6.2.1 (docutils 0.19)
- Sphinx 7.2.6 (docutils 0.20.1)
- Sphinx 7.3.7 (docutils 0.21.2)
Link: http://www.docutils.org/RELEASE-NOTES.html#release-0-21-2024-04-09 [1]
Link: https://www.sphinx-doc.org/en/master/changes.html#release-7-3-0-released-apr-16-2024 [2]
Link: https://github.com/docutils/docutils/commit/c8471ce47a24 [3]
Signed-off-by: Akira Yokosawa <akiyks@gmail.com>
Cc: stable@vger.kernel.org
Signed-off-by: Jonathan Corbet <corbet@lwn.net>
Link: https://lore.kernel.org/r/faf5fa45-2a9d-4573-9d2e-3930bdc1ed65@gmail.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
Documentation/sphinx/kernel_include.py | 1 -
1 file changed, 1 deletion(-)
--- a/Documentation/sphinx/kernel_include.py
+++ b/Documentation/sphinx/kernel_include.py
@@ -94,7 +94,6 @@ class KernelInclude(Include):
# HINT: this is the only line I had to change / commented out:
#path = utils.relative_path(None, path)
- path = nodes.reprunicode(path)
encoding = self.options.get(
'encoding', self.state.document.settings.input_encoding)
e_handler=self.state.document.settings.input_encoding_error_handler
^ permalink raw reply [flat|nested] 22+ messages in thread* Re: [PATCH 5.10 00/15] 5.10.218-rc1 review
2024-05-23 13:12 [PATCH 5.10 00/15] 5.10.218-rc1 review Greg Kroah-Hartman
` (14 preceding siblings ...)
2024-05-23 13:12 ` [PATCH 5.10 15/15] docs: kernel_include.py: Cope with docutils 0.21 Greg Kroah-Hartman
@ 2024-05-23 18:20 ` Mark Brown
2024-05-23 18:35 ` Florian Fainelli
` (4 subsequent siblings)
20 siblings, 0 replies; 22+ messages in thread
From: Mark Brown @ 2024-05-23 18:20 UTC (permalink / raw)
To: Greg Kroah-Hartman
Cc: stable, patches, linux-kernel, torvalds, akpm, linux, shuah,
patches, lkft-triage, pavel, jonathanh, f.fainelli,
sudipm.mukherjee, srw, rwarsow, conor, allen.lkml
[-- Attachment #1: Type: text/plain, Size: 346 bytes --]
On Thu, May 23, 2024 at 03:12:42PM +0200, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 5.10.218 release.
> There are 15 patches in this series, all will be posted as a response
> to this one. If anyone has any issues with these being applied, please
> let me know.
Tested-by: Mark Brown <broonie@kernel.org>
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply [flat|nested] 22+ messages in thread* Re: [PATCH 5.10 00/15] 5.10.218-rc1 review
2024-05-23 13:12 [PATCH 5.10 00/15] 5.10.218-rc1 review Greg Kroah-Hartman
` (15 preceding siblings ...)
2024-05-23 18:20 ` [PATCH 5.10 00/15] 5.10.218-rc1 review Mark Brown
@ 2024-05-23 18:35 ` Florian Fainelli
2024-05-24 0:55 ` Dominique Martinet
` (3 subsequent siblings)
20 siblings, 0 replies; 22+ messages in thread
From: Florian Fainelli @ 2024-05-23 18:35 UTC (permalink / raw)
To: Greg Kroah-Hartman, stable
Cc: patches, linux-kernel, torvalds, akpm, linux, shuah, patches,
lkft-triage, pavel, jonathanh, sudipm.mukherjee, srw, rwarsow,
conor, allen.lkml, broonie
On 5/23/24 06:12, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 5.10.218 release.
> There are 15 patches in this series, all will be posted as a response
> to this one. If anyone has any issues with these being applied, please
> let me know.
>
> Responses should be made by Sat, 25 May 2024 13:03:15 +0000.
> Anything received after that time might be too late.
>
> The whole patch series can be found in one patch at:
> https://www.kernel.org/pub/linux/kernel/v5.x/stable-review/patch-5.10.218-rc1.gz
> or in the git tree and branch at:
> git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-5.10.y
> and the diffstat can be found below.
>
> thanks,
>
> greg k-h
On ARCH_BRCMSTB using 32-bit and 64-bit ARM kernels, build tested on
BMIPS_GENERIC:
Tested-by: Florian Fainelli <florian.fainelli@broadcom.com>
--
Florian
^ permalink raw reply [flat|nested] 22+ messages in thread* Re: [PATCH 5.10 00/15] 5.10.218-rc1 review
2024-05-23 13:12 [PATCH 5.10 00/15] 5.10.218-rc1 review Greg Kroah-Hartman
` (16 preceding siblings ...)
2024-05-23 18:35 ` Florian Fainelli
@ 2024-05-24 0:55 ` Dominique Martinet
2024-05-24 11:22 ` Pavel Machek
` (2 subsequent siblings)
20 siblings, 0 replies; 22+ messages in thread
From: Dominique Martinet @ 2024-05-24 0:55 UTC (permalink / raw)
To: Greg Kroah-Hartman
Cc: stable, patches, linux-kernel, torvalds, akpm, linux, shuah,
patches, lkft-triage, pavel, jonathanh, f.fainelli,
sudipm.mukherjee, srw, rwarsow, conor, allen.lkml, broonie
Greg Kroah-Hartman wrote on Thu, May 23, 2024 at 03:12:42PM +0200:
> This is the start of the stable review cycle for the 5.10.218 release.
> There are 15 patches in this series, all will be posted as a response
> to this one. If anyone has any issues with these being applied, please
> let me know.
>
> Responses should be made by Sat, 25 May 2024 13:03:15 +0000.
> Anything received after that time might be too late.
>
> The whole patch series can be found in one patch at:
> https://www.kernel.org/pub/linux/kernel/v5.x/stable-review/patch-5.10.218-rc1.gz
> or in the git tree and branch at:
> git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-5.10.y
> and the diffstat can be found below.
Tested bc8c5267b8b7 ("Linux 5.10.218-rc1") on:
- arm i.MX6ULL (Armadillo 640)
- arm64 i.MX8MP (Armadillo G4)
No obvious regression in dmesg or basic tests:
Tested-by: Dominique Martinet <dominique.martinet@atmark-techno.com>
--
Dominique Martinet | Asmadeus
^ permalink raw reply [flat|nested] 22+ messages in thread* Re: [PATCH 5.10 00/15] 5.10.218-rc1 review
2024-05-23 13:12 [PATCH 5.10 00/15] 5.10.218-rc1 review Greg Kroah-Hartman
` (17 preceding siblings ...)
2024-05-24 0:55 ` Dominique Martinet
@ 2024-05-24 11:22 ` Pavel Machek
2024-05-24 11:42 ` Anders Roxell
2024-05-24 15:20 ` Jon Hunter
20 siblings, 0 replies; 22+ messages in thread
From: Pavel Machek @ 2024-05-24 11:22 UTC (permalink / raw)
To: Greg Kroah-Hartman
Cc: stable, patches, linux-kernel, torvalds, akpm, linux, shuah,
patches, lkft-triage, pavel, jonathanh, f.fainelli,
sudipm.mukherjee, srw, rwarsow, conor, allen.lkml, broonie
[-- Attachment #1: Type: text/plain, Size: 661 bytes --]
Hi!
> This is the start of the stable review cycle for the 5.10.218 release.
> There are 15 patches in this series, all will be posted as a response
> to this one. If anyone has any issues with these being applied, please
> let me know.
CIP testing did not find any problems here:
https://gitlab.com/cip-project/cip-testing/linux-stable-rc-ci/-/tree/linux-5.10.y
Tested-by: Pavel Machek (CIP) <pavel@denx.de>
Best regards,
Pavel
--
DENX Software Engineering GmbH, Managing Director: Erika Unter
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 195 bytes --]
^ permalink raw reply [flat|nested] 22+ messages in thread* Re: [PATCH 5.10 00/15] 5.10.218-rc1 review
2024-05-23 13:12 [PATCH 5.10 00/15] 5.10.218-rc1 review Greg Kroah-Hartman
` (18 preceding siblings ...)
2024-05-24 11:22 ` Pavel Machek
@ 2024-05-24 11:42 ` Anders Roxell
2024-05-24 15:20 ` Jon Hunter
20 siblings, 0 replies; 22+ messages in thread
From: Anders Roxell @ 2024-05-24 11:42 UTC (permalink / raw)
To: Greg Kroah-Hartman
Cc: stable, patches, linux-kernel, torvalds, akpm, linux, shuah,
patches, lkft-triage, pavel, jonathanh, f.fainelli,
sudipm.mukherjee, srw, rwarsow, conor, allen.lkml, broonie
On Thu, 23 May 2024 at 15:17, Greg Kroah-Hartman
<gregkh@linuxfoundation.org> wrote:
>
> This is the start of the stable review cycle for the 5.10.218 release.
> There are 15 patches in this series, all will be posted as a response
> to this one. If anyone has any issues with these being applied, please
> let me know.
>
> Responses should be made by Sat, 25 May 2024 13:03:15 +0000.
> Anything received after that time might be too late.
>
> The whole patch series can be found in one patch at:
> https://www.kernel.org/pub/linux/kernel/v5.x/stable-review/patch-5.10.218-rc1.gz
> or in the git tree and branch at:
> git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-5.10.y
> and the diffstat can be found below.
Results from Linaro’s test farm.
No regressions on arm64, arm, x86_64, and i386.
Tested-by: Linux Kernel Functional Testing <lkft@linaro.org>
## Build Summary
* arc: 5 total, 5 passed, 0 failed
* arm: 104 total, 104 passed, 0 failed
* arm64: 31 total, 31 passed, 0 failed
* i386: 25 total, 25 passed, 0 failed
* mips: 22 total, 22 passed, 0 failed
* parisc: 3 total, 0 passed, 3 failed
* powerpc: 23 total, 23 passed, 0 failed
* riscv: 9 total, 9 passed, 0 failed
* s390: 9 total, 9 passed, 0 failed
* sh: 9 total, 9 passed, 0 failed
* sparc: 6 total, 6 passed, 0 failed
* x86_64: 27 total, 27 passed, 0 failed
## Test suites summary
* boot
* kselftest-android
* kselftest-arm64
* kselftest-breakpoints
* kselftest-capabilities
* kselftest-cgroup
* kselftest-clone3
* kselftest-core
* kselftest-cpu-hotplug
* kselftest-cpufreq
* kselftest-drivers-dma-buf
* kselftest-efivarfs
* kselftest-exec
* kselftest-filesystems
* kselftest-filesystems-binderfs
* kselftest-filesystems-epoll
* kselftest-firmware
* kselftest-fpu
* kselftest-ftrace
* kselftest-futex
* kselftest-gpio
* kselftest-intel_pstate
* kselftest-ipc
* kselftest-ir
* kselftest-kcmp
* kselftest-kexec
* kselftest-kvm
* kselftest-lib
* kselftest-membarrier
* kselftest-memfd
* kselftest-memory-hotplug
* kselftest-mincore
* kselftest-mm
* kselftest-mount
* kselftest-mqueue
* kselftest-net
* kselftest-net-mptcp
* kselftest-netfilter
* kselftest-nsfs
* kselftest-openat2
* kselftest-pid_namespace
* kselftest-pidfd
* kselftest-proc
* kselftest-pstore
* kselftest-ptrace
* kselftest-rseq
* kselftest-rtc
* kselftest-sigaltstack
* kselftest-size
* kselftest-splice
* kselftest-static_keys
* kselftest-sync
* kselftest-sysctl
* kselftest-tc-testing
* kselftest-timens
* kselftest-timers
* kselftest-tmpfs
* kselftest-tpm2
* kselftest-user
* kselftest-user_events
* kselftest-vDSO
* kselftest-watchdog
* kselftest-x86
* kselftest-zram
* kunit
* kvm-unit-tests
* libgpiod
* log-parser-boot
* log-parser-test
* ltp-cap_bounds
* ltp-commands
* ltp-containers
* ltp-controllers
* ltp-crypto
* ltp-cve
* ltp-fcntl-locktests
* ltp-filecaps
* ltp-fs
* ltp-fs_bind
* ltp-fs_perms_simple
* ltp-hugetlb
* ltp-io
* ltp-ipc
* ltp-math
* ltp-mm
* ltp-nptl
* ltp-pty
* ltp-sched
* ltp-securebits
* ltp-smoke
* ltp-smoketest
* ltp-syscalls
* ltp-tracing
* perf
* rcutorture
--
Linaro LKFT
https://lkft.linaro.org
^ permalink raw reply [flat|nested] 22+ messages in thread* Re: [PATCH 5.10 00/15] 5.10.218-rc1 review
2024-05-23 13:12 [PATCH 5.10 00/15] 5.10.218-rc1 review Greg Kroah-Hartman
` (19 preceding siblings ...)
2024-05-24 11:42 ` Anders Roxell
@ 2024-05-24 15:20 ` Jon Hunter
20 siblings, 0 replies; 22+ messages in thread
From: Jon Hunter @ 2024-05-24 15:20 UTC (permalink / raw)
To: Greg Kroah-Hartman
Cc: Greg Kroah-Hartman, patches, linux-kernel, torvalds, akpm, linux,
shuah, patches, lkft-triage, pavel, jonathanh, f.fainelli,
sudipm.mukherjee, srw, rwarsow, conor, allen.lkml, broonie,
linux-tegra, stable
On Thu, 23 May 2024 15:12:42 +0200, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 5.10.218 release.
> There are 15 patches in this series, all will be posted as a response
> to this one. If anyone has any issues with these being applied, please
> let me know.
>
> Responses should be made by Sat, 25 May 2024 13:03:15 +0000.
> Anything received after that time might be too late.
>
> The whole patch series can be found in one patch at:
> https://www.kernel.org/pub/linux/kernel/v5.x/stable-review/patch-5.10.218-rc1.gz
> or in the git tree and branch at:
> git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-5.10.y
> and the diffstat can be found below.
>
> thanks,
>
> greg k-h
All tests passing for Tegra ...
Test results for stable-v5.10:
10 builds: 10 pass, 0 fail
26 boots: 26 pass, 0 fail
61 tests: 61 pass, 0 fail
Linux version: 5.10.218-rc1-gbc8c5267b8b7
Boards tested: tegra124-jetson-tk1, tegra186-p2771-0000,
tegra194-p2972-0000, tegra194-p3509-0000+p3668-0000,
tegra20-ventana, tegra210-p2371-2180,
tegra210-p3450-0000, tegra30-cardhu-a04
Tested-by: Jon Hunter <jonathanh@nvidia.com>
Jon
^ permalink raw reply [flat|nested] 22+ messages in thread