5.15.19-rc1 review

Cc Matt Kline <[email protected]>

Cc Chandrasekar Ramakrishnan <[email protected]>

Reported-by Michael Anochin <[email protected]>

Signed-off-by Marc Kleine-Budde <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 drivers/net/can/m_can/m_can.c |    6 ++++++
 1 file changed, 6 insertions(+)

drivers/net/can/m_can/m_can.c +6 -0

@@ -336,6 +336,9 @@ m_can_fifo_read(struct m_can_classdev *c
 	u32 addr_offset = cdev->mcfg[MRAM_RXF0].off + fgi * RXF0_ELEMENT_SIZE +
 		offset;
 
+	if (val_count == 0)
+		return 0;
+
 	return cdev->ops->read_fifo(cdev, addr_offset, val, val_count);
 }

@@ -346,6 +349,9 @@ m_can_fifo_write(struct m_can_classdev *
 	u32 addr_offset = cdev->mcfg[MRAM_TXB].off + fpi * TXB_ELEMENT_SIZE +
 		offset;
 
+	if (val_count == 0)
+		return 0;
+
 	return cdev->ops->write_fifo(cdev, addr_offset, val, val_count);
 }

Greg Kroah-Hartman

author maintainer

2022-01-31 11:12 UTC #2 lore raw

PATCH 2/171 net: sfp: ignore disabled SFP node

From: Marek Behún <[email protected]>

commit 2148927e6ed43a1667baf7c2ae3e0e05a44b51a0 upstream.

Commit ce0aa27ff3f6 ("sfp: add sfp-bus to bridge between network devices and sfp cages") added code which finds SFP bus DT node even if the node is disabled with status = "disabled". Because of this, when phylink is created, it ends with non-null .sfp_bus member, even though the SFP module is not probed (because the node is disabled).

We need to ignore disabled SFP bus node.

Fixes ce0aa27ff3f6 ("sfp: add sfp-bus to bridge between network devices and sfp cages")

Signed-off-by Marek Behún <[email protected]>

Cc [email protected] # 2203cbf2c8b5 ("net: sfp: move fwnode parsing into sfp-bus layer")

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 drivers/net/phy/sfp-bus.c |    5 +++++
 1 file changed, 5 insertions(+)

drivers/net/phy/sfp-bus.c +5 -0

@@ -651,6 +651,11 @@ struct sfp_bus *sfp_bus_find_fwnode(stru
 	else if (ret < 0)
 		return ERR_PTR(ret);
 
+	if (!fwnode_device_is_available(ref.fwnode)) {
+		fwnode_handle_put(ref.fwnode);
+		return NULL;
+	}
+
 	bus = sfp_bus_get(ref.fwnode);
 	fwnode_handle_put(ref.fwnode);
 	if (!bus)

Greg Kroah-Hartman

author maintainer

2022-01-31 11:12 UTC #3 lore raw

PATCH 3/171 net: stmmac: configure PTP clock source prior to PTP initialization

From: Mohammad Athari Bin Ismail <[email protected]>

commit 94c82de43e01ef5747a95e4a590880de863fe423 upstream.

For Intel platform, it is required to configure PTP clock source prior PTP initialization in MAC. So, need to move ptp_clk_freq_config execution from stmmac_ptp_register() to stmmac_init_ptp().

Fixes 76da35dc99af ("stmmac: intel: Add PSE and PCH PTP clock source selection")

Cc <[email protected]> # 5.15.x

Signed-off-by Mohammad Athari Bin Ismail <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 drivers/net/ethernet/stmicro/stmmac/stmmac_main.c |    3 +++
 drivers/net/ethernet/stmicro/stmmac/stmmac_ptp.c  |    3 ---
 2 files changed, 3 insertions(+), 3 deletions(-)

drivers/net/ethernet/stmicro/stmmac/stmmac_main.c +3 -0

@@ -899,6 +899,9 @@ static int stmmac_init_ptp(struct stmmac
 	bool xmac = priv->plat->has_gmac4 || priv->plat->has_xgmac;
 	int ret;
 
+	if (priv->plat->ptp_clk_freq_config)
+		priv->plat->ptp_clk_freq_config(priv);
+
 	ret = stmmac_init_tstamp_counter(priv, STMMAC_HWTS_ACTIVE);
 	if (ret)
 		return ret;

drivers/net/ethernet/stmicro/stmmac/stmmac_ptp.c +0 -3

@@ -297,9 +297,6 @@ void stmmac_ptp_register(struct stmmac_p
 {
 	int i;
 
-	if (priv->plat->ptp_clk_freq_config)
-		priv->plat->ptp_clk_freq_config(priv);
-
 	for (i = 0; i < priv->dma_cap.pps_out_num; i++) {
 		if (i >= STMMAC_PPS_MAX)
 			break;

Greg Kroah-Hartman

author maintainer

2022-01-31 11:12 UTC #4 lore raw

PATCH 4/171 net: stmmac: skip only stmmac_ptp_register when resume from suspend

From: Mohammad Athari Bin Ismail <[email protected]>

commit 0735e639f129dff455aeb91da291f5c578cc33db upstream.

When resume from suspend, besides skipping PTP registration, it also skipping PTP HW initialization. This could cause PTP clock not able to operate properly when resume from suspend.

To fix this, only stmmac_ptp_register() is skipped when resume from suspend.

Fixes fe1319291150 ("stmmac: Don't init ptp again when resume from suspend/hibernation")

Cc <[email protected]> # 5.15.x

Signed-off-by Mohammad Athari Bin Ismail <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 drivers/net/ethernet/stmicro/stmmac/stmmac_main.c |   20 +++++++++-----------
 1 file changed, 9 insertions(+), 11 deletions(-)

drivers/net/ethernet/stmicro/stmmac/stmmac_main.c +9 ~~-11~~

@@ -924,8 +924,6 @@ static int stmmac_init_ptp(struct stmmac
 	priv->hwts_tx_en = 0;
 	priv->hwts_rx_en = 0;
 
-	stmmac_ptp_register(priv);
-
 	return 0;
 }

@@ -3240,7 +3238,7 @@ static int stmmac_fpe_start_wq(struct st
 /**
  * stmmac_hw_setup - setup mac in a usable state.
  *  @dev : pointer to the device structure.
- *  @init_ptp: initialize PTP if set
+ *  @ptp_register: register PTP if set
  *  Description:
  *  this is the main function to setup the HW in a usable state because the
  *  dma engine is reset, the core registers are configured (e.g. AXI,

@@ -3250,7 +3248,7 @@ static int stmmac_fpe_start_wq(struct st
  *  0 on success and an appropriate (-)ve integer as defined in errno.h
  *  file on failure.
  */
-static int stmmac_hw_setup(struct net_device *dev, bool init_ptp)
+static int stmmac_hw_setup(struct net_device *dev, bool ptp_register)
 {
 	struct stmmac_priv *priv = netdev_priv(dev);
 	u32 rx_cnt = priv->plat->rx_queues_to_use;

@@ -3307,13 +3305,13 @@ static int stmmac_hw_setup(struct net_de
 
 	stmmac_mmc_setup(priv);
 
-	if (init_ptp) {
-		ret = stmmac_init_ptp(priv);
-		if (ret == -EOPNOTSUPP)
-			netdev_warn(priv->dev, "PTP not supported by HW\n");
-		else if (ret)
-			netdev_warn(priv->dev, "PTP init failed\n");
-	}
+	ret = stmmac_init_ptp(priv);
+	if (ret == -EOPNOTSUPP)
+		netdev_warn(priv->dev, "PTP not supported by HW\n");
+	else if (ret)
+		netdev_warn(priv->dev, "PTP init failed\n");
+	else if (ptp_register)
+		stmmac_ptp_register(priv);
 
 	priv->eee_tw_timer = STMMAC_DEFAULT_TWT_LS;

Greg Kroah-Hartman

author maintainer

2022-01-31 11:12 UTC #5 lore raw

PATCH 5/171 ARM: 9179/1: uaccess: avoid alignment faults in copy_[from|to]_kernel_nofault

From: Ard Biesheuvel <[email protected]>

commit 15420269b02a63ed8c1841905d8b8b2403246004 upstream.

The helpers that are used to implement copy_from_kernel_nofault() and copy_to_kernel_nofault() cast a void* to a pointer to a wider type, which may result in alignment faults on ARM if the compiler decides to use double-word or multiple-word load/store instructions.

Only configurations that define CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS=y are affected, given that commit 2423de2e6f4d ("ARM: 9115/1: mm/maccess:
fix unaligned copy_{from,to}_kernel_nofault") ensures that dst and src are sufficiently aligned otherwise.

So use the unaligned accessors for accessing dst and src in cases where they may be misaligned.

Cc <[email protected]> # depends on 2423de2e6f4d

Fixes 2df4c9a741a0 ("ARM: 9112/1: uaccess: add __{get,put}_kernel_nofault")

Reviewed-by Arnd Bergmann <[email protected]>

Signed-off-by Russell King (Oracle) <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 arch/arm/include/asm/uaccess.h |   10 ++++++++--
 1 file changed, 8 insertions(+), 2 deletions(-)

arch/arm/include/asm/uaccess.h +8 -2

@@ -11,6 +11,7 @@
 #include <linux/string.h>
 #include <asm/memory.h>
 #include <asm/domain.h>
+#include <asm/unaligned.h>
 #include <asm/unified.h>
 #include <asm/compiler.h>

@@ -497,7 +498,10 @@ do {									\
 	}								\
 	default: __err = __get_user_bad(); break;			\
 	}								\
-	*(type *)(dst) = __val;						\
+	if (IS_ENABLED(CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS))		\
+		put_unaligned(__val, (type *)(dst));			\
+	else								\
+		*(type *)(dst) = __val; /* aligned by caller */		\
 	if (__err)							\
 		goto err_label;						\
 } while (0)

@@ -507,7 +511,9 @@ do {									\
 	const type *__pk_ptr = (dst);					\
 	unsigned long __dst = (unsigned long)__pk_ptr;			\
 	int __err = 0;							\
-	type __val = *(type *)src;					\
+	type __val = IS_ENABLED(CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS)	\
+		     ? get_unaligned((type *)(src))			\
+		     : *(type *)(src);	/* aligned by caller */		\
 	switch (sizeof(type)) {						\
 	case 1: __put_user_asm_byte(__val, __dst, __err, ""); break;	\
 	case 2:	__put_user_asm_half(__val, __dst, __err, ""); break;	\

Greg Kroah-Hartman

author maintainer

2022-01-31 11:11 UTC #6 lore raw

PATCH 6/171 ARM: 9180/1: Thumb2: align ALT_UP() sections in modules sufficiently

From: Ard Biesheuvel <[email protected]>

commit 9f80ccda53b9417236945bc7ece4b519037df74d upstream.

When building for Thumb2, the .alt.smp.init sections that are emitted by the ALT_UP() patching code may not be 32-bit aligned, even though the fixup_smp_on_up() routine expects that. This results in alignment faults at module load time, which need to be fixed up by the fault handler.

So let's align those sections explicitly, and prevent this from occurring.

Signed-off-by Russell King (Oracle) <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 arch/arm/include/asm/assembler.h |    2 ++
 arch/arm/include/asm/processor.h |    1 +
 2 files changed, 3 insertions(+)

arch/arm/include/asm/assembler.h +2 -0

@@ -259,6 +259,7 @@
  */
 #define ALT_UP(instr...)					\
 	.pushsection ".alt.smp.init", "a"			;\
+	.align	2						;\
 	.long	9998b - .					;\
 9997:	instr							;\
 	.if . - 9997b == 2					;\

@@ -270,6 +271,7 @@
 	.popsection
 #define ALT_UP_B(label)					\
 	.pushsection ".alt.smp.init", "a"			;\
+	.align	2						;\
 	.long	9998b - .					;\
 	W(b)	. + (label - 9998b)					;\
 	.popsection

arch/arm/include/asm/processor.h +1 -0

@@ -96,6 +96,7 @@ unsigned long get_wchan(struct task_stru
 #define __ALT_SMP_ASM(smp, up)						\
 	"9998:	" smp "\n"						\
 	"	.pushsection \".alt.smp.init\", \"a\"\n"		\
+	"	.align	2\n"						\
 	"	.long	9998b - .\n"					\
 	"	" up "\n"						\
 	"	.popsection\n"

Greg Kroah-Hartman

author maintainer

2022-01-31 11:11 UTC #7 lore raw

PATCH 7/171 KVM: arm64: Use shadow SPSR_EL1 when injecting exceptions on !VHE

From: Marc Zyngier <[email protected]>

commit 278583055a237270fac70518275ba877bf9e4013 upstream.

Injecting an exception into a guest with non-VHE is risky business. Instead of writing in the shadow register for the switch code to restore it, we override the CPU register instead. Which gets overriden a few instructions later by said restore code.

The result is that although the guest correctly gets the exception, it will return to the original context in some random state, depending on what was there the first place... Boo.

Fix the issue by writing to the shadow register. The original code is absolutely fine on VHE, as the state is already loaded, and writing to the shadow register in that case would actually be a bug.

Fixes bb666c472ca2 ("KVM: arm64: Inject AArch64 exceptions from HYP")

Reviewed-by Fuad Tabba <[email protected]>

Link https://lore.kernel.org/r/[email protected] open here

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 arch/arm64/kvm/hyp/exception.c |    5 ++++-
 1 file changed, 4 insertions(+), 1 deletion(-)

arch/arm64/kvm/hyp/exception.c +4 -1

@@ -38,7 +38,10 @@ static inline void __vcpu_write_sys_reg(
 
 static void __vcpu_write_spsr(struct kvm_vcpu *vcpu, u64 val)
 {
-	write_sysreg_el1(val, SYS_SPSR);
+	if (has_vhe())
+		write_sysreg_el1(val, SYS_SPSR);
+	else
+		__vcpu_sys_reg(vcpu, SPSR_EL1) = val;
 }
 
 static void __vcpu_write_spsr_abt(struct kvm_vcpu *vcpu, u64 val)

Greg Kroah-Hartman

author maintainer

2022-01-31 11:11 UTC #8 lore raw

PATCH 8/171 s390/module: fix loading modules with a lot of relocations

From: Ilya Leoshkevich <[email protected]>

commit f3b7e73b2c6619884351a3a0a7468642f852b8a2 upstream.

If the size of the PLT entries generated by apply_rela() exceeds 64KiB, the first ones can no longer reach __jump_r1 with brc. Fix by using brcl. An alternative solution is to add a __jump_r1 copy after every 64KiB, however, the space savings are quite small and do not justify the additional complexity.

Fixes f19fbd5ed642 ("s390: introduce execute-trampolines for branches")

Reported-by Andrea Righi <[email protected]>

Signed-off-by Ilya Leoshkevich <[email protected]>

Reviewed-by Heiko Carstens <[email protected]>

Cc Vasily Gorbik <[email protected]>

Cc Christian Borntraeger <[email protected]>

Signed-off-by Heiko Carstens <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 arch/s390/kernel/module.c |   37 ++++++++++++++++++-------------------
 1 file changed, 18 insertions(+), 19 deletions(-)

arch/s390/kernel/module.c +18 ~~-19~~

@@ -33,7 +33,7 @@
 #define DEBUGP(fmt , ...)
 #endif
 
-#define PLT_ENTRY_SIZE 20
+#define PLT_ENTRY_SIZE 22
 
 void *module_alloc(unsigned long size)
 {

@@ -340,27 +340,26 @@ static int apply_rela(Elf_Rela *rela, El
 	case R_390_PLTOFF32:	/* 32 bit offset from GOT to PLT. */
 	case R_390_PLTOFF64:	/* 16 bit offset from GOT to PLT. */
 		if (info->plt_initialized == 0) {
-			unsigned int insn[5];
-			unsigned int *ip = me->core_layout.base +
-					   me->arch.plt_offset +
-					   info->plt_offset;
-
-			insn[0] = 0x0d10e310;	/* basr 1,0  */
-			insn[1] = 0x100a0004;	/* lg	1,10(1) */
+			unsigned char insn[PLT_ENTRY_SIZE];
+			char *plt_base;
+			char *ip;
+
+			plt_base = me->core_layout.base + me->arch.plt_offset;
+			ip = plt_base + info->plt_offset;
+			*(int *)insn = 0x0d10e310;	/* basr 1,0  */
+			*(int *)&insn[4] = 0x100c0004;	/* lg	1,12(1) */
 			if (IS_ENABLED(CONFIG_EXPOLINE) && !nospec_disable) {
-				unsigned int *ij;
-				ij = me->core_layout.base +
-					me->arch.plt_offset +
-					me->arch.plt_size - PLT_ENTRY_SIZE;
-				insn[2] = 0xa7f40000 +	/* j __jump_r1 */
-					(unsigned int)(u16)
-					(((unsigned long) ij - 8 -
-					  (unsigned long) ip) / 2);
+				char *jump_r1;
+
+				jump_r1 = plt_base + me->arch.plt_size -
+					PLT_ENTRY_SIZE;
+				/* brcl	0xf,__jump_r1 */
+				*(short *)&insn[8] = 0xc0f4;
+				*(int *)&insn[10] = (jump_r1 - (ip + 8)) / 2;
 			} else {
-				insn[2] = 0x07f10000;	/* br %r1 */
+				*(int *)&insn[8] = 0x07f10000;	/* br %r1 */
 			}
-			insn[3] = (unsigned int) (val >> 32);
-			insn[4] = (unsigned int) val;
+			*(long *)&insn[14] = val;
 
 			write(ip, insn, sizeof(insn));
 			info->plt_initialized = 1;

Greg Kroah-Hartman

author maintainer

2022-01-31 11:12 UTC #9 lore raw

PATCH 9/171 s390/hypfs: include z/VM guests with access control group set

From: Vasily Gorbik <[email protected]>

commit 663d34c8df98740f1e90241e78e456d00b3c6cad upstream.

Currently if z/VM guest is allowed to retrieve hypervisor performance data globally for all guests (privilege class B) the query is formed in a way to include all guests but the group name is left empty. This leads to that z/VM guests which have access control group set not being included in the results (even local vm).

Change the query group identifier from empty to "any" to retrieve information about all guests from any groups (or without a group set).

Fixes 31cb4bd31a48 ("[S390] Hypervisor filesystem (s390_hypfs) for z/VM")

Reviewed-by Gerald Schaefer <[email protected]>

Signed-off-by Vasily Gorbik <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 arch/s390/hypfs/hypfs_vm.c |    6 ++++--
 1 file changed, 4 insertions(+), 2 deletions(-)

arch/s390/hypfs/hypfs_vm.c +4 -2

@@ -20,6 +20,7 @@
 
 static char local_guest[] = "        ";
 static char all_guests[] = "*       ";
+static char *all_groups = all_guests;
 static char *guest_query;
 
 struct diag2fc_data {

@@ -62,10 +63,11 @@ static int diag2fc(int size, char* query
 
 	memcpy(parm_list.userid, query, NAME_LEN);
 	ASCEBC(parm_list.userid, NAME_LEN);
-	parm_list.addr = (unsigned long) addr ;
+	memcpy(parm_list.aci_grp, all_groups, NAME_LEN);
+	ASCEBC(parm_list.aci_grp, NAME_LEN);
+	parm_list.addr = (unsigned long)addr;
 	parm_list.size = size;
 	parm_list.fmt = 0x02;
-	memset(parm_list.aci_grp, 0x40, NAME_LEN);
 	rc = -1;
 
 	diag_stat_inc(DIAG_STAT_X2FC);

Greg Kroah-Hartman

author maintainer

2022-01-31 11:12 UTC #10 lore raw

PATCH 10/171 s390/nmi: handle guarded storage validity failures for KVM guests

From: Christian Borntraeger <[email protected]>

commit 1ea1d6a847d2b1d17fefd9196664b95f052a0775 upstream.

machine check validity bits reflect the state of the machine check. If a guest does not make use of guarded storage, the validity bit might be off. We can not use the host CR bit to decide if the validity bit must be on. So ignore "invalid" guarded storage controls for KVM guests in the host and rely on the machine check being forwarded to the guest. If no other errors happen from a host perspective everything is fine and no process must be killed and the host can continue to run.

Fixes c929500d7a5a ("s390/nmi: s390: New low level handling for machine check happening in guest")

Reported-by Carsten Otte <[email protected]>

Signed-off-by Christian Borntraeger <[email protected]>

Tested-by Carsten Otte <[email protected]>

Reviewed-by Heiko Carstens <[email protected]>

Signed-off-by Heiko Carstens <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 arch/s390/kernel/nmi.c |   18 ++++++++++++++----
 1 file changed, 14 insertions(+), 4 deletions(-)

arch/s390/kernel/nmi.c +14 -4

@@ -316,11 +316,21 @@ static int notrace s390_validate_registe
 	if (cr2.gse) {
 		if (!mci.gs) {
 			/*
-			 * Guarded storage register can't be restored and
-			 * the current processes uses guarded storage.
-			 * It has to be terminated.
+			 * 2 cases:
+			 * - machine check in kernel or userspace
+			 * - machine check while running SIE (KVM guest)
+			 * For kernel or userspace the userspace values of
+			 * guarded storage control can not be recreated, the
+			 * process must be terminated.
+			 * For SIE the guest values of guarded storage can not
+			 * be recreated. This is either due to a bug or due to
+			 * GS being disabled in the guest. The guest will be
+			 * notified by KVM code and the guests machine check
+			 * handling must take care of this.  The host values
+			 * are saved by KVM and are not affected.
 			 */
-			kill_task = 1;
+			if (!test_cpu_flag(CIF_MCCK_GUEST))
+				kill_task = 1;
 		} else {
 			load_gs_cb((struct gs_cb *)mcesa->guarded_storage_save_area);
 		}

Greg Kroah-Hartman

author maintainer

2022-01-31 11:12 UTC #11 lore raw

PATCH 11/171 s390/nmi: handle vector validity failures for KVM guests

From: Christian Borntraeger <[email protected]>

commit f094a39c6ba168f2df1edfd1731cca377af5f442 upstream.

The machine check validity bit tells about the context. If a KVM guest was running the bit tells about the guest validity and the host state is not affected. As a guest can disable the guest validity this might result in unwanted host errors on machine checks.

Fixes c929500d7a5a ("s390/nmi: s390: New low level handling for machine check happening in guest")

Signed-off-by Christian Borntraeger <[email protected]>

Reviewed-by Heiko Carstens <[email protected]>

Signed-off-by Heiko Carstens <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 arch/s390/kernel/nmi.c |    9 ++++++++-
 1 file changed, 8 insertions(+), 1 deletion(-)

arch/s390/kernel/nmi.c +8 -1

@@ -273,7 +273,14 @@ static int notrace s390_validate_registe
 		/* Validate vector registers */
 		union ctlreg0 cr0;
 
-		if (!mci.vr) {
+		/*
+		 * The vector validity must only be checked if not running a
+		 * KVM guest. For KVM guests the machine check is forwarded by
+		 * KVM and it is the responsibility of the guest to take
+		 * appropriate actions. The host vector or FPU values have been
+		 * saved by KVM and will be restored by KVM.
+		 */
+		if (!mci.vr && !test_cpu_flag(CIF_MCCK_GUEST)) {
 			/*
 			 * Vector registers can't be restored. If the kernel
 			 * currently uses vector registers the system is

Greg Kroah-Hartman

author maintainer

2022-01-31 11:12 UTC #12 lore raw

PATCH 12/171 bpf: Guard against accessing NULL pt_regs in bpf_get_task_stack()

From: Naveen N. Rao <[email protected]>

commit b992f01e66150fc5e90be4a96f5eb8e634c8249e upstream.

task_pt_regs() can return NULL on powerpc for kernel threads. This is then used in __bpf_get_stack() to check for user mode, resulting in a kernel oops. Guard against this by checking return value of task_pt_regs() before trying to obtain the call chain.

Fixes fa28dcb82a38f8 ("bpf: Introduce helper bpf_get_task_stack()")

Cc [email protected] # v5.9+

Acked-by Daniel Borkmann <[email protected]>

Link https://lore.kernel.org/r/d5ef83c361cc255494afd15ff1b4fb02a36e1dcf.1641468127.git.naveen.n.rao@linux.vnet.ibm.com open here

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 kernel/bpf/stackmap.c |    5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

kernel/bpf/stackmap.c +3 -2

@@ -525,13 +525,14 @@ BPF_CALL_4(bpf_get_task_stack, struct ta
 	   u32, size, u64, flags)
 {
 	struct pt_regs *regs;
-	long res;
+	long res = -EINVAL;
 
 	if (!try_get_task_stack(task))
 		return -EFAULT;
 
 	regs = task_pt_regs(task);
-	res = __bpf_get_stack(regs, task, NULL, buf, size, flags);
+	if (regs)
+		res = __bpf_get_stack(regs, task, NULL, buf, size, flags);
 	put_task_stack(task);
 
 	return res;

Greg Kroah-Hartman

author maintainer

2022-01-31 11:10 UTC #13 lore raw

PATCH 13/171 powerpc32/bpf: Fix codegen for bpf-to-bpf calls

From: Naveen N. Rao <[email protected]>

commit fab07611fb2e6a15fac05c4583045ca5582fd826 upstream.

Pad instructions emitted for BPF_CALL so that the number of instructions generated does not change for different function addresses. This is especially important for calls to other bpf functions, whose address will only be known during extra pass.

Fixes 51c66ad849a703 ("powerpc/bpf: Implement extended BPF on PPC32")

Cc [email protected] # v5.13+

Link https://lore.kernel.org/r/52d8fe51f7620a6f27f377791564d79d75463576.1641468127.git.naveen.n.rao@linux.vnet.ibm.com open here

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 arch/powerpc/net/bpf_jit_comp32.c |    3 +++
 1 file changed, 3 insertions(+)

arch/powerpc/net/bpf_jit_comp32.c +3 -0

@@ -191,6 +191,9 @@ void bpf_jit_emit_func_call_rel(u32 *ima
 
 	if (image && rel < 0x2000000 && rel >= -0x2000000) {
 		PPC_BL_ABS(func);
+		EMIT(PPC_RAW_NOP());
+		EMIT(PPC_RAW_NOP());
+		EMIT(PPC_RAW_NOP());
 	} else {
 		/* Load function address into r0 */
 		EMIT(PPC_RAW_LIS(_R0, IMM_H(func)));

Greg Kroah-Hartman

author maintainer

2022-01-31 11:11 UTC #14 lore raw

PATCH 14/171 powerpc/bpf: Update ldimm64 instructions during extra pass

From: Naveen N. Rao <[email protected]>

commit f9320c49993ca3c0ec0f9a7026b313735306bb8b upstream.

These instructions are updated after the initial JIT, so redo codegen during the extra pass. Rename bpf_jit_fixup_subprog_calls() to clarify that this is more than just subprog calls.

Fixes 69c087ba6225b5 ("bpf: Add bpf_for_each_map_elem() helper")

Cc [email protected] # v5.15

Tested-by Jiri Olsa <[email protected]>

Link https://lore.kernel.org/r/7cc162af77ba918eb3ecd26ec9e7824bc44b1fae.1641468127.git.naveen.n.rao@linux.vnet.ibm.com open here

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 arch/powerpc/net/bpf_jit_comp.c   |   29 +++++++++++++++++++++++------
 arch/powerpc/net/bpf_jit_comp32.c |    6 ++++++
 arch/powerpc/net/bpf_jit_comp64.c |    7 ++++++-
 3 files changed, 35 insertions(+), 7 deletions(-)

arch/powerpc/net/bpf_jit_comp.c +23 -6

@@ -23,15 +23,15 @@ static void bpf_jit_fill_ill_insns(void
 	memset32(area, BREAKPOINT_INSTRUCTION, size / 4);
 }
 
-/* Fix the branch target addresses for subprog calls */
-static int bpf_jit_fixup_subprog_calls(struct bpf_prog *fp, u32 *image,
-				       struct codegen_context *ctx, u32 *addrs)
+/* Fix updated addresses (for subprog calls, ldimm64, et al) during extra pass */
+static int bpf_jit_fixup_addresses(struct bpf_prog *fp, u32 *image,
+				   struct codegen_context *ctx, u32 *addrs)
 {
 	const struct bpf_insn *insn = fp->insnsi;
 	bool func_addr_fixed;
 	u64 func_addr;
 	u32 tmp_idx;
-	int i, ret;
+	int i, j, ret;
 
 	for (i = 0; i < fp->len; i++) {
 		/*

@@ -66,6 +66,23 @@ static int bpf_jit_fixup_subprog_calls(s
 			 * of the JITed sequence remains unchanged.
 			 */
 			ctx->idx = tmp_idx;
+		} else if (insn[i].code == (BPF_LD | BPF_IMM | BPF_DW)) {
+			tmp_idx = ctx->idx;
+			ctx->idx = addrs[i] / 4;
+#ifdef CONFIG_PPC32
+			PPC_LI32(ctx->b2p[insn[i].dst_reg] - 1, (u32)insn[i + 1].imm);
+			PPC_LI32(ctx->b2p[insn[i].dst_reg], (u32)insn[i].imm);
+			for (j = ctx->idx - addrs[i] / 4; j < 4; j++)
+				EMIT(PPC_RAW_NOP());
+#else
+			func_addr = ((u64)(u32)insn[i].imm) | (((u64)(u32)insn[i + 1].imm) << 32);
+			PPC_LI64(b2p[insn[i].dst_reg], func_addr);
+			/* overwrite rest with nops */
+			for (j = ctx->idx - addrs[i] / 4; j < 5; j++)
+				EMIT(PPC_RAW_NOP());
+#endif
+			ctx->idx = tmp_idx;
+			i++;
 		}
 	}

@@ -193,13 +210,13 @@ skip_init_ctx:
 		/*
 		 * Do not touch the prologue and epilogue as they will remain
 		 * unchanged. Only fix the branch target address for subprog
-		 * calls in the body.
+		 * calls in the body, and ldimm64 instructions.
 		 *
 		 * This does not change the offsets and lengths of the subprog
 		 * call instruction sequences and hence, the size of the JITed
 		 * image as well.
 		 */
-		bpf_jit_fixup_subprog_calls(fp, code_base, &cgctx, addrs);
+		bpf_jit_fixup_addresses(fp, code_base, &cgctx, addrs);
 
 		/* There is no need to perform the usual passes. */
 		goto skip_codegen_passes;

arch/powerpc/net/bpf_jit_comp32.c +6 -0

@@ -292,6 +292,8 @@ int bpf_jit_build_body(struct bpf_prog *
 		bool func_addr_fixed;
 		u64 func_addr;
 		u32 true_cond;
+		u32 tmp_idx;
+		int j;
 
 		/*
 		 * addrs[] maps a BPF bytecode address into a real offset from

@@ -839,8 +841,12 @@ int bpf_jit_build_body(struct bpf_prog *
 		 * 16 byte instruction that uses two 'struct bpf_insn'
 		 */
 		case BPF_LD | BPF_IMM | BPF_DW: /* dst = (u64) imm */
+			tmp_idx = ctx->idx;
 			PPC_LI32(dst_reg_h, (u32)insn[i + 1].imm);
 			PPC_LI32(dst_reg, (u32)insn[i].imm);
+			/* padding to allow full 4 instructions for later patching */
+			for (j = ctx->idx - tmp_idx; j < 4; j++)
+				EMIT(PPC_RAW_NOP());
 			/* Adjust for two bpf instructions */
 			addrs[++i] = ctx->idx * 4;
 			break;

arch/powerpc/net/bpf_jit_comp64.c +6 -1

@@ -318,6 +318,7 @@ int bpf_jit_build_body(struct bpf_prog *
 		u64 imm64;
 		u32 true_cond;
 		u32 tmp_idx;
+		int j;
 
 		/*
 		 * addrs[] maps a BPF bytecode address into a real offset from

@@ -806,9 +807,13 @@ emit_clear:
 		case BPF_LD | BPF_IMM | BPF_DW: /* dst = (u64) imm */
 			imm64 = ((u64)(u32) insn[i].imm) |
 				    (((u64)(u32) insn[i+1].imm) << 32);
+			tmp_idx = ctx->idx;
+			PPC_LI64(dst_reg, imm64);
+			/* padding to allow full 5 instructions for later patching */
+			for (j = ctx->idx - tmp_idx; j < 5; j++)
+				EMIT(PPC_RAW_NOP());
 			/* Adjust for two bpf instructions */
 			addrs[++i] = ctx->idx * 4;
-			PPC_LI64(dst_reg, imm64);
 			break;
 
 		/*

Greg Kroah-Hartman

author maintainer

2022-01-31 11:11 UTC #15 lore raw

PATCH 15/171 ucount: Make get_ucount a safe get_user replacement

Link https://lore.kernel.org/lkml/[email protected]/ open here

From: Eric W. Biederman <[email protected]>

commit f9d87929d451d3e649699d0f1d74f71f77ad38f5 upstream.

When the ucount code was refactored to create get_ucount it was missed that some of the contexts in which a rlimit is kept elevated can be the only reference to the user/ucount in the system.

Ordinary ucount references exist in places that also have a reference to the user namspace, but in POSIX message queues, the SysV shm code, and the SIGPENDING code there is no independent user namespace reference.

Inspection of the the user_namespace show no instance of circular references between struct ucounts and the user_namespace. So hold a reference from struct ucount to i's user_namespace to resolve this problem.

Reported-by Qian Cai <[email protected]>

Reported-by Mathias Krause <[email protected]>

Tested-by Mathias Krause <[email protected]>

Reviewed-by Mathias Krause <[email protected]>

Reviewed-by Alexey Gladkov <[email protected]>

Fixes d64696905554 ("Reimplement RLIMIT_SIGPENDING on top of ucounts")

Fixes 6e52a9f0532f ("Reimplement RLIMIT_MSGQUEUE on top of ucounts")

Fixes d7c9e99aee48 ("Reimplement RLIMIT_MEMLOCK on top of ucounts")

Signed-off-by "Eric W. Biederman" <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 kernel/ucount.c |    2 ++
 1 file changed, 2 insertions(+)

kernel/ucount.c +2 -0

@@ -184,6 +184,7 @@ struct ucounts *alloc_ucounts(struct use
 			kfree(new);
 		} else {
 			hlist_add_head(&new->node, hashent);
+			get_user_ns(new->ns);
 			spin_unlock_irq(&ucounts_lock);
 			return new;
 		}

@@ -204,6 +205,7 @@ void put_ucounts(struct ucounts *ucounts
 	if (atomic_dec_and_lock_irqsave(&ucounts->count, &ucounts_lock, flags)) {
 		hlist_del_init(&ucounts->node);
 		spin_unlock_irqrestore(&ucounts_lock, flags);
+		put_user_ns(ucounts->ns);
 		kfree(ucounts);
 	}
 }

Greg Kroah-Hartman

author maintainer

2022-01-31 11:12 UTC #16 lore raw

PATCH 16/171 scsi: zfcp: Fix failed recovery on gone remote port with non-NPIV FCP devices

From: Steffen Maier <[email protected]>

commit 8c9db6679be4348b8aae108e11d4be2f83976e30 upstream.

Suppose we have an environment with a number of non-NPIV FCP devices (virtual HBAs / FCP devices / zfcp "adapter"s) sharing the same physical FCP channel (HBA port) and its I_T nexus. Plus a number of storage target ports zoned to such shared channel. Now one target port logs out of the fabric causing an RSCN. Zfcp reacts with an ADISC ELS and subsequent port recovery depending on the ADISC result. This happens on all such FCP devices (in different Linux images) concurrently as they all receive a copy of this RSCN. In the following we look at one of those FCP devices.

Requests other than FSF_QTCB_FCP_CMND can be slow until they get a response.

Depending on which requests are affected by slow responses, there are different recovery outcomes. Here we want to fix failed recoveries on port or adapter level by avoiding recovery requests that can be slow.

We need the cached N_Port_ID for the remote port "link" test with ADISC. Just before sending the ADISC, we now intentionally forget the old cached N_Port_ID. The idea is that on receiving an RSCN for a port, we have to assume that any cached information about this port is stale. This forces a fresh new GID_PN [FC-GS] nameserver lookup on any subsequent recovery for the same port. Since we typically can still communicate with the nameserver efficiently, we now reach steady state quicker: Either the nameserver still does not know about the port so we stop recovery, or the nameserver already knows the port potentially with a new N_Port_ID and we can successfully and quickly perform open port recovery. For the one case, where ADISC returns successfully, we re-initialize port->d_id because that case does not involve any port recovery.

This also solves a problem if the storage WWPN quickly logs into the fabric again but with a different N_Port_ID. Such as on virtual WWPN takeover during target NPIV failover.
[https://www.redbooks.ibm.com/abstracts/redp5477.html] In that case the RSCN from the storage FDISC was ignored by zfcp and we could not successfully recover the failover. On some later failback on the storage, we could have been lucky if the virtual WWPN got the same old N_Port_ID from the SAN switch as we still had cached. Then the related RSCN triggered a successful port reopen recovery. However, there is no guarantee to get the same N_Port_ID on NPIV FDISC.

Even though NPIV-enabled FCP devices are not affected by this problem, this code change optimizes recovery time for gone remote ports as a side effect. The timely drop of cached N_Port_IDs prevents unnecessary slow open port attempts.

While the problem might have been in code before v2.6.32 commit 799b76d09aee ("[SCSI] zfcp: Decouple gid_pn requests from erp") this fix depends on the gid_pn_work introduced with that commit, so we mark it as culprit to satisfy fix dependencies.

Note: Point-to-point remote port is already handled separately and gets its N_Port_ID from the cached peer_d_id. So resetting port->d_id in general does not affect PtP.

Link https://lore.kernel.org/r/[email protected] open here

Fixes 799b76d09aee ("[SCSI] zfcp: Decouple gid_pn requests from erp")

Cc <[email protected]> #2.6.32+

Reviewed-by Benjamin Block <[email protected]>

Signed-off-by Steffen Maier <[email protected]>

Signed-off-by Martin K. Petersen <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 drivers/s390/scsi/zfcp_fc.c |   13 ++++++++++++-
 1 file changed, 12 insertions(+), 1 deletion(-)

drivers/s390/scsi/zfcp_fc.c +12 -1

@@ -521,6 +521,8 @@ static void zfcp_fc_adisc_handler(void *
 		goto out;
 	}
 
+	/* re-init to undo drop from zfcp_fc_adisc() */
+	port->d_id = ntoh24(adisc_resp->adisc_port_id);
 	/* port is good, unblock rport without going through erp */
 	zfcp_scsi_schedule_rport_register(port);
  out:

@@ -534,6 +536,7 @@ static int zfcp_fc_adisc(struct zfcp_por
 	struct zfcp_fc_req *fc_req;
 	struct zfcp_adapter *adapter = port->adapter;
 	struct Scsi_Host *shost = adapter->scsi_host;
+	u32 d_id;
 	int ret;
 
 	fc_req = kmem_cache_zalloc(zfcp_fc_req_cache, GFP_ATOMIC);

@@ -558,7 +561,15 @@ static int zfcp_fc_adisc(struct zfcp_por
 	fc_req->u.adisc.req.adisc_cmd = ELS_ADISC;
 	hton24(fc_req->u.adisc.req.adisc_port_id, fc_host_port_id(shost));
 
-	ret = zfcp_fsf_send_els(adapter, port->d_id, &fc_req->ct_els,
+	d_id = port->d_id; /* remember as destination for send els below */
+	/*
+	 * Force fresh GID_PN lookup on next port recovery.
+	 * Must happen after request setup and before sending request,
+	 * to prevent race with port->d_id re-init in zfcp_fc_adisc_handler().
+	 */
+	port->d_id = 0;
+
+	ret = zfcp_fsf_send_els(adapter, d_id, &fc_req->ct_els,
 				ZFCP_FC_CTELS_TMO);
 	if (ret)
 		kmem_cache_free(zfcp_fc_req_cache, fc_req);

Greg Kroah-Hartman

author maintainer

2022-01-31 11:12 UTC #17 lore raw

PATCH 17/171 udf: Restore i_lenAlloc when inode expansion fails

From: Jan Kara <[email protected]>

commit ea8569194b43f0f01f0a84c689388542c7254a1f upstream.

When we fail to expand inode from inline format to a normal format, we restore inode to contain the original inline formatting but we forgot to set i_lenAlloc back. The mismatch between i_lenAlloc and i_size was then causing further problems such as warnings and lost data down the line.

Reported-by butt3rflyh4ck <[email protected]>

CC [email protected]

Fixes 7e49b6f2480c ("udf: Convert UDF to new truncate calling sequence")

Signed-off-by Jan Kara <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 fs/udf/inode.c |    1 +
 1 file changed, 1 insertion(+)

fs/udf/inode.c +1 -0

@@ -317,6 +317,7 @@ int udf_expand_file_adinicb(struct inode
 		unlock_page(page);
 		iinfo->i_alloc_type = ICBTAG_FLAG_AD_IN_ICB;
 		inode->i_data.a_ops = &udf_adinicb_aops;
+		iinfo->i_lenAlloc = inode->i_size;
 		up_write(&iinfo->i_data_sem);
 	}
 	put_page(page);

Greg Kroah-Hartman

author maintainer

2022-01-31 11:12 UTC #18 lore raw

PATCH 18/171 udf: Fix NULL ptr deref when converting from inline format

From: Jan Kara <[email protected]>

commit 7fc3b7c2981bbd1047916ade327beccb90994eee upstream.

udf_expand_file_adinicb() calls directly ->writepage to write data expanded into a page. This however misses to setup inode for writeback properly and so we can crash on inode->i_wb dereference when submitting page for IO like:

  BUG: kernel NULL pointer dereference, address: 0000000000000158
  #PF: supervisor read access in kernel mode
...
  <TASK>
  __folio_start_writeback+0x2ac/0x350
  __block_write_full_page+0x37d/0x490
  udf_expand_file_adinicb+0x255/0x400 [udf]
  udf_file_write_iter+0xbe/0x1b0 [udf]
  new_sync_write+0x125/0x1c0
  vfs_write+0x28e/0x400

Fix the problem by marking the page dirty and going through the standard writeback path to write the page. Strictly speaking we would not even have to write the page but we want to catch e.g. ENOSPC errors early.

Reported-by butt3rflyh4ck <[email protected]>

CC [email protected]

Fixes 52ebea749aae ("writeback: make backing_dev_info host cgroup-specific bdi_writebacks")

Signed-off-by Jan Kara <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 fs/udf/inode.c |    8 +++-----
 1 file changed, 3 insertions(+), 5 deletions(-)

fs/udf/inode.c +3 -5

@@ -258,10 +258,6 @@ int udf_expand_file_adinicb(struct inode
 	char *kaddr;
 	struct udf_inode_info *iinfo = UDF_I(inode);
 	int err;
-	struct writeback_control udf_wbc = {
-		.sync_mode = WB_SYNC_NONE,
-		.nr_to_write = 1,
-	};
 
 	WARN_ON_ONCE(!inode_is_locked(inode));
 	if (!iinfo->i_lenAlloc) {

@@ -305,8 +301,10 @@ int udf_expand_file_adinicb(struct inode
 		iinfo->i_alloc_type = ICBTAG_FLAG_AD_LONG;
 	/* from now on we have normal address_space methods */
 	inode->i_data.a_ops = &udf_aops;
+	set_page_dirty(page);
+	unlock_page(page);
 	up_write(&iinfo->i_data_sem);
-	err = inode->i_data.a_ops->writepage(page, &udf_wbc);
+	err = filemap_fdatawrite(inode->i_mapping);
 	if (err) {
 		/* Restore everything back so that we don't lose data... */
 		lock_page(page);

Greg Kroah-Hartman

author maintainer

2022-01-31 11:12 UTC #19 lore raw

PATCH 19/171 efi: runtime: avoid EFIv2 runtime services on Apple x86 machines

[0] https://lore.kernel.org/all/[email protected]/

From: Ard Biesheuvel <[email protected]>

commit f5390cd0b43c2e54c7cf5506c7da4a37c5cef746 upstream.

Aditya reports [0] that his recent MacbookPro crashes in the firmware when using the variable services at runtime. The culprit appears to be a call to QueryVariableInfo(), which we did not use to call on Apple x86 machines in the past as they only upgraded from EFI v1.10 to EFI v2.40 firmware fairly recently, and QueryVariableInfo() (along with UpdateCapsule() et al) was added in EFI v2.00.

The only runtime service introduced in EFI v2.00 that we actually use in Linux is QueryVariableInfo(), as the capsule based ones are optional, generally not used at runtime (all the LVFS/fwupd firmware update infrastructure uses helper EFI programs that invoke capsule update at boot time, not runtime), and not implemented by Apple machines in the first place. QueryVariableInfo() is used to 'safely' set variables, i.e., only when there is enough space. This prevents machines with buggy firmwares from corrupting their NVRAMs when they run out of space.

Given that Apple machines have been using EFI v1.10 services only for the longest time (the EFI v2.0 spec was released in 2006, and Linux support for the newly introduced runtime services was added in 2011, but the MacbookPro12,1 released in 2015 still claims to be EFI v1.10 only), let's avoid the EFI v2.0 ones on all Apple x86 machines.

Cc Jeremy Kerr <[email protected]>

Cc Matthew Garrett <[email protected]>

Reported-by Aditya Garg <[email protected]>

Tested-by Orlando Chamberlain <[email protected]>

Link https://bugzilla.kernel.org/show_bug.cgi?id=215277

Tested-by Aditya Garg <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 drivers/firmware/efi/efi.c |    7 +++++++
 1 file changed, 7 insertions(+)

drivers/firmware/efi/efi.c +7 -0

@@ -719,6 +719,13 @@ void __init efi_systab_report_header(con
 		systab_hdr->revision >> 16,
 		systab_hdr->revision & 0xffff,
 		vendor);
+
+	if (IS_ENABLED(CONFIG_X86_64) &&
+	    systab_hdr->revision > EFI_1_10_SYSTEM_TABLE_REVISION &&
+	    !strcmp(vendor, "Apple")) {
+		pr_info("Apple Mac detected, using EFI v1.10 runtime services only\n");
+		efi.runtime_version = EFI_1_10_SYSTEM_TABLE_REVISION;
+	}
 }
 
 static __initdata char memory_type_name[][13] = {

Greg Kroah-Hartman

author maintainer

2022-01-31 11:11 UTC #20 lore raw

PATCH 20/171 PM: wakeup: simplify the output logic of pm_show_wakelocks()

From: Greg Kroah-Hartman <[email protected]>

commit c9d967b2ce40d71e968eb839f36c936b8a9cf1ea upstream.

The buffer handling in pm_show_wakelocks() is tricky, and hopefully correct. Ensure it really is correct by using sysfs_emit_at() which handles all of the tricky string handling logic in a PAGE_SIZE buffer for us automatically as this is a sysfs file being read from.

Reviewed-by Lee Jones <[email protected]>

Signed-off-by Rafael J. Wysocki <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 kernel/power/wakelock.c |   11 ++++-------
 1 file changed, 4 insertions(+), 7 deletions(-)

kernel/power/wakelock.c +4 -7

@@ -39,23 +39,20 @@ ssize_t pm_show_wakelocks(char *buf, boo
 {
 	struct rb_node *node;
 	struct wakelock *wl;
-	char *str = buf;
-	char *end = buf + PAGE_SIZE;
+	int len = 0;
 
 	mutex_lock(&wakelocks_lock);
 
 	for (node = rb_first(&wakelocks_tree); node; node = rb_next(node)) {
 		wl = rb_entry(node, struct wakelock, node);
 		if (wl->ws->active == show_active)
-			str += scnprintf(str, end - str, "%s ", wl->name);
+			len += sysfs_emit_at(buf, len, "%s ", wl->name);
 	}
-	if (str > buf)
-		str--;
 
-	str += scnprintf(str, end - str, "\n");
+	len += sysfs_emit_at(buf, len, "\n");
 
 	mutex_unlock(&wakelocks_lock);
-	return (str - buf);
+	return len;
 }
 
 #if CONFIG_PM_WAKELOCKS_LIMIT > 0

Greg Kroah-Hartman

author maintainer

2022-01-31 11:12 UTC #21 lore raw

PATCH 21/171 tracing/histogram: Fix a potential memory leak for kstrdup()

From: Xiaoke Wang <[email protected]>

commit e629e7b525a179e29d53463d992bdee759c950fb upstream.

kfree() is missing on an error path to free the memory allocated by kstrdup():

  p = param = kstrdup(data->params[i], GFP_KERNEL);

So it is better to free it via kfree(p).

Link https://lkml.kernel.org/r/[email protected] open here

Fixes d380dcde9a07c ("tracing: Fix now invalid var_ref_vals assumption in trace action")

Signed-off-by Xiaoke Wang <[email protected]>

Signed-off-by Steven Rostedt (Google) <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 kernel/trace/trace_events_hist.c |    1 +
 1 file changed, 1 insertion(+)

kernel/trace/trace_events_hist.c +1 -0

@@ -3581,6 +3581,7 @@ static int trace_action_create(struct hi
 
 			var_ref_idx = find_var_ref_idx(hist_data, var_ref);
 			if (WARN_ON(var_ref_idx < 0)) {
+				kfree(p);
 				ret = var_ref_idx;
 				goto err;
 			}

Greg Kroah-Hartman

author maintainer

2022-01-31 11:11 UTC #22 lore raw

PATCH 22/171 tracing: Dont inc err_log entry count if entry allocation fails

Link https://lkml.kernel.org/r/cad1ab28f75968db0f466925e7cba5970cec6c29.1643319703.git.zanussi@kernel.org open here

From: Tom Zanussi <[email protected]>

commit 67ab5eb71b37b55f7c5522d080a1b42823351776 upstream.

tr->n_err_log_entries should only be increased if entry allocation succeeds.

Doing it when it fails won't cause any problems other than wasting an entry, but should be fixed anyway.

Fixes 2f754e771b1a6 ("tracing: Don't inc err_log entry count if entry allocation fails")

Signed-off-by Tom Zanussi <[email protected]>

Signed-off-by Steven Rostedt (Google) <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 kernel/trace/trace.c |    3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

kernel/trace/trace.c +2 -1

@@ -7749,7 +7749,8 @@ static struct tracing_log_err *get_traci
 		err = kzalloc(sizeof(*err), GFP_KERNEL);
 		if (!err)
 			err = ERR_PTR(-ENOMEM);
-		tr->n_err_log_entries++;
+		else
+			tr->n_err_log_entries++;
 
 		return err;
 	}

Greg Kroah-Hartman

author maintainer

2022-01-31 11:12 UTC #23 lore raw

PATCH 23/171 ceph: properly put ceph_string reference after async create attempt

From: Jeff Layton <[email protected]>

commit 932a9b5870d38b87ba0a9923c804b1af7d3605b9 upstream.

The reference acquired by try_prep_async_create is currently leaked. Ensure we put it.

Fixes 9a8d03ca2e2c ("ceph: attempt to do async create when possible")

Signed-off-by Jeff Layton <[email protected]>

Reviewed-by Ilya Dryomov <[email protected]>

Signed-off-by Ilya Dryomov <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 fs/ceph/file.c |    2 ++
 1 file changed, 2 insertions(+)

fs/ceph/file.c +2 -0

@@ -744,8 +744,10 @@ retry:
 				restore_deleg_ino(dir, req->r_deleg_ino);
 				ceph_mdsc_put_request(req);
 				try_async = false;
+				ceph_put_string(rcu_dereference_raw(lo.pool_ns));
 				goto retry;
 			}
+			ceph_put_string(rcu_dereference_raw(lo.pool_ns));
 			goto out_req;
 		}
 	}

Greg Kroah-Hartman

author maintainer

2022-01-31 11:11 UTC #24 lore raw

PATCH 24/171 ceph: set pool_ns in new inode layout for async creates

From: Jeff Layton <[email protected]>

commit 4584a768f22b7669cdebabc911543621ac661341 upstream.

Dan reported that he was unable to write to files that had been asynchronously created when the client's OSD caps are restricted to a particular namespace.

The issue is that the layout for the new inode is only partially being filled. Ensure that we populate the pool_ns_data and pool_ns_len in the iinfo before calling ceph_fill_inode.

Cc: [email protected]
URL: https://tracker.ceph.com/issues/54013

Fixes 9a8d03ca2e2c ("ceph: attempt to do async create when possible")

Reported-by Dan van der Ster <[email protected]>

Signed-off-by Jeff Layton <[email protected]>

Reviewed-by Ilya Dryomov <[email protected]>

Signed-off-by Ilya Dryomov <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 fs/ceph/file.c |    7 +++++++
 1 file changed, 7 insertions(+)

fs/ceph/file.c +7 -0

@@ -577,6 +577,7 @@ static int ceph_finish_async_create(stru
 	struct ceph_inode_info *ci = ceph_inode(dir);
 	struct inode *inode;
 	struct timespec64 now;
+	struct ceph_string *pool_ns;
 	struct ceph_mds_client *mdsc = ceph_sb_to_mdsc(dir->i_sb);
 	struct ceph_vino vino = { .ino = req->r_deleg_ino,
 				  .snap = CEPH_NOSNAP };

@@ -626,6 +627,12 @@ static int ceph_finish_async_create(stru
 	in.max_size = cpu_to_le64(lo->stripe_unit);
 
 	ceph_file_layout_to_legacy(lo, &in.layout);
+	/* lo is private, so pool_ns can't change */
+	pool_ns = rcu_dereference_raw(lo->pool_ns);
+	if (pool_ns) {
+		iinfo.pool_ns_len = pool_ns->len;
+		iinfo.pool_ns_data = pool_ns->str;
+	}
 
 	down_read(&mdsc->snap_rwsem);
 	ret = ceph_fill_inode(inode, NULL, &iinfo, NULL, req->r_session,

Greg Kroah-Hartman

author maintainer

2022-01-31 11:12 UTC #25 lore raw

PATCH 25/171 fsnotify: fix fsnotify hooks in pseudo filesystems

Link https://lore.kernel.org/linux-fsdevel/YeNyzoDM5hP5LtGW@visor/ open here

From: Amir Goldstein <[email protected]>

commit 29044dae2e746949ad4b9cbdbfb248994d1dcdb4 upstream.

Commit 49246466a989 ("fsnotify: move fsnotify_nameremove() hook out of d_delete()") moved the fsnotify delete hook before d_delete() so fsnotify will have access to a positive dentry.

This allowed a race where opening the deleted file via cached dentry is now possible after receiving the IN_DELETE event.

To fix the regression in pseudo filesystems, convert d_delete() calls to d_drop() (see commit 46c46f8df9aa ("devpts_pty_kill(): don't bother with d_delete()") and move the fsnotify hook after d_drop().

Add a missing fsnotify_unlink() hook in nfsdfs that was found during the audit of fsnotify hooks in pseudo filesystems.

Note that the fsnotify hooks in simple_recursive_removal() follow d_invalidate(), so they require no change.

Link https://lore.kernel.org/r/[email protected] open here

Reported-by Ivan Delalande <[email protected]>

Fixes 49246466a989 ("fsnotify: move fsnotify_nameremove() hook out of d_delete()")

Cc [email protected] # v5.3+

Signed-off-by Amir Goldstein <[email protected]>

Signed-off-by Jan Kara <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 fs/configfs/dir.c     |    6 +++---
 fs/devpts/inode.c     |    2 +-
 fs/nfsd/nfsctl.c      |    5 +++--
 net/sunrpc/rpc_pipe.c |    4 ++--
 4 files changed, 9 insertions(+), 8 deletions(-)

fs/configfs/dir.c +3 -3

@@ -1780,8 +1780,8 @@ void configfs_unregister_group(struct co
 	configfs_detach_group(&group->cg_item);
 	d_inode(dentry)->i_flags |= S_DEAD;
 	dont_mount(dentry);
+	d_drop(dentry);
 	fsnotify_rmdir(d_inode(parent), dentry);
-	d_delete(dentry);
 	inode_unlock(d_inode(parent));
 
 	dput(dentry);

@@ -1922,10 +1922,10 @@ void configfs_unregister_subsystem(struc
 	configfs_detach_group(&group->cg_item);
 	d_inode(dentry)->i_flags |= S_DEAD;
 	dont_mount(dentry);
-	fsnotify_rmdir(d_inode(root), dentry);
 	inode_unlock(d_inode(dentry));
 
-	d_delete(dentry);
+	d_drop(dentry);
+	fsnotify_rmdir(d_inode(root), dentry);
 
 	inode_unlock(d_inode(root));

fs/devpts/inode.c +1 -1

@@ -621,8 +621,8 @@ void devpts_pty_kill(struct dentry *dent
 
 	dentry->d_fsdata = NULL;
 	drop_nlink(dentry->d_inode);
-	fsnotify_unlink(d_inode(dentry->d_parent), dentry);
 	d_drop(dentry);
+	fsnotify_unlink(d_inode(dentry->d_parent), dentry);
 	dput(dentry);	/* d_alloc_name() in devpts_pty_new() */
 }

fs/nfsd/nfsctl.c +3 -2

@@ -1249,7 +1249,8 @@ static void nfsdfs_remove_file(struct in
 	clear_ncl(d_inode(dentry));
 	dget(dentry);
 	ret = simple_unlink(dir, dentry);
-	d_delete(dentry);
+	d_drop(dentry);
+	fsnotify_unlink(dir, dentry);
 	dput(dentry);
 	WARN_ON_ONCE(ret);
 }

@@ -1340,8 +1341,8 @@ void nfsd_client_rmdir(struct dentry *de
 	dget(dentry);
 	ret = simple_rmdir(dir, dentry);
 	WARN_ON_ONCE(ret);
+	d_drop(dentry);
 	fsnotify_rmdir(dir, dentry);
-	d_delete(dentry);
 	dput(dentry);
 	inode_unlock(dir);
 }

net/sunrpc/rpc_pipe.c +2 -2

@@ -600,9 +600,9 @@ static int __rpc_rmdir(struct inode *dir
 
 	dget(dentry);
 	ret = simple_rmdir(dir, dentry);
+	d_drop(dentry);
 	if (!ret)
 		fsnotify_rmdir(dir, dentry);
-	d_delete(dentry);
 	dput(dentry);
 	return ret;
 }

@@ -613,9 +613,9 @@ static int __rpc_unlink(struct inode *di
 
 	dget(dentry);
 	ret = simple_unlink(dir, dentry);
+	d_drop(dentry);
 	if (!ret)
 		fsnotify_unlink(dir, dentry);
-	d_delete(dentry);
 	dput(dentry);
 	return ret;
 }

Greg Kroah-Hartman

author maintainer

2022-01-31 11:11 UTC #26 lore raw

PATCH 26/171 Revert "KVM: SVM: avoid infinite loop on NPF from bad address"

From: Sean Christopherson <[email protected]>

commit 31c25585695abdf03d6160aa6d829e855b256329 upstream.

Revert a completely broken check on an "invalid" RIP in SVM's workaround for the DecodeAssists SMAP errata. kvm_vcpu_gfn_to_memslot() obviously expects a gfn, i.e. operates in the guest physical address space, whereas RIP is a virtual (not even linear) address. The "fix" worked for the problematic KVM selftest because the test identity mapped RIP.

Fully revert the hack instead of trying to translate RIP to a GPA, as the non-SEV case is now handled earlier, and KVM cannot access guest page tables to translate RIP.

This reverts commit e72436bc3a5206f95bb384e741154166ddb3202e.

Fixes e72436bc3a52 ("KVM: SVM: avoid infinite loop on NPF from bad address")

Reported-by Liam Merwick <[email protected]>

Signed-off-by Sean Christopherson <[email protected]>

Reviewed-by Liam Merwick <[email protected]>

Message-Id: <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 arch/x86/kvm/svm/svm.c |    7 -------
 virt/kvm/kvm_main.c    |    1 -
 2 files changed, 8 deletions(-)

arch/x86/kvm/svm/svm.c +0 -7

@@ -4456,13 +4456,6 @@ static bool svm_can_emulate_instruction(
 	if (likely(!insn || insn_len))
 		return true;
 
-	/*
-	 * If RIP is invalid, go ahead with emulation which will cause an
-	 * internal error exit.
-	 */
-	if (!kvm_vcpu_gfn_to_memslot(vcpu, kvm_rip_read(vcpu) >> PAGE_SHIFT))
-		return true;
-
 	cr4 = kvm_read_cr4(vcpu);
 	smep = cr4 & X86_CR4_SMEP;
 	smap = cr4 & X86_CR4_SMAP;

virt/kvm/kvm_main.c +0 -1

@@ -2104,7 +2104,6 @@ struct kvm_memory_slot *kvm_vcpu_gfn_to_
 
 	return NULL;
 }
-EXPORT_SYMBOL_GPL(kvm_vcpu_gfn_to_memslot);
 
 bool kvm_is_visible_gfn(struct kvm *kvm, gfn_t gfn)
 {

Greg Kroah-Hartman

author maintainer

2022-01-31 11:11 UTC #27 lore raw

PATCH 27/171 psi: Fix uaf issue when psi trigger is destroyed while being polled

From: Suren Baghdasaryan <[email protected]>

commit a06247c6804f1a7c86a2e5398a4c1f1db1471848 upstream.

With write operation on psi files replacing old trigger with a new one, the lifetime of its waitqueue is totally arbitrary. Overwriting an existing trigger causes its waitqueue to be freed and pending poll() will stumble on trigger->event_wait which was destroyed.
Fix this by disallowing to redefine an existing psi trigger. If a write operation is used on a file descriptor with an already existing psi trigger, the operation will fail with EBUSY error.
Also bypass a check for psi_disabled in the psi_trigger_destroy as the flag can be flipped after the trigger is created, leading to a memory leak.

Fixes 0e94682b73bf ("psi: introduce psi monitor")

Reported-by [email protected]

Analyzed-by Eric Biggers <[email protected]>

Signed-off-by Suren Baghdasaryan <[email protected]>

Signed-off-by Peter Zijlstra (Intel) <[email protected]>

Reviewed-by Eric Biggers <[email protected]>

Acked-by Johannes Weiner <[email protected]>

Link https://lore.kernel.org/r/[email protected] open here

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 Documentation/accounting/psi.rst |    3 +
 include/linux/psi.h              |    2 -
 include/linux/psi_types.h        |    3 -
 kernel/cgroup/cgroup.c           |   11 ++++--
 kernel/sched/psi.c               |   66 +++++++++++++++++----------------------
 5 files changed, 40 insertions(+), 45 deletions(-)

Documentation/accounting/psi.rst +2 -1

@@ -92,7 +92,8 @@ Triggers can be set on more than one psi
 for the same psi metric can be specified. However for each trigger a separate
 file descriptor is required to be able to poll it separately from others,
 therefore for each trigger a separate open() syscall should be made even
-when opening the same psi interface file.
+when opening the same psi interface file. Write operations to a file descriptor
+with an already existing psi trigger will fail with EBUSY.
 
 Monitors activate only when system enters stall state for the monitored
 psi metric and deactivates upon exit from the stall state. While system is

include/linux/psi.h +1 -1

@@ -32,7 +32,7 @@ void cgroup_move_task(struct task_struct
 
 struct psi_trigger *psi_trigger_create(struct psi_group *group,
 			char *buf, size_t nbytes, enum psi_res res);
-void psi_trigger_replace(void **trigger_ptr, struct psi_trigger *t);
+void psi_trigger_destroy(struct psi_trigger *t);
 
 __poll_t psi_trigger_poll(void **trigger_ptr, struct file *file,
 			poll_table *wait);

include/linux/psi_types.h +0 -3

@@ -140,9 +140,6 @@ struct psi_trigger {
 	 * events to one per window
 	 */
 	u64 last_event_time;
-
-	/* Refcounting to prevent premature destruction */
-	struct kref refcount;
 };
 
 struct psi_group {

kernel/cgroup/cgroup.c +8 -3

@@ -3642,6 +3642,12 @@ static ssize_t cgroup_pressure_write(str
 	cgroup_get(cgrp);
 	cgroup_kn_unlock(of->kn);
 
+	/* Allow only one trigger per file descriptor */
+	if (ctx->psi.trigger) {
+		cgroup_put(cgrp);
+		return -EBUSY;
+	}
+
 	psi = cgroup_ino(cgrp) == 1 ? &psi_system : &cgrp->psi;
 	new = psi_trigger_create(psi, buf, nbytes, res);
 	if (IS_ERR(new)) {

@@ -3649,8 +3655,7 @@ static ssize_t cgroup_pressure_write(str
 		return PTR_ERR(new);
 	}
 
-	psi_trigger_replace(&ctx->psi.trigger, new);
-
+	smp_store_release(&ctx->psi.trigger, new);
 	cgroup_put(cgrp);
 
 	return nbytes;

@@ -3689,7 +3694,7 @@ static void cgroup_pressure_release(stru
 {
 	struct cgroup_file_ctx *ctx = of->priv;
 
-	psi_trigger_replace(&ctx->psi.trigger, NULL);
+	psi_trigger_destroy(ctx->psi.trigger);
 }
 
 bool cgroup_psi_enabled(void)

kernel/sched/psi.c +29 ~~-37~~

123 lines not on this page · raw message

Greg Kroah-Hartman

author maintainer

2022-01-31 11:12 UTC #28 lore raw

PATCH 28/171 powerpc/audit: Fix syscall_get_arch()

From: Christophe Leroy <[email protected]>

commit 252745240ba0ae774d2f80c5e185ed59fbc4fb41 upstream.

Commit 770cec16cdc9 ("powerpc/audit: Simplify syscall_get_arch()") and commit 898a1ef06ad4 ("powerpc/audit: Avoid unneccessary #ifdef in syscall_get_arguments()")
replaced test_tsk_thread_flag(task, TIF_32BIT)) by is_32bit_task().

But is_32bit_task() applies on current task while be want the test done on task 'task'

So add a new macro is_tsk_32bit_task() to check any task.

Fixes 770cec16cdc9 ("powerpc/audit: Simplify syscall_get_arch()")

Fixes 898a1ef06ad4 ("powerpc/audit: Avoid unneccessary #ifdef in syscall_get_arguments()")

Reported-by Dmitry V. Levin <[email protected]>

Link https://lore.kernel.org/r/c55cddb8f65713bf5859ed675d75a50cb37d5995.1642159570.git.christophe.leroy@csgroup.eu open here

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 arch/powerpc/include/asm/syscall.h     |    4 ++--
 arch/powerpc/include/asm/thread_info.h |    2 ++
 2 files changed, 4 insertions(+), 2 deletions(-)

arch/powerpc/include/asm/syscall.h +2 -2

@@ -90,7 +90,7 @@ static inline void syscall_get_arguments
 	unsigned long val, mask = -1UL;
 	unsigned int n = 6;
 
-	if (is_32bit_task())
+	if (is_tsk_32bit_task(task))
 		mask = 0xffffffff;
 
 	while (n--) {

@@ -115,7 +115,7 @@ static inline void syscall_set_arguments
 
 static inline int syscall_get_arch(struct task_struct *task)
 {
-	if (is_32bit_task())
+	if (is_tsk_32bit_task(task))
 		return AUDIT_ARCH_PPC;
 	else if (IS_ENABLED(CONFIG_CPU_LITTLE_ENDIAN))
 		return AUDIT_ARCH_PPC64LE;

arch/powerpc/include/asm/thread_info.h +2 -0

@@ -165,8 +165,10 @@ static inline bool test_thread_local_fla
 
 #ifdef CONFIG_COMPAT
 #define is_32bit_task()	(test_thread_flag(TIF_32BIT))
+#define is_tsk_32bit_task(tsk)	(test_tsk_thread_flag(tsk, TIF_32BIT))
 #else
 #define is_32bit_task()	(IS_ENABLED(CONFIG_PPC32))
+#define is_tsk_32bit_task(tsk)	(IS_ENABLED(CONFIG_PPC32))
 #endif
 
 #if defined(CONFIG_PPC64)

Greg Kroah-Hartman

author maintainer

2022-01-31 11:11 UTC #29 lore raw

PATCH 29/171 perf/x86/intel/uncore: Fix CAS_COUNT_WRITE issue for ICX

From: Zhengjun Xing <[email protected]>

commit 96fd2e89fba1aaada6f4b1e5d25a9d9ecbe1943d upstream.

The user recently report a perf issue in the ICX platform, when test by perf event “uncore_imc_x/cas_count_write”,the write bandwidth is always very small (only 0.38MB/s), it is caused by the wrong "umask" for the "cas_count_write" event. When double-checking, find "cas_count_read" also is wrong.

The public document for ICX uncore:

3rd Gen Intel® Xeon® Processor Scalable Family, Codename Ice Lake,Uncore Performance Monitoring Reference Manual, Revision 1.00, May 2021

On 2.4.7, it defines Unit Masks for CAS_COUNT:
RD b00001111
WR b00110000

So corrected both "cas_count_read" and "cas_count_write" for ICX.

Old settings:
hswep_uncore_imc_events

	INTEL_UNCORE_EVENT_DESC(cas_count_read,  "event=0x04,umask=0x03")
	INTEL_UNCORE_EVENT_DESC(cas_count_write, "event=0x04,umask=0x0c")

New settings:
snr_uncore_imc_events

	INTEL_UNCORE_EVENT_DESC(cas_count_read,  "event=0x04,umask=0x0f")
	INTEL_UNCORE_EVENT_DESC(cas_count_write, "event=0x04,umask=0x30")

Fixes 2b3b76b5ec67 ("perf/x86/intel/uncore: Add Ice Lake server uncore support")

Signed-off-by Zhengjun Xing <[email protected]>

Signed-off-by Peter Zijlstra (Intel) <[email protected]>

Reviewed-by Adrian Hunter <[email protected]>

Reviewed-by Kan Liang <[email protected]>

Link https://lkml.kernel.org/r/[email protected] open here

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 arch/x86/events/intel/uncore_snbep.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

arch/x86/events/intel/uncore_snbep.c +1 -1

@@ -5482,7 +5482,7 @@ static struct intel_uncore_type icx_unco
 	.fixed_ctr_bits	= 48,
 	.fixed_ctr	= SNR_IMC_MMIO_PMON_FIXED_CTR,
 	.fixed_ctl	= SNR_IMC_MMIO_PMON_FIXED_CTL,
-	.event_descs	= hswep_uncore_imc_events,
+	.event_descs	= snr_uncore_imc_events,
 	.perf_ctr	= SNR_IMC_MMIO_PMON_CTR0,
 	.event_ctl	= SNR_IMC_MMIO_PMON_CTL0,
 	.event_mask	= SNBEP_PMON_RAW_EVENT_MASK,

Greg Kroah-Hartman

author maintainer

2022-01-31 11:12 UTC #30 lore raw

PATCH 30/171 perf/x86/intel: Add a quirk for the calculation of the number of counters on Alder Lake

From: Kan Liang <[email protected]>

commit 7fa981cad216e9f64f49e22112f610c0bfed91bc upstream.

For some Alder Lake machine with all E-cores disabled in a BIOS, the below warning may be triggered.

[ 2.010766] hw perf events fixed 5 > max(4), clipping!

Current perf code relies on the CPUID leaf 0xA and leaf 7.EDX[15] to calculate the number of the counters and follow the below assumption.

For a hybrid configuration, the leaf 7.EDX[15] (X86_FEATURE_HYBRID_CPU) is set. The leaf 0xA only enumerate the common counters. Linux perf has to manually add the extra GP counters and fixed counters for P-cores. For a non-hybrid configuration, the X86_FEATURE_HYBRID_CPU should not be set. The leaf 0xA enumerates all counters.

However, that's not the case when all E-cores are disabled in a BIOS. Although there are only P-cores in the system, the leaf 7.EDX[15] (X86_FEATURE_HYBRID_CPU) is still set. But the leaf 0xA is updated to enumerate all counters of P-cores. The inconsistency triggers the warning.

Several software ways were considered to handle the inconsistency.
- Drop the leaf 0xA and leaf 7.EDX[15] CPUID enumeration support. Hardcode the number of counters. This solution may be a problem for virtualization. A hypervisor cannot control the number of counters in a Linux guest via changing the guest CPUID enumeration anymore.
- Find another CPUID bit that is also updated with E-cores disabled. There may be a problem in the virtualization environment too. Because a hypervisor may disable the feature/CPUID bit.
- The P-cores have a maximum of 8 GP counters and 4 fixed counters on ADL. The maximum number can be used to detect the case. This solution is implemented in this patch.

Fixes ee72a94ea4a6 ("perf/x86/intel: Fix fixed counter check warning for some Alder Lake")

Reported-by Damjan Marion (damarion) <[email protected]>

Reported-by Chan Edison <[email protected]>

Signed-off-by Kan Liang <[email protected]>

Signed-off-by Peter Zijlstra (Intel) <[email protected]>

Tested-by Damjan Marion (damarion) <[email protected]>

Link https://lkml.kernel.org/r/[email protected] open here

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 arch/x86/events/intel/core.c |   13 +++++++++++++
 1 file changed, 13 insertions(+)

arch/x86/events/intel/core.c +13 -0

@@ -6187,6 +6187,19 @@ __init int intel_pmu_init(void)
 			pmu->num_counters = x86_pmu.num_counters;
 			pmu->num_counters_fixed = x86_pmu.num_counters_fixed;
 		}
+
+		/*
+		 * Quirk: For some Alder Lake machine, when all E-cores are disabled in
+		 * a BIOS, the leaf 0xA will enumerate all counters of P-cores. However,
+		 * the X86_FEATURE_HYBRID_CPU is still set. The above codes will
+		 * mistakenly add extra counters for P-cores. Correct the number of
+		 * counters here.
+		 */
+		if ((pmu->num_counters > 8) || (pmu->num_counters_fixed > 4)) {
+			pmu->num_counters = x86_pmu.num_counters;
+			pmu->num_counters_fixed = x86_pmu.num_counters_fixed;
+		}
+
 		pmu->max_pebs_events = min_t(unsigned, MAX_PEBS_EVENTS, pmu->num_counters);
 		pmu->unconstrained = (struct event_constraint)
 					__EVENT_CONSTRAINT(0, (1ULL << pmu->num_counters) - 1,

Greg Kroah-Hartman

author maintainer

2022-01-31 11:12 UTC #31 lore raw

PATCH 31/171 drm/etnaviv: relax submit size limits

From: Lucas Stach <[email protected]>

commit e3d26528e083e612314d4dcd713f3d5a26143ddc upstream.

While all userspace tried to limit commandstreams to 64K in size, a bug in the Mesa driver lead to command streams of up to 128K being submitted. Allow those to avoid breaking existing userspace.

Fixes 6dfa2fab8ddd ("drm/etnaviv: limit submit sizes")

Signed-off-by Lucas Stach <[email protected]>

Reviewed-by Christian Gmeiner <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 drivers/gpu/drm/etnaviv/etnaviv_gem_submit.c |    4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

drivers/gpu/drm/etnaviv/etnaviv_gem_submit.c +2 -2

@@ -469,8 +469,8 @@ int etnaviv_ioctl_gem_submit(struct drm_
 		return -EINVAL;
 	}
 
-	if (args->stream_size > SZ_64K || args->nr_relocs > SZ_64K ||
-	    args->nr_bos > SZ_64K || args->nr_pmrs > 128) {
+	if (args->stream_size > SZ_128K || args->nr_relocs > SZ_128K ||
+	    args->nr_bos > SZ_128K || args->nr_pmrs > 128) {
 		DRM_ERROR("submit arguments out of size limits\n");
 		return -EINVAL;
 	}

Greg Kroah-Hartman

author maintainer

2022-01-31 11:09 UTC #32 lore raw

PATCH 32/171 drm/atomic: Add the crtc to affected crtc only if uapi.enable = true

From: Manasi Navare <[email protected]>

commit 5ec1cebd59300ddd26dbaa96c17c508764eef911 upstream.

In case of a modeset where a mode gets split across multiple CRTCs in the driver specific implementation (bigjoiner in i915) we wrongly count the affected CRTCs based on the drm_crtc_mask and indicate the stolen CRTC as an affected CRTC in atomic_check_only().
This triggers a warning since affected CRTCs doent match requested CRTC.

To fix this in such bigjoiner configurations, we should only increment affected crtcs if that CRTC is enabled in UAPI not if it is just used internally in the driver to split the mode.

v3: Add the same uapi crtc_state->enable check in requested crtc calc (Ville)

Cc Ville Syrjälä <[email protected]>

Cc Simon Ser <[email protected]>

Cc Pekka Paalanen <[email protected]>

Cc Daniel Stone <[email protected]>

Cc Daniel Vetter <[email protected]>

Link https://patchwork.freedesktop.org/patch/msgid/[email protected]

Cc <[email protected]> # v5.11+

Fixes 919c2299a893 ("drm/i915: Enable bigjoiner")

Signed-off-by Manasi Navare <[email protected]>

Reviewed-by Ville Syrjälä <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 drivers/gpu/drm/drm_atomic.c |   12 ++++++++----
 1 file changed, 8 insertions(+), 4 deletions(-)

drivers/gpu/drm/drm_atomic.c +8 -4

@@ -1310,8 +1310,10 @@ int drm_atomic_check_only(struct drm_ato
 
 	DRM_DEBUG_ATOMIC("checking %p\n", state);
 
-	for_each_new_crtc_in_state(state, crtc, new_crtc_state, i)
-		requested_crtc |= drm_crtc_mask(crtc);
+	for_each_new_crtc_in_state(state, crtc, new_crtc_state, i) {
+		if (new_crtc_state->enable)
+			requested_crtc |= drm_crtc_mask(crtc);
+	}
 
 	for_each_oldnew_plane_in_state(state, plane, old_plane_state, new_plane_state, i) {
 		ret = drm_atomic_plane_check(old_plane_state, new_plane_state);

@@ -1360,8 +1362,10 @@ int drm_atomic_check_only(struct drm_ato
 		}
 	}
 
-	for_each_new_crtc_in_state(state, crtc, new_crtc_state, i)
-		affected_crtc |= drm_crtc_mask(crtc);
+	for_each_new_crtc_in_state(state, crtc, new_crtc_state, i) {
+		if (new_crtc_state->enable)
+			affected_crtc |= drm_crtc_mask(crtc);
+	}
 
 	/*
 	 * For commits that allow modesets drivers can add other CRTCs to the

Greg Kroah-Hartman

author maintainer

2022-01-31 11:11 UTC #33 lore raw

PATCH 33/171 drm/amd/display: Fix FP start/end for dcn30_internal_validate_bw.

From: Bas Nieuwenhuizen <[email protected]>

commit 72a8d87b87270bff0c0b2fed4d59c48d0dd840d7 upstream.

It calls populate_dml_pipes which uses doubles to initialize the scale_ratio_depth params. Mirrors the dcn20 logic.

Signed-off-by Bas Nieuwenhuizen <[email protected]>

Signed-off-by Alex Deucher <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 drivers/gpu/drm/amd/display/dc/dcn30/dcn30_resource.c |    4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

drivers/gpu/drm/amd/display/dc/dcn30/dcn30_resource.c +2 -2

@@ -1879,7 +1879,6 @@ static noinline bool dcn30_internal_vali
 	dc->res_pool->funcs->update_soc_for_wm_a(dc, context);
 	pipe_cnt = dc->res_pool->funcs->populate_dml_pipes(dc, context, pipes, fast_validate);
 
-	DC_FP_START();
 	if (!pipe_cnt) {
 		out = true;
 		goto validate_out;

@@ -2103,7 +2102,6 @@ validate_fail:
 	out = false;
 
 validate_out:
-	DC_FP_END();
 	return out;
 }

@@ -2304,7 +2302,9 @@ bool dcn30_validate_bandwidth(struct dc
 
 	BW_VAL_TRACE_COUNT();
 
+	DC_FP_START();
 	out = dcn30_internal_validate_bw(dc, context, pipes, &pipe_cnt, &vlevel, fast_validate);
+	DC_FP_END();
 
 	if (pipe_cnt == 0)
 		goto validate_out;

Greg Kroah-Hartman

author maintainer

2022-01-31 11:11 UTC #34 lore raw

PATCH 34/171 KVM: LAPIC: Also cancel preemption timer during SET_LAPIC

From: Wanpeng Li <[email protected]>

commit 35fe7cfbab2e81f1afb23fc4212210b1de6d9633 upstream.

The below warning is splatting during guest reboot.

  ------------[ cut here ]------------
  WARNING: CPU: 0 PID: 1931 at arch/x86/kvm/x86.c:10322 kvm_arch_vcpu_ioctl_run+0x874/0x880 [kvm]
  CPU: 0 PID: 1931 Comm: qemu-system-x86 Tainted: G          I       5.17.0-rc1+ #5
  RIP: 0010:kvm_arch_vcpu_ioctl_run+0x874/0x880 [kvm]
  Call Trace:
   <TASK>
   kvm_vcpu_ioctl+0x279/0x710 [kvm]
   __x64_sys_ioctl+0x83/0xb0
   do_syscall_64+0x3b/0xc0
   entry_SYSCALL_64_after_hwframe+0x44/0xae
  RIP: 0033:0x7fd39797350b

This can be triggered by not exposing tsc-deadline mode and doing a reboot in the guest. The lapic_shutdown() function which is called in sys_reboot path will not disarm the flying timer, it just masks LVTT. lapic_shutdown() clears APIC state w/ LVT_MASKED and timer-mode bit is 0, this can trigger timer-mode switch between tsc-deadline and oneshot/periodic, which can result in preemption timer be cancelled in apic_update_lvtt(). However, We can't depend on this when not exposing tsc-deadline mode and oneshot/periodic modes emulated by preemption timer. Qemu will synchronise states around reset, let's cancel preemption timer under KVM_SET_LAPIC.

Signed-off-by Wanpeng Li <[email protected]>

Message-Id: <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 arch/x86/kvm/lapic.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

arch/x86/kvm/lapic.c +1 -1

@@ -2623,7 +2623,7 @@ int kvm_apic_set_state(struct kvm_vcpu *
 	kvm_apic_set_version(vcpu);
 
 	apic_update_ppr(apic);
-	hrtimer_cancel(&apic->lapic_timer.timer);
+	cancel_apic_timer(apic);
 	apic->lapic_timer.expired_tscdeadline = 0;
 	apic_update_lvtt(apic);
 	apic_manage_nmi_watchdog(apic, kvm_lapic_get_reg(apic, APIC_LVT0));

Greg Kroah-Hartman

author maintainer

2022-01-31 11:11 UTC #35 lore raw

PATCH 35/171 KVM: SVM: Never reject emulation due to SMAP errata for !SEV guests

From: Sean Christopherson <[email protected]>

commit 55467fcd55b89c622e62b4afe60ac0eb2fae91f2 upstream.

Always signal that emulation is possible for !SEV guests regardless of whether or not the CPU provided a valid instruction byte stream. KVM can read all guest state (memory and registers) for !SEV guests, i.e. can fetch the code stream from memory even if the CPU failed to do so because of the SMAP errata.

Fixes 05d5a4863525 ("KVM: SVM: Workaround errata#1096 (insn_len maybe zero on SMAP violation)")

Cc Tom Lendacky <[email protected]>

Cc Brijesh Singh <[email protected]>

Signed-off-by Sean Christopherson <[email protected]>

Reviewed-by Liam Merwick <[email protected]>

Message-Id: <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 arch/x86/kvm/svm/svm.c |   10 ++++++----
 1 file changed, 6 insertions(+), 4 deletions(-)

arch/x86/kvm/svm/svm.c +6 -4

@@ -4407,8 +4407,13 @@ static bool svm_can_emulate_instruction(
 	bool smep, smap, is_user;
 	unsigned long cr4;
 
+	/* Emulation is always possible when KVM has access to all guest state. */
+	if (!sev_guest(vcpu->kvm))
+		return true;
+
 	/*
-	 * When the guest is an SEV-ES guest, emulation is not possible.
+	 * Emulation is impossible for SEV-ES guests as KVM doesn't have access
+	 * to guest register state.
 	 */
 	if (sev_es_guest(vcpu->kvm))
 		return false;

@@ -4461,9 +4466,6 @@ static bool svm_can_emulate_instruction(
 	smap = cr4 & X86_CR4_SMAP;
 	is_user = svm_get_cpl(vcpu) == 3;
 	if (smap && (!smep || is_user)) {
-		if (!sev_guest(vcpu->kvm))
-			return true;
-
 		pr_err_ratelimited("KVM: SEV Guest triggered AMD Erratum 1096\n");
 		kvm_make_request(KVM_REQ_TRIPLE_FAULT, vcpu);
 	}

Greg Kroah-Hartman

author maintainer

2022-01-31 11:11 UTC #36 lore raw

PATCH 36/171 KVM: SVM: Dont intercept #GP for SEV guests

From: Sean Christopherson <[email protected]>

commit 0b0be065b7563ac708aaa9f69dd4941c80b3446d upstream.

Never intercept #GP for SEV guests as reading SEV guest private memory will return cyphertext, i.e. emulating on #GP can't work as intended.

Cc Tom Lendacky <[email protected]>

Cc Brijesh Singh <[email protected]>

Signed-off-by Sean Christopherson <[email protected]>

Reviewed-by Liam Merwick <[email protected]>

Message-Id: <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 arch/x86/kvm/svm/svm.c |   11 ++++++++---
 1 file changed, 8 insertions(+), 3 deletions(-)

arch/x86/kvm/svm/svm.c +8 -3

@@ -303,7 +303,11 @@ int svm_set_efer(struct kvm_vcpu *vcpu,
 				return ret;
 			}
 
-			if (svm_gp_erratum_intercept)
+			/*
+			 * Never intercept #GP for SEV guests, KVM can't
+			 * decrypt guest memory to workaround the erratum.
+			 */
+			if (svm_gp_erratum_intercept && !sev_guest(vcpu->kvm))
 				set_exception_intercept(svm, GP_VECTOR);
 		}
 	}

@@ -1176,9 +1180,10 @@ static void init_vmcb(struct kvm_vcpu *v
 	 * Guest access to VMware backdoor ports could legitimately
 	 * trigger #GP because of TSS I/O permission bitmap.
 	 * We intercept those #GP and allow access to them anyway
-	 * as VMware does.
+	 * as VMware does.  Don't intercept #GP for SEV guests as KVM can't
+	 * decrypt guest memory to decode the faulting instruction.
 	 */
-	if (enable_vmware_backdoor)
+	if (enable_vmware_backdoor && !sev_guest(vcpu->kvm))
 		set_exception_intercept(svm, GP_VECTOR);
 
 	svm_set_intercept(svm, INTERCEPT_INTR);

Greg Kroah-Hartman

author maintainer

2022-01-31 11:12 UTC #37 lore raw

PATCH 37/171 KVM: x86: nSVM: skip eax alignment check for non-SVM instructions

From: Denis Valeev <[email protected]>

commit 47c28d436f409f5b009dc82bd82d4971088aa391 upstream.

The bug occurs on #GP triggered by VMware backdoor when eax value is unaligned. eax alignment check should not be applied to non-SVM instructions because it leads to incorrect omission of the instructions emulation.
Apply the alignment check only to SVM instructions to fix.

Fixes d1cba6c92237 ("KVM: x86: nSVM: test eax for 4K alignment for GP errata workaround")

Signed-off-by Denis Valeev <[email protected]>

Message-Id: <Yexlhaoe1Fscm59u@q>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 arch/x86/kvm/svm/svm.c |   11 ++++++-----
 1 file changed, 6 insertions(+), 5 deletions(-)

arch/x86/kvm/svm/svm.c +6 -5

@@ -2238,10 +2238,6 @@ static int gp_interception(struct kvm_vc
 	if (error_code)
 		goto reinject;
 
-	/* All SVM instructions expect page aligned RAX */
-	if (svm->vmcb->save.rax & ~PAGE_MASK)
-		goto reinject;
-
 	/* Decode the instruction for usage later */
 	if (x86_decode_emulated_instruction(vcpu, 0, NULL, 0) != EMULATION_OK)
 		goto reinject;

@@ -2259,8 +2255,13 @@ static int gp_interception(struct kvm_vc
 		if (!is_guest_mode(vcpu))
 			return kvm_emulate_instruction(vcpu,
 				EMULTYPE_VMWARE_GP | EMULTYPE_NO_DECODE);
-	} else
+	} else {
+		/* All SVM instructions expect page aligned RAX */
+		if (svm->vmcb->save.rax & ~PAGE_MASK)
+			goto reinject;
+
 		return emulate_svm_instr(vcpu, opcode);
+	}
 
 reinject:
 	kvm_queue_exception_e(vcpu, GP_VECTOR, error_code);

Greg Kroah-Hartman

author maintainer

2022-01-31 11:12 UTC #38 lore raw

PATCH 38/171 KVM: x86: Forcibly leave nested virt when SMM state is toggled

From: Sean Christopherson <[email protected]>

commit f7e570780efc5cec9b2ed1e0472a7da14e864fdb upstream.

Forcibly leave nested virtualization operation if userspace toggles SMM state via KVM_SET_VCPU_EVENTS or KVM_SYNC_X86_EVENTS. If userspace forces the vCPU out of SMM while it's post-VMXON and then injects an SMI, vmx_enter_smm() will overwrite vmx->nested.smm.vmxon and end up with both vmxon=false and smm.vmxon=false, but all other nVMX state allocated.

Don't attempt to gracefully handle the transition as (a) most transitions are nonsencial, e.g. forcing SMM while L2 is running, (b) there isn't sufficient information to handle all transitions, e.g. SVM wants access to the SMRAM save state, and (c) KVM_SET_VCPU_EVENTS must precede KVM_SET_NESTED_STATE during state restore as the latter disallows putting the vCPU into L2 if SMM is active, and disallows tagging the vCPU as being post-VMXON in SMM if SMM is not active.

Abuse of KVM_SET_VCPU_EVENTS manifests as a WARN and memory leak in nVMX due to failure to free vmcs01's shadow VMCS, but the bug goes far beyond just a memory leak, e.g. toggling SMM on while L2 is active puts the vCPU in an architecturally impossible state.

  WARNING: CPU: 0 PID: 3606 at free_loaded_vmcs arch/x86/kvm/vmx/vmx.c:2665 [inline]
  WARNING: CPU: 0 PID: 3606 at free_loaded_vmcs+0x158/0x1a0 arch/x86/kvm/vmx/vmx.c:2656
  Modules linked in:
  CPU: 1 PID: 3606 Comm: syz-executor725 Not tainted 5.17.0-rc1-syzkaller #0
  Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
  RIP: 0010:free_loaded_vmcs arch/x86/kvm/vmx/vmx.c:2665 [inline]
  RIP: 0010:free_loaded_vmcs+0x158/0x1a0 arch/x86/kvm/vmx/vmx.c:2656
  Code: <0f> 0b eb b3 e8 8f 4d 9f 00 e9 f7 fe ff ff 48 89 df e8 92 4d 9f 00
  Call Trace:
   <TASK>
   kvm_arch_vcpu_destroy+0x72/0x2f0 arch/x86/kvm/x86.c:11123
   kvm_vcpu_destroy arch/x86/kvm/../../../virt/kvm/kvm_main.c:441 [inline]
   kvm_destroy_vcpus+0x11f/0x290 arch/x86/kvm/../../../virt/kvm/kvm_main.c:460
   kvm_free_vcpus arch/x86/kvm/x86.c:11564 [inline]
   kvm_arch_destroy_vm+0x2e8/0x470 arch/x86/kvm/x86.c:11676
   kvm_destroy_vm arch/x86/kvm/../../../virt/kvm/kvm_main.c:1217 [inline]
   kvm_put_kvm+0x4fa/0xb00 arch/x86/kvm/../../../virt/kvm/kvm_main.c:1250
   kvm_vm_release+0x3f/0x50 arch/x86/kvm/../../../virt/kvm/kvm_main.c:1273
   __fput+0x286/0x9f0 fs/file_table.c:311
   task_work_run+0xdd/0x1a0 kernel/task_work.c:164
   exit_task_work include/linux/task_work.h:32 [inline]
   do_exit+0xb29/0x2a30 kernel/exit.c:806
   do_group_exit+0xd2/0x2f0 kernel/exit.c:935
   get_signal+0x4b0/0x28c0 kernel/signal.c:2862
   arch_do_signal_or_restart+0x2a9/0x1c40 arch/x86/kernel/signal.c:868
   handle_signal_work kernel/entry/common.c:148 [inline]
   exit_to_user_mode_loop kernel/entry/common.c:172 [inline]
   exit_to_user_mode_prepare+0x17d/0x290 kernel/entry/common.c:207
   __syscall_exit_to_user_mode_work kernel/entry/common.c:289 [inline]
   syscall_exit_to_user_mode+0x19/0x60 kernel/entry/common.c:300
   do_syscall_64+0x42/0xb0 arch/x86/entry/common.c:86
   entry_SYSCALL_64_after_hwframe+0x44/0xae
   </TASK>

Reported-by [email protected]

Signed-off-by Sean Christopherson <[email protected]>

Message-Id: <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 arch/x86/include/asm/kvm_host.h |    1 +
 arch/x86/kvm/svm/nested.c       |    9 +++++----
 arch/x86/kvm/svm/svm.c          |    2 +-
 arch/x86/kvm/svm/svm.h          |    2 +-
 arch/x86/kvm/vmx/nested.c       |    1 +
 arch/x86/kvm/x86.c              |    4 +++-
 6 files changed, 12 insertions(+), 7 deletions(-)

arch/x86/include/asm/kvm_host.h +1 -0

@@ -1487,6 +1487,7 @@ struct kvm_x86_ops {
 };
 
 struct kvm_x86_nested_ops {
+	void (*leave_nested)(struct kvm_vcpu *vcpu);
 	int (*check_events)(struct kvm_vcpu *vcpu);
 	bool (*hv_timer_pending)(struct kvm_vcpu *vcpu);
 	void (*triple_fault)(struct kvm_vcpu *vcpu);

arch/x86/kvm/svm/nested.c +5 -4

@@ -942,9 +942,9 @@ void svm_free_nested(struct vcpu_svm *sv
 /*
  * Forcibly leave nested mode in order to be able to reset the VCPU later on.
  */
-void svm_leave_nested(struct vcpu_svm *svm)
+void svm_leave_nested(struct kvm_vcpu *vcpu)
 {
-	struct kvm_vcpu *vcpu = &svm->vcpu;
+	struct vcpu_svm *svm = to_svm(vcpu);
 
 	if (is_guest_mode(vcpu)) {
 		svm->nested.nested_run_pending = 0;

@@ -1313,7 +1313,7 @@ static int svm_set_nested_state(struct k
 		return -EINVAL;
 
 	if (!(kvm_state->flags & KVM_STATE_NESTED_GUEST_MODE)) {
-		svm_leave_nested(svm);
+		svm_leave_nested(vcpu);
 		svm_set_gif(svm, !!(kvm_state->flags & KVM_STATE_NESTED_GIF_SET));
 		return 0;
 	}

@@ -1378,7 +1378,7 @@ static int svm_set_nested_state(struct k
 	 */
 
 	if (is_guest_mode(vcpu))
-		svm_leave_nested(svm);
+		svm_leave_nested(vcpu);
 	else
 		svm->nested.vmcb02.ptr->save = svm->vmcb01.ptr->save;

@@ -1432,6 +1432,7 @@ static bool svm_get_nested_state_pages(s
 }
 
 struct kvm_x86_nested_ops svm_nested_ops = {
+	.leave_nested = svm_leave_nested,
 	.check_events = svm_check_nested_events,
 	.triple_fault = nested_svm_triple_fault,
 	.get_nested_state_pages = svm_get_nested_state_pages,

arch/x86/kvm/svm/svm.c +1 -1

@@ -281,7 +281,7 @@ int svm_set_efer(struct kvm_vcpu *vcpu,
 
 	if ((old_efer & EFER_SVME) != (efer & EFER_SVME)) {
 		if (!(efer & EFER_SVME)) {
-			svm_leave_nested(svm);
+			svm_leave_nested(vcpu);
 			svm_set_gif(svm, true);
 			/* #GP intercept is still needed for vmware backdoor */
 			if (!enable_vmware_backdoor)

arch/x86/kvm/svm/svm.h +1 -1

@@ -461,7 +461,7 @@ static inline bool nested_exit_on_nmi(st
 
 int enter_svm_guest_mode(struct kvm_vcpu *vcpu,
 			 u64 vmcb_gpa, struct vmcb *vmcb12, bool from_vmrun);
-void svm_leave_nested(struct vcpu_svm *svm);
+void svm_leave_nested(struct kvm_vcpu *vcpu);
 void svm_free_nested(struct vcpu_svm *svm);
 int svm_allocate_nested(struct vcpu_svm *svm);
 int nested_svm_vmrun(struct kvm_vcpu *vcpu);

arch/x86/kvm/vmx/nested.c +1 -0

@@ -6748,6 +6748,7 @@ __init int nested_vmx_hardware_setup(int
 }
 
 struct kvm_x86_nested_ops vmx_nested_ops = {
+	.leave_nested = vmx_leave_nested,
 	.check_events = vmx_check_nested_events,
 	.hv_timer_pending = nested_vmx_preemption_timer_pending,
 	.triple_fault = nested_vmx_triple_fault,

arch/x86/kvm/x86.c +3 -1

@@ -4727,8 +4727,10 @@ static int kvm_vcpu_ioctl_x86_set_vcpu_e
 		vcpu->arch.apic->sipi_vector = events->sipi_vector;
 
 	if (events->flags & KVM_VCPUEVENT_VALID_SMM) {
-		if (!!(vcpu->arch.hflags & HF_SMM_MASK) != events->smi.smm)
+		if (!!(vcpu->arch.hflags & HF_SMM_MASK) != events->smi.smm) {
+			kvm_x86_ops.nested_ops->leave_nested(vcpu);
 			kvm_smm_changed(vcpu, events->smi.smm);
+		}
 
 		vcpu->arch.smi_pending = events->smi.pending;

Greg Kroah-Hartman

author maintainer

2022-01-31 11:11 UTC #39 lore raw

PATCH 39/171 KVM: x86: Keep MSR_IA32_XSS unchanged for INIT

From: Xiaoyao Li <[email protected]>

commit be4f3b3f82271c3193ce200a996dc70682c8e622 upstream.

It has been corrected from SDM version 075 that MSR_IA32_XSS is reset to zero on Power up and Reset but keeps unchanged on INIT.

Fixes a554d207dc46 ("KVM: X86: Processor States following Reset or INIT")

Signed-off-by Xiaoyao Li <[email protected]>

Signed-off-by Sean Christopherson <[email protected]>

Message-Id: <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 arch/x86/kvm/x86.c |    3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

arch/x86/kvm/x86.c +1 -2

@@ -10990,6 +10990,7 @@ void kvm_vcpu_reset(struct kvm_vcpu *vcp
 		vcpu->arch.msr_misc_features_enables = 0;
 
 		vcpu->arch.xcr0 = XFEATURE_MASK_FP;
+		vcpu->arch.ia32_xss = 0;
 	}
 
 	memset(vcpu->arch.regs, 0, sizeof(vcpu->arch.regs));

@@ -11008,8 +11009,6 @@ void kvm_vcpu_reset(struct kvm_vcpu *vcp
 		eax = 0x600;
 	kvm_rdx_write(vcpu, eax);
 
-	vcpu->arch.ia32_xss = 0;
-
 	static_call(kvm_x86_vcpu_reset)(vcpu, init_event);
 
 	kvm_set_rflags(vcpu, X86_EFLAGS_FIXED);

Greg Kroah-Hartman

author maintainer

2022-01-31 11:12 UTC #40 lore raw

PATCH 40/171 KVM: x86: Update vCPUs runtime CPUID on write to MSR_IA32_XSS

From: Like Xu <[email protected]>

commit 4c282e51e4450b94680d6ca3b10f830483b1f243 upstream.

Do a runtime CPUID update for a vCPU if MSR_IA32_XSS is written, as the size in bytes of the XSAVE area is affected by the states enabled in XSS.

Fixes 203000993de5 ("kvm: vmx: add MSR logic for XSAVES")

Signed-off-by Like Xu <[email protected]>

[sean: split out as a separate patch, adjust Fixes tag]

Signed-off-by Sean Christopherson <[email protected]>

Message-Id: <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 arch/x86/kvm/x86.c |    1 +
 1 file changed, 1 insertion(+)

arch/x86/kvm/x86.c +1 -0

@@ -3453,6 +3453,7 @@ int kvm_set_msr_common(struct kvm_vcpu *
 		if (data & ~supported_xss)
 			return 1;
 		vcpu->arch.ia32_xss = data;
+		kvm_update_cpuid_runtime(vcpu);
 		break;
 	case MSR_SMI_COUNT:
 		if (!msr_info->host_initiated)

Greg Kroah-Hartman

author maintainer

2022-01-31 11:11 UTC #41 lore raw

PATCH 41/171 KVM: x86: Sync the states size with the XCR0/IA32_XSS at, any time

From: Like Xu <[email protected]>

commit 05a9e065059e566f218f8778c4d17ee75db56c55 upstream.

XCR0 is reset to 1 by RESET but not INIT and IA32_XSS is zeroed by both RESET and INIT. The kvm_set_msr_common()'s handling of MSR_IA32_XSS also needs to update kvm_update_cpuid_runtime(). In the above cases, the size in bytes of the XSAVE area containing all states enabled by XCR0 or (XCRO | IA32_XSS) needs to be updated.

For simplicity and consistency, existing helpers are used to write values and call kvm_update_cpuid_runtime(), and it's not exactly a fast path.

Fixes a554d207dc46 ("KVM: X86: Processor States following Reset or INIT")

Signed-off-by Like Xu <[email protected]>

Signed-off-by Sean Christopherson <[email protected]>

Message-Id: <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 arch/x86/kvm/x86.c |    4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

arch/x86/kvm/x86.c +2 -2

@@ -10990,8 +10990,8 @@ void kvm_vcpu_reset(struct kvm_vcpu *vcp
 
 		vcpu->arch.msr_misc_features_enables = 0;
 
-		vcpu->arch.xcr0 = XFEATURE_MASK_FP;
-		vcpu->arch.ia32_xss = 0;
+		__kvm_set_xcr(vcpu, 0, XFEATURE_MASK_FP);
+		__kvm_set_msr(vcpu, MSR_IA32_XSS, 0, true);
 	}
 
 	memset(vcpu->arch.regs, 0, sizeof(vcpu->arch.regs));

Greg Kroah-Hartman

author maintainer

2022-01-31 11:11 UTC #42 lore raw

PATCH 42/171 KVM: PPC: Book3S HV Nested: Fix nested HFSCR being clobbered with multiple vCPUs

From: Nicholas Piggin <[email protected]>

commit 22f7ff0dea9491e90b6fe808ed40c30bd791e5c2 upstream.

The L0 is storing HFSCR requested by the L1 for the L2 in struct kvm_nested_guest when the L1 requests a vCPU enter L2. kvm_nested_guest is not a per-vCPU structure. Hilarity ensues.

Fix it by moving the nested hfscr into the vCPU structure together with the other per-vCPU nested fields.

Fixes 8b210a880b35 ("KVM: PPC: Book3S HV Nested: Make nested HFSCR state accessible")

Cc [email protected] # v5.15+

Signed-off-by Nicholas Piggin <[email protected]>

Reviewed-by Fabiano Rosas <[email protected]>

Link https://lore.kernel.org/r/[email protected] open here

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 arch/powerpc/include/asm/kvm_book3s_64.h |    1 -
 arch/powerpc/include/asm/kvm_host.h      |    1 +
 arch/powerpc/kvm/book3s_hv.c             |    3 +--
 arch/powerpc/kvm/book3s_hv_nested.c      |    2 +-
 4 files changed, 3 insertions(+), 4 deletions(-)

arch/powerpc/include/asm/kvm_book3s_64.h +0 -1

@@ -39,7 +39,6 @@ struct kvm_nested_guest {
 	pgd_t *shadow_pgtable;		/* our page table for this guest */
 	u64 l1_gr_to_hr;		/* L1's addr of part'n-scoped table */
 	u64 process_table;		/* process table entry for this guest */
-	u64 hfscr;			/* HFSCR that the L1 requested for this nested guest */
 	long refcnt;			/* number of pointers to this struct */
 	struct mutex tlb_lock;		/* serialize page faults and tlbies */
 	struct kvm_nested_guest *next;

arch/powerpc/include/asm/kvm_host.h +1 -0

@@ -814,6 +814,7 @@ struct kvm_vcpu_arch {
 
 	/* For support of nested guests */
 	struct kvm_nested_guest *nested;
+	u64 nested_hfscr;	/* HFSCR that the L1 requested for the nested guest */
 	u32 nested_vcpu_id;
 	gpa_t nested_io_gpr;
 #endif

arch/powerpc/kvm/book3s_hv.c +1 -2

@@ -1731,7 +1731,6 @@ static int kvmppc_handle_exit_hv(struct
 
 static int kvmppc_handle_nested_exit(struct kvm_vcpu *vcpu)
 {
-	struct kvm_nested_guest *nested = vcpu->arch.nested;
 	int r;
 	int srcu_idx;

@@ -1831,7 +1830,7 @@ static int kvmppc_handle_nested_exit(str
 		 * it into a HEAI.
 		 */
 		if (!(vcpu->arch.hfscr_permitted & (1UL << cause)) ||
-					(nested->hfscr & (1UL << cause))) {
+				(vcpu->arch.nested_hfscr & (1UL << cause))) {
 			vcpu->arch.trap = BOOK3S_INTERRUPT_H_EMUL_ASSIST;
 
 			/*

arch/powerpc/kvm/book3s_hv_nested.c +1 -1

@@ -362,7 +362,7 @@ long kvmhv_enter_nested_guest(struct kvm
 	/* set L1 state to L2 state */
 	vcpu->arch.nested = l2;
 	vcpu->arch.nested_vcpu_id = l2_hv.vcpu_token;
-	l2->hfscr = l2_hv.hfscr;
+	vcpu->arch.nested_hfscr = l2_hv.hfscr;
 	vcpu->arch.regs = l2_regs;
 
 	/* Guest must always run with ME enabled, HV disabled. */

Greg Kroah-Hartman

author maintainer

2022-01-31 11:11 UTC #43 lore raw

PATCH 43/171 dm: revert partial fix for redundant bio-based IO accounting

From: Mike Snitzer <[email protected]>

commit f524d9c95fab54783d0038f7a3e8c014d5b56857 upstream.

Reverts a1e1cb72d9649 ("dm: fix redundant IO accounting for bios that need splitting") because it was too narrow in scope (only addressed redundant 'sectors[]' accounting and not ios, nsecs[], etc).

Signed-off-by Mike Snitzer <[email protected]>

Link https://lore.kernel.org/r/[email protected] open here

Signed-off-by Jens Axboe <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 drivers/md/dm.c |   15 ---------------
 1 file changed, 15 deletions(-)

drivers/md/dm.c +0 ~~-15~~

@@ -1514,9 +1514,6 @@ static void init_clone_info(struct clone
 	ci->sector = bio->bi_iter.bi_sector;
 }
 
-#define __dm_part_stat_sub(part, field, subnd)	\
-	(part_stat_get(part, field) -= (subnd))
-
 /*
  * Entry point to split a bio into clones and submit them to the targets.
  */

@@ -1553,18 +1550,6 @@ static blk_qc_t __split_and_process_bio(
 						  GFP_NOIO, &md->queue->bio_split);
 			ci.io->orig_bio = b;
 
-			/*
-			 * Adjust IO stats for each split, otherwise upon queue
-			 * reentry there will be redundant IO accounting.
-			 * NOTE: this is a stop-gap fix, a proper fix involves
-			 * significant refactoring of DM core's bio splitting
-			 * (by eliminating DM's splitting and just using bio_split)
-			 */
-			part_stat_lock();
-			__dm_part_stat_sub(dm_disk(md)->part0,
-					   sectors[op_stat_group(bio_op(bio))], ci.sector_count);
-			part_stat_unlock();
-
 			bio_chain(b, bio);
 			trace_block_split(b, bio->bi_iter.bi_sector);
 			ret = submit_bio_noacct(bio);

Greg Kroah-Hartman

author maintainer

2022-01-31 11:12 UTC #44 lore raw

PATCH 44/171 block: add bio_start_io_acct_time() to control start_time

From: Mike Snitzer <[email protected]>

commit e45c47d1f94e0cc7b6b079fdb4bcce2995e2adc4 upstream.

bio_start_io_acct_time() interface is like bio_start_io_acct() that allows start_time to be passed in. This gives drivers the ability to defer starting accounting until after IO is issued (but possibily not entirely due to bio splitting).

Signed-off-by Mike Snitzer <[email protected]>

Link https://lore.kernel.org/r/[email protected] open here

Signed-off-by Jens Axboe <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 block/blk-core.c       |   25 +++++++++++++++++++------
 include/linux/blkdev.h |    1 +
 2 files changed, 20 insertions(+), 6 deletions(-)

block/blk-core.c +19 -6

@@ -1293,22 +1293,34 @@ void blk_account_io_start(struct request
 }
 
 static unsigned long __part_start_io_acct(struct block_device *part,
-					  unsigned int sectors, unsigned int op)
+					  unsigned int sectors, unsigned int op,
+					  unsigned long start_time)
 {
 	const int sgrp = op_stat_group(op);
-	unsigned long now = READ_ONCE(jiffies);
 
 	part_stat_lock();
-	update_io_ticks(part, now, false);
+	update_io_ticks(part, start_time, false);
 	part_stat_inc(part, ios[sgrp]);
 	part_stat_add(part, sectors[sgrp], sectors);
 	part_stat_local_inc(part, in_flight[op_is_write(op)]);
 	part_stat_unlock();
 
-	return now;
+	return start_time;
 }
 
 /**
+ * bio_start_io_acct_time - start I/O accounting for bio based drivers
+ * @bio:	bio to start account for
+ * @start_time:	start time that should be passed back to bio_end_io_acct().
+ */
+void bio_start_io_acct_time(struct bio *bio, unsigned long start_time)
+{
+	__part_start_io_acct(bio->bi_bdev, bio_sectors(bio),
+			     bio_op(bio), start_time);
+}
+EXPORT_SYMBOL_GPL(bio_start_io_acct_time);
+
+/**
  * bio_start_io_acct - start I/O accounting for bio based drivers
  * @bio:	bio to start account for
  *

@@ -1316,14 +1328,15 @@ static unsigned long __part_start_io_acc
  */
 unsigned long bio_start_io_acct(struct bio *bio)
 {
-	return __part_start_io_acct(bio->bi_bdev, bio_sectors(bio), bio_op(bio));
+	return __part_start_io_acct(bio->bi_bdev, bio_sectors(bio),
+				    bio_op(bio), jiffies);
 }
 EXPORT_SYMBOL_GPL(bio_start_io_acct);
 
 unsigned long disk_start_io_acct(struct gendisk *disk, unsigned int sectors,
 				 unsigned int op)
 {
-	return __part_start_io_acct(disk->part0, sectors, op);
+	return __part_start_io_acct(disk->part0, sectors, op, jiffies);
 }
 EXPORT_SYMBOL(disk_start_io_acct);

include/linux/blkdev.h +1 -0

@@ -1947,6 +1947,7 @@ unsigned long disk_start_io_acct(struct
 void disk_end_io_acct(struct gendisk *disk, unsigned int op,
 		unsigned long start_time);
 
+void bio_start_io_acct_time(struct bio *bio, unsigned long start_time);
 unsigned long bio_start_io_acct(struct bio *bio);
 void bio_end_io_acct_remapped(struct bio *bio, unsigned long start_time,
 		struct block_device *orig_bdev);

Greg Kroah-Hartman

author maintainer

2022-01-31 11:11 UTC #45 lore raw

PATCH 45/171 dm: properly fix redundant bio-based IO accounting

From: Mike Snitzer <[email protected]>

commit b879f915bc48a18d4f4462729192435bb0f17052 upstream.

Record the start_time for a bio but defer the starting block core's IO accounting until after IO is submitted using bio_start_io_acct_time().

This approach avoids the need to mess around with any of the individual IO stats in response to a bio_split() that follows bio submission.

Reported-by Bud Brown <[email protected]>

Depends-on: e45c47d1f94e ("block: add bio_start_io_acct_time() to control start_time")

Signed-off-by Mike Snitzer <[email protected]>

Link https://lore.kernel.org/r/[email protected] open here

Signed-off-by Jens Axboe <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 drivers/md/dm.c |    5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

drivers/md/dm.c +3 -2

@@ -489,7 +489,7 @@ static void start_io_acct(struct dm_io *
 	struct mapped_device *md = io->md;
 	struct bio *bio = io->orig_bio;
 
-	io->start_time = bio_start_io_acct(bio);
+	bio_start_io_acct_time(bio, io->start_time);
 	if (unlikely(dm_stats_used(&md->stats)))
 		dm_stats_account_io(&md->stats, bio_data_dir(bio),
 				    bio->bi_iter.bi_sector, bio_sectors(bio),

@@ -535,7 +535,7 @@ static struct dm_io *alloc_io(struct map
 	io->md = md;
 	spin_lock_init(&io->endio_lock);
 
-	start_io_acct(io);
+	io->start_time = jiffies;
 
 	return io;
 }

@@ -1555,6 +1555,7 @@ static blk_qc_t __split_and_process_bio(
 			ret = submit_bio_noacct(bio);
 		}
 	}
+	start_io_acct(ci.io);
 
 	/* drop the extra reference count */
 	dm_io_dec_pending(ci.io, errno_to_blk_status(error));

Greg Kroah-Hartman

author maintainer

2022-01-31 11:11 UTC #46 lore raw

PATCH 46/171 serial: pl011: Fix incorrect rs485 RTS polarity on set_mctrl

Link https://lore.kernel.org/r/85fa3323ba8c307943969b7343e23f34c3e652ba.1642909284.git.lukas@wunner.de open here

From: Jochen Mades <[email protected]>

commit 62f676ff7898f6c1bd26ce014564773a3dc00601 upstream.

Commit 8d479237727c ("serial: amba-pl011: add RS485 support") sought to keep RTS deasserted on set_mctrl if rs485 is enabled. However it did so only if deasserted RTS polarity is high. Fix it in case it's low.

Fixes 8d479237727c ("serial: amba-pl011: add RS485 support")

Cc [email protected] # v5.15+

Cc Lino Sanfilippo <[email protected]>

Signed-off-by Jochen Mades <[email protected]>

[lukas: copyedit commit message, add stable designation]

Signed-off-by Lukas Wunner <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 drivers/tty/serial/amba-pl011.c |    8 ++++++--
 1 file changed, 6 insertions(+), 2 deletions(-)

drivers/tty/serial/amba-pl011.c +6 -2

@@ -1615,8 +1615,12 @@ static void pl011_set_mctrl(struct uart_
 	    container_of(port, struct uart_amba_port, port);
 	unsigned int cr;
 
-	if (port->rs485.flags & SER_RS485_ENABLED)
-		mctrl &= ~TIOCM_RTS;
+	if (port->rs485.flags & SER_RS485_ENABLED) {
+		if (port->rs485.flags & SER_RS485_RTS_AFTER_SEND)
+			mctrl &= ~TIOCM_RTS;
+		else
+			mctrl |= TIOCM_RTS;
+	}
 
 	cr = pl011_read(uap, REG_CR);

Greg Kroah-Hartman

author maintainer

2022-01-31 11:11 UTC #47 lore raw

PATCH 47/171 serial: 8250: of: Fix mapped region size when using reg-offset property

From: Robert Hancock <[email protected]>

commit d06b1cf28297e27127d3da54753a3a01a2fa2f28 upstream.

8250_of supports a reg-offset property which is intended to handle cases where the device registers start at an offset inside the region of memory allocated to the device. The Xilinx 16550 UART, for which this support was initially added, requires this. However, the code did not adjust the overall size of the mapped region accordingly, causing the driver to request an area of memory past the end of the device's allocation. For example, if the UART was allocated an address of 0xb0130000, size of 0x10000 and reg-offset of 0x1000 in the device tree, the region of memory reserved was b0131000-b0140fff, which caused the driver for the region starting at b0140000 to fail to probe.

Fix this by subtracting reg-offset from the mapped region size.

Fixes b912b5e2cfb3 ([POWERPC] Xilinx: of_serial support for Xilinx uart 16550.)

Cc stable <[email protected]>

Link https://lore.kernel.org/r/[email protected] open here

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 drivers/tty/serial/8250/8250_of.c |   11 ++++++++++-
 1 file changed, 10 insertions(+), 1 deletion(-)

drivers/tty/serial/8250/8250_of.c +10 -1

@@ -83,8 +83,17 @@ static int of_platform_serial_setup(stru
 		port->mapsize = resource_size(&resource);
 
 		/* Check for shifted address mapping */
-		if (of_property_read_u32(np, "reg-offset", &prop) == 0)
+		if (of_property_read_u32(np, "reg-offset", &prop) == 0) {
+			if (prop >= port->mapsize) {
+				dev_warn(&ofdev->dev, "reg-offset %u exceeds region size %pa\n",
+					 prop, &port->mapsize);
+				ret = -EINVAL;
+				goto err_unprepare;
+			}
+
 			port->mapbase += prop;
+			port->mapsize -= prop;
+		}
 
 		port->iotype = UPIO_MEM;
 		if (of_property_read_u32(np, "reg-io-width", &prop) == 0) {

Greg Kroah-Hartman

author maintainer

2022-01-31 11:11 UTC #48 lore raw

PATCH 48/171 serial: stm32: fix software flow control transfer

From: Valentin Caron <[email protected]>

commit 037b91ec7729524107982e36ec4b40f9b174f7a2 upstream.

x_char is ignored by stm32_usart_start_tx() when xmit buffer is empty.

Fix start_tx condition to allow x_char to be sent.

Fixes 48a6092fb41f ("serial: stm32-usart: Add STM32 USART Driver")

Cc stable <[email protected]>

Signed-off-by Erwan Le Ray <[email protected]>

Signed-off-by Valentin Caron <[email protected]>

Link https://lore.kernel.org/r/[email protected] open here

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 drivers/tty/serial/stm32-usart.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

drivers/tty/serial/stm32-usart.c +1 -1

@@ -575,7 +575,7 @@ static void stm32_usart_start_tx(struct
 	struct serial_rs485 *rs485conf = &port->rs485;
 	struct circ_buf *xmit = &port->state->xmit;
 
-	if (uart_circ_empty(xmit))
+	if (uart_circ_empty(xmit) && !port->x_char)
 		return;
 
 	if (rs485conf->flags & SER_RS485_ENABLED) {

Greg Kroah-Hartman

author maintainer

2022-01-31 11:12 UTC #49 lore raw

PATCH 49/171 tty: n_gsm: fix SW flow control encoding/handling

From: [email protected] <[email protected]>

commit 8838b2af23caf1ff0610caef2795d6668a013b2d upstream.

n_gsm is based on the 3GPP 07.010 and its newer version is the 3GPP 27.010.
See https://portal.3gpp.org/desktopmodules/Specifications/SpecificationDetails.aspx?specificationId=1516
The changes from 07.010 to 27.010 are non-functional. Therefore, I refer to
the newer 27.010 here. Chapter 5.2.7.3 states that DC1 (XON) and DC3 (XOFF)
are the control characters defined in ISO/IEC 646. These shall be quoted if
seen in the data stream to avoid interpretation as flow control characters.

ISO/IEC 646 refers to the set of ISO standards described as the ISO 7-bit coded character set for information interchange. Its final version is also known as ITU T.50.
See https://www.itu.int/rec/T-REC-T.50-199209-I/en

To abide the standard it is needed to quote DC1 and DC3 correctly if these are seen as data bytes and not as control characters. The current implementation already tries to enforce this but fails to catch all defined cases. 3GPP 27.010 chapter 5.2.7.3 clearly states that the most significant bit shall be ignored for DC1 and DC3 handling. The current implementation handles only the case with the most significant bit set 0. Cases in which DC1 and DC3 have the most significant bit set 1 are left unhandled.

This patch fixes this by masking the data bytes with ISO_IEC_646_MASK (only the 7 least significant bits set 1) before comparing them with XON (a.k.a. DC1) and XOFF (a.k.a. DC3) when testing which byte values need quotation via byte stuffing.

Fixes e1eaea46bb40 ("tty: n_gsm line discipline")

Signed-off-by Daniel Starke <[email protected]>

Link https://lore.kernel.org/r/[email protected] open here

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 drivers/tty/n_gsm.c |    4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

drivers/tty/n_gsm.c +3 -1

@@ -318,6 +318,7 @@ static struct tty_driver *gsm_tty_driver
 #define GSM1_ESCAPE_BITS	0x20
 #define XON			0x11
 #define XOFF			0x13
+#define ISO_IEC_646_MASK	0x7F
 
 static const struct tty_port_operations gsm_port_ops;

@@ -527,7 +528,8 @@ static int gsm_stuff_frame(const u8 *inp
 	int olen = 0;
 	while (len--) {
 		if (*input == GSM1_SOF || *input == GSM1_ESCAPE
-		    || *input == XON || *input == XOFF) {
+		    || (*input & ISO_IEC_646_MASK) == XON
+		    || (*input & ISO_IEC_646_MASK) == XOFF) {
 			*output++ = GSM1_ESCAPE;
 			*output++ = *input++ ^ GSM1_ESCAPE_BITS;
 			olen++;

Greg Kroah-Hartman

author maintainer

2022-01-31 11:11 UTC #50 lore raw

PATCH 50/171 tty: Partially revert the removal of the Cyclades public API

From: Maciej W. Rozycki <[email protected]>

commit f23653fe64479d96910bfda2b700b1af17c991ac upstream.

Fix a user API regression introduced with commit f76edd8f7ce0 ("tty:
cyclades, remove this orphan"), which removed a part of the API and caused compilation errors for user programs using said part, such as GCC 9 in its libsanitizer component[1]:

.../libsanitizer/sanitizer_common/sanitizer_platform_limits_posix.cc:160:10: fatal error: linux/cyclades.h: No such file or directory
160 | #include <linux/cyclades.h>

      |          ^~~~~~~~~~~~~~~~~~

compilation terminated.
make[4]: *** [Makefile:664: sanitizer_platform_limits_posix.lo] Error 1

As the absolute minimum required bring `struct cyclades_monitor' and ioctl numbers back then so as to make the library build again. Add a preprocessor warning as to the obsolescence of the features provided.

[1] GCC PR sanitizer/100379, "cyclades.h is removed from linux kernel

    header files", <https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100379>

Fixes f76edd8f7ce0 ("tty: cyclades, remove this orphan")

Cc [email protected] # v5.13+

Signed-off-by Maciej W. Rozycki <[email protected]>

Link https://lore.kernel.org/r/[email protected] open here

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 include/uapi/linux/cyclades.h |   35 +++++++++++++++++++++++++++++++++++
 1 file changed, 35 insertions(+)
 create mode 100644 include/uapi/linux/cyclades.h

include/uapi/linux/cyclades.h new file +35 -0

@@ -0,0 +1,35 @@
+/* SPDX-License-Identifier: GPL-2.0 WITH Linux-syscall-note */
+
+#ifndef _UAPI_LINUX_CYCLADES_H
+#define _UAPI_LINUX_CYCLADES_H
+
+#warning "Support for features provided by this header has been removed"
+#warning "Please consider updating your code"
+
+struct cyclades_monitor {
+	unsigned long int_count;
+	unsigned long char_count;
+	unsigned long char_max;
+	unsigned long char_last;
+};
+
+#define CYGETMON		0x435901
+#define CYGETTHRESH		0x435902
+#define CYSETTHRESH		0x435903
+#define CYGETDEFTHRESH		0x435904
+#define CYSETDEFTHRESH		0x435905
+#define CYGETTIMEOUT		0x435906
+#define CYSETTIMEOUT		0x435907
+#define CYGETDEFTIMEOUT		0x435908
+#define CYSETDEFTIMEOUT		0x435909
+#define CYSETRFLOW		0x43590a
+#define CYGETRFLOW		0x43590b
+#define CYSETRTSDTR_INV		0x43590c
+#define CYGETRTSDTR_INV		0x43590d
+#define CYZSETPOLLCYCLE		0x43590e
+#define CYZGETPOLLCYCLE		0x43590f
+#define CYGETCD1400VER		0x435910
+#define CYSETWAIT		0x435912
+#define CYGETWAIT		0x435913
+
+#endif /* _UAPI_LINUX_CYCLADES_H */

Greg Kroah-Hartman

author maintainer

2022-01-31 11:11 UTC #51 lore raw

PATCH 51/171 tty: Add support for Brainboxes UC cards.

Link https://lore.kernel.org/r/AM5PR0202MB2564688493F7DD9B9C610827C45E9@AM5PR0202MB2564.eurprd02.prod.outlook.com open here

From: Cameron Williams <[email protected]>

commit 152d1afa834c84530828ee031cf07a00e0fc0b8c upstream.

This commit adds support for the some of the Brainboxes PCI range of cards, including the UC-101, UC-235/246, UC-257, UC-268, UC-275/279, UC-302, UC-310, UC-313, UC-320/324, UC-346, UC-357, UC-368 and UC-420/431.

Signed-off-by Cameron Williams <[email protected]>

Cc stable <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 drivers/tty/serial/8250/8250_pci.c |  100 ++++++++++++++++++++++++++++++++++++-
 1 file changed, 98 insertions(+), 2 deletions(-)

drivers/tty/serial/8250/8250_pci.c +98 -2

@@ -5203,8 +5203,30 @@ static const struct pci_device_id serial
 	{	PCI_VENDOR_ID_INTASHIELD, PCI_DEVICE_ID_INTASHIELD_IS400,
 		PCI_ANY_ID, PCI_ANY_ID, 0, 0,    /* 135a.0dc0 */
 		pbn_b2_4_115200 },
+	/* Brainboxes Devices */
 	/*
-	 * BrainBoxes UC-260
+	* Brainboxes UC-101
+	*/
+	{       PCI_VENDOR_ID_INTASHIELD, 0x0BA1,
+		PCI_ANY_ID, PCI_ANY_ID,
+		0, 0,
+		pbn_b2_2_115200 },
+	/*
+	 * Brainboxes UC-235/246
+	 */
+	{	PCI_VENDOR_ID_INTASHIELD, 0x0AA1,
+		PCI_ANY_ID, PCI_ANY_ID,
+		0, 0,
+		pbn_b2_1_115200 },
+	/*
+	 * Brainboxes UC-257
+	 */
+	{	PCI_VENDOR_ID_INTASHIELD, 0x0861,
+		PCI_ANY_ID, PCI_ANY_ID,
+		0, 0,
+		pbn_b2_2_115200 },
+	/*
+	 * Brainboxes UC-260/271/701/756
 	 */
 	{	PCI_VENDOR_ID_INTASHIELD, 0x0D21,
 		PCI_ANY_ID, PCI_ANY_ID,

@@ -5212,7 +5234,81 @@ static const struct pci_device_id serial
 		pbn_b2_4_115200 },
 	{	PCI_VENDOR_ID_INTASHIELD, 0x0E34,
 		PCI_ANY_ID, PCI_ANY_ID,
-		 PCI_CLASS_COMMUNICATION_MULTISERIAL << 8, 0xffff00,
+		PCI_CLASS_COMMUNICATION_MULTISERIAL << 8, 0xffff00,
+		pbn_b2_4_115200 },
+	/*
+	 * Brainboxes UC-268
+	 */
+	{       PCI_VENDOR_ID_INTASHIELD, 0x0841,
+		PCI_ANY_ID, PCI_ANY_ID,
+		0, 0,
+		pbn_b2_4_115200 },
+	/*
+	 * Brainboxes UC-275/279
+	 */
+	{	PCI_VENDOR_ID_INTASHIELD, 0x0881,
+		PCI_ANY_ID, PCI_ANY_ID,
+		0, 0,
+		pbn_b2_8_115200 },
+	/*
+	 * Brainboxes UC-302
+	 */
+	{	PCI_VENDOR_ID_INTASHIELD, 0x08E1,
+		PCI_ANY_ID, PCI_ANY_ID,
+		0, 0,
+		pbn_b2_2_115200 },
+	/*
+	 * Brainboxes UC-310
+	 */
+	{       PCI_VENDOR_ID_INTASHIELD, 0x08C1,
+		PCI_ANY_ID, PCI_ANY_ID,
+		0, 0,
+		pbn_b2_2_115200 },
+	/*
+	 * Brainboxes UC-313
+	 */
+	{       PCI_VENDOR_ID_INTASHIELD, 0x08A3,
+		PCI_ANY_ID, PCI_ANY_ID,
+		0, 0,
+		pbn_b2_2_115200 },
+	/*
+	 * Brainboxes UC-320/324
+	 */
+	{	PCI_VENDOR_ID_INTASHIELD, 0x0A61,
+		PCI_ANY_ID, PCI_ANY_ID,
+		0, 0,
+		pbn_b2_1_115200 },
+	/*
+	 * Brainboxes UC-346
+	 */
+	{	PCI_VENDOR_ID_INTASHIELD, 0x0B02,
+		PCI_ANY_ID, PCI_ANY_ID,
+		0, 0,
+		pbn_b2_4_115200 },
+	/*
+	 * Brainboxes UC-357
+	 */
+	{	PCI_VENDOR_ID_INTASHIELD, 0x0A81,
+		PCI_ANY_ID, PCI_ANY_ID,
+		0, 0,
+		pbn_b2_2_115200 },
+	{	PCI_VENDOR_ID_INTASHIELD, 0x0A83,
+		PCI_ANY_ID, PCI_ANY_ID,
+		0, 0,
+		pbn_b2_2_115200 },
+	/*
+	 * Brainboxes UC-368
+	 */
+	{	PCI_VENDOR_ID_INTASHIELD, 0x0C41,
+		PCI_ANY_ID, PCI_ANY_ID,
+		0, 0,
+		pbn_b2_4_115200 },
+	/*
+	 * Brainboxes UC-420/431
+	 */
+	{       PCI_VENDOR_ID_INTASHIELD, 0x0921,
+		PCI_ANY_ID, PCI_ANY_ID,
+		0, 0,
 		pbn_b2_4_115200 },
 	/*
 	 * Perle PCI-RAS cards

Greg Kroah-Hartman

author maintainer

2022-01-31 11:11 UTC #52 lore raw

PATCH 52/171 kbuild: remove include/linux/cyclades.h from header file check

From: Greg Kroah-Hartman <[email protected]>

commit d1ad2721b1eb05d54e81393a7ebc332d4a35c68f upstream.

The file now rightfully throws up a big warning that it should never be included, so remove it from the header_check test.

Fixes f23653fe6447 ("tty: Partially revert the removal of the Cyclades public API")

Cc stable <[email protected]>

Cc Masahiro Yamada <[email protected]>

Cc "Maciej W. Rozycki" <[email protected]>

Reported-by Stephen Rothwell <[email protected]>

Reported-by kernel test robot <[email protected]>

Link https://lore.kernel.org/r/[email protected] open here

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 usr/include/Makefile |    1 +
 1 file changed, 1 insertion(+)

usr/include/Makefile +1 -0

@@ -28,6 +28,7 @@ no-header-test += linux/am437x-vpfe.h
 no-header-test += linux/android/binder.h
 no-header-test += linux/android/binderfs.h
 no-header-test += linux/coda.h
+no-header-test += linux/cyclades.h
 no-header-test += linux/errqueue.h
 no-header-test += linux/fsmap.h
 no-header-test += linux/hdlc/ioctl.h

Greg Kroah-Hartman

author maintainer

2022-01-31 11:12 UTC #53 lore raw

PATCH 53/171 usb-storage: Add unusual-devs entry for VL817 USB-SATA bridge

From: Alan Stern <[email protected]>

commit 5b67b315037250a61861119683e7fcb509deea25 upstream.

Two people have reported (and mentioned numerous other reports on the web) that VIA's VL817 USB-SATA bridge does not work with the uas driver. Typical log messages are:

[ 3606.232149] sd 14:0:0:0: [sdg] tag#2 uas_zap_pending 0 uas-tag 1 inflight: CMD
[ 3606.232154] sd 14:0:0:0: [sdg] tag#2 CDB: Write(16) 8a 00 00 00 00 00 18 0c c9 80 00 00 00 80 00 00
[ 3606.306257] usb 4-4.4: reset SuperSpeed Plus Gen 2x1 USB device number 11 using xhci_hcd
[ 3606.328584] scsi host14: uas_eh_device_reset_handler success

Surprisingly, the devices do seem to work okay for some other people. The cause of the differing behaviors is not known.

In the hope of getting the devices to work for the most users, even at the possible cost of degraded performance for some, this patch adds an unusual_devs entry for the VL817 to block it from binding to the uas driver by default. Users will be able to override this entry by means of a module parameter, if they want.

CC <[email protected]>

Reported-by DocMAX <[email protected]>

Reported-and-tested-by Thomas Weißschuh <[email protected]>

Signed-off-by Alan Stern <[email protected]>

Link https://lore.kernel.org/r/[email protected] open here

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 drivers/usb/storage/unusual_devs.h |   10 ++++++++++
 1 file changed, 10 insertions(+)

drivers/usb/storage/unusual_devs.h +10 -0

@@ -2301,6 +2301,16 @@ UNUSUAL_DEV(  0x2027, 0xa001, 0x0000, 0x
 		USB_SC_DEVICE, USB_PR_DEVICE, usb_stor_euscsi_init,
 		US_FL_SCM_MULT_TARG ),
 
+/*
+ * Reported by DocMAX <[email protected]>
+ * and Thomas Weißschuh <[email protected]>
+ */
+UNUSUAL_DEV( 0x2109, 0x0715, 0x9999, 0x9999,
+		"VIA Labs, Inc.",
+		"VL817 SATA Bridge",
+		USB_SC_DEVICE, USB_PR_DEVICE, NULL,
+		US_FL_IGNORE_UAS),
+
 UNUSUAL_DEV( 0x2116, 0x0320, 0x0001, 0x0001,
 		"ST",
 		"2A",

Greg Kroah-Hartman

author maintainer

2022-01-31 11:11 UTC #54 lore raw

PATCH 54/171 usb: xhci-plat: fix crash when suspend if remote wake enable

From: Frank Li <[email protected]>

commit 9df478463d9feb90dae24f183383961cf123a0ec upstream.

Crashed at i.mx8qm platform when suspend if enable remote wakeup

Internal error: synchronous external abort: 96000210 [#1] PREEMPT SMP
Modules linked in:
CPU: 2 PID: 244 Comm: kworker/u12:6 Not tainted 5.15.5-dirty #12
Hardware name: Freescale i.MX8QM MEK (DT)
Workqueue: events_unbound async_run_entry_fn
pstate: 600000c5 (nZCv daIF -PAN -UAO -TCO -DIT -SSBS BTYPE=--)
pc : xhci_disable_hub_port_wake.isra.62+0x60/0xf8
lr : xhci_disable_hub_port_wake.isra.62+0x34/0xf8

sp : ffff80001394bbf0
x29: ffff80001394bbf0 x28: 0000000000000000 x27: ffff00081193b578
x26: ffff00081193b570 x25: 0000000000000000 x24: 0000000000000000
x23: ffff00081193a29c x22: 0000000000020001 x21: 0000000000000001
x20: 0000000000000000 x19: ffff800014e90490 x18: 0000000000000000
x17: 0000000000000000 x16: 0000000000000000 x15: 0000000000000000
x14: 0000000000000000 x13: 0000000000000002 x12: 0000000000000000
x11: 0000000000000000 x10: 0000000000000960 x9 : ffff80001394baa0 x8 : ffff0008145d1780 x7 : ffff0008f95b8e80 x6 : 000000001853b453 x5 : 0000000000000496 x4 : 0000000000000000 x3 : ffff00081193a29c x2 : 0000000000000001 x1 : 0000000000000000 x0 : ffff000814591620

Call trace:
 xhci_disable_hub_port_wake.isra.62+0x60/0xf8
 xhci_suspend+0x58/0x510
 xhci_plat_suspend+0x50/0x78
 platform_pm_suspend+0x2c/0x78
 dpm_run_callback.isra.25+0x50/0xe8
 __device_suspend+0x108/0x3c0

The basic flow:
1. run time suspend call xhci_suspend, xhci parent devices gate the clock.
2. echo mem >/sys/power/state, system _device_suspend call xhci_suspend
3. xhci_suspend call xhci_disable_hub_port_wake, which access register, but clock already gated by run time suspend.

This problem was hidden by power domain driver, which call run time resume before it.

But the below commit remove it and make this issue happen.
commit c1df456d0f06e ("PM: domains: Don't runtime resume devices at genpd_prepare()")

This patch call run time resume before suspend to make sure clock is on before access register.

Reviewed-by Peter Chen <[email protected]>

Cc stable <[email protected]>

Signed-off-by Frank Li <[email protected]>

Testeb-by Abel Vesa <[email protected]>

Link https://lore.kernel.org/r/[email protected] open here

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 drivers/usb/host/xhci-plat.c |    3 +++
 1 file changed, 3 insertions(+)

drivers/usb/host/xhci-plat.c +3 -0

@@ -437,6 +437,9 @@ static int __maybe_unused xhci_plat_susp
 	struct xhci_hcd	*xhci = hcd_to_xhci(hcd);
 	int ret;
 
+	if (pm_runtime_suspended(dev))
+		pm_runtime_resume(dev);
+
 	ret = xhci_priv_suspend_quirk(hcd);
 	if (ret)
 		return ret;

Greg Kroah-Hartman

author maintainer

2022-01-31 11:12 UTC #55 lore raw

PATCH 55/171 usb: common: ulpi: Fix crash in ulpi_match()

From: Jon Hunter <[email protected]>

commit 2e3dd4a6246945bf84ea6f478365d116e661554c upstream.

Commit 7495af930835 ("ARM: multi_v7_defconfig: Enable drivers for DragonBoard 410c") enables the CONFIG_PHY_QCOM_USB_HS for the ARM multi_v7_defconfig. Enabling this Kconfig is causing the kernel to crash on the Tegra20 Ventana platform in the ulpi_match() function.

The Qualcomm USB HS PHY driver that is enabled by CONFIG_PHY_QCOM_USB_HS, registers a ulpi_driver but this driver does not provide an 'id_table', so when ulpi_match() is called on the Tegra20 Ventana platform, it crashes when attempting to deference the id_table pointer which is not valid. The Qualcomm USB HS PHY driver uses device-tree for matching the ULPI driver with the device and so fix this crash by using device-tree for matching if the id_table is not valid.

Fixes ef6a7bcfb01c ("usb: ulpi: Support device discovery via DT")

Cc stable <[email protected]>

Signed-off-by Jon Hunter <[email protected]>

Link https://lore.kernel.org/r/[email protected] open here

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 drivers/usb/common/ulpi.c |    7 +++++--
 1 file changed, 5 insertions(+), 2 deletions(-)

drivers/usb/common/ulpi.c +5 -2

@@ -39,8 +39,11 @@ static int ulpi_match(struct device *dev
 	struct ulpi *ulpi = to_ulpi_dev(dev);
 	const struct ulpi_device_id *id;
 
-	/* Some ULPI devices don't have a vendor id so rely on OF match */
-	if (ulpi->id.vendor == 0)
+	/*
+	 * Some ULPI devices don't have a vendor id
+	 * or provide an id_table so rely on OF match.
+	 */
+	if (ulpi->id.vendor == 0 || !drv->id_table)
 		return of_driver_match_device(dev, driver);
 
 	for (id = drv->id_table; id->vendor; id++)

Greg Kroah-Hartman

author maintainer

2022-01-31 11:11 UTC #56 lore raw

PATCH 56/171 usb: gadget: f_sourcesink: Fix isoc transfer for USB_SPEED_SUPER_PLUS

From: Pavankumar Kondeti <[email protected]>

commit 904edf8aeb459697129be5fde847e2a502f41fd9 upstream.

Currently when gadget enumerates in super speed plus, the isoc endpoint request buffer size is not calculated correctly. Fix this by checking the gadget speed against USB_SPEED_SUPER_PLUS and update the request buffer size.

Fixes 90c4d05780d4 ("usb: fix various gadgets null ptr deref on 10gbps cabling.")

Cc stable <[email protected]>

Signed-off-by Pavankumar Kondeti <[email protected]>

Link https://lore.kernel.org/r/[email protected] open here

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 drivers/usb/gadget/function/f_sourcesink.c |    1 +
 1 file changed, 1 insertion(+)

drivers/usb/gadget/function/f_sourcesink.c +1 -0

@@ -584,6 +584,7 @@ static int source_sink_start_ep(struct f
 
 	if (is_iso) {
 		switch (speed) {
+		case USB_SPEED_SUPER_PLUS:
 		case USB_SPEED_SUPER:
 			size = ss->isoc_maxpacket *
 					(ss->isoc_mult + 1) *

Greg Kroah-Hartman

author maintainer

2022-01-31 11:11 UTC #57 lore raw

PATCH 57/171 usb: cdnsp: Fix segmentation fault in cdns_lost_power function

From: Pawel Laszczak <[email protected]>

commit 79aa3e19fe8f5be30e846df8a436bfe306e8b1a6 upstream.

CDNSP driver read not initialized cdns->otg_v0_regs which lead to segmentation fault. Patch fixes this issue.

Fixes 2cf2581cd229 ("usb: cdns3: add power lost support for system resume")

cc <[email protected]>

Signed-off-by Pawel Laszczak <[email protected]>

Link https://lore.kernel.org/r/[email protected] open here

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 drivers/usb/cdns3/drd.c |    6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

drivers/usb/cdns3/drd.c +3 -3

@@ -483,11 +483,11 @@ int cdns_drd_exit(struct cdns *cdns)
 /* Indicate the cdns3 core was power lost before */
 bool cdns_power_is_lost(struct cdns *cdns)
 {
-	if (cdns->version == CDNS3_CONTROLLER_V1) {
-		if (!(readl(&cdns->otg_v1_regs->simulate) & BIT(0)))
+	if (cdns->version == CDNS3_CONTROLLER_V0) {
+		if (!(readl(&cdns->otg_v0_regs->simulate) & BIT(0)))
 			return true;
 	} else {
-		if (!(readl(&cdns->otg_v0_regs->simulate) & BIT(0)))
+		if (!(readl(&cdns->otg_v1_regs->simulate) & BIT(0)))
 			return true;
 	}
 	return false;

Greg Kroah-Hartman

author maintainer

2022-01-31 11:11 UTC #58 lore raw

PATCH 58/171 usb: dwc3: xilinx: Skip resets and USB3 register settings for USB2.0 mode

From: Robert Hancock <[email protected]>

commit 9678f3361afc27a3124cd2824aec0227739986fb upstream.

It appears that the PIPE clock should not be selected when only USB 2.0 is being used in the design and no USB 3.0 reference clock is used. Also, the core resets are not required if a USB3 PHY is not in use, and will break things if USB3 is actually used but the PHY entry is not listed in the device tree.

Skip core resets and register settings that are only required for USB3 mode when no USB3 PHY is specified in the device tree.

Fixes 84770f028fab ("usb: dwc3: Add driver for Xilinx platforms")

Cc stable <[email protected]>

Link https://lore.kernel.org/r/[email protected] open here

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 drivers/usb/dwc3/dwc3-xilinx.c |   13 +++++++++++++
 1 file changed, 13 insertions(+)

drivers/usb/dwc3/dwc3-xilinx.c +13 -0

@@ -110,6 +110,18 @@ static int dwc3_xlnx_init_zynqmp(struct
 		usb3_phy = NULL;
 	}
 
+	/*
+	 * The following core resets are not required unless a USB3 PHY
+	 * is used, and the subsequent register settings are not required
+	 * unless a core reset is performed (they should be set properly
+	 * by the first-stage boot loader, but may be reverted by a core
+	 * reset). They may also break the configuration if USB3 is actually
+	 * in use but the usb3-phy entry is missing from the device tree.
+	 * Therefore, skip these operations in this case.
+	 */
+	if (!usb3_phy)
+		goto skip_usb3_phy;
+
 	crst = devm_reset_control_get_exclusive(dev, "usb_crst");
 	if (IS_ERR(crst)) {
 		ret = PTR_ERR(crst);

@@ -188,6 +200,7 @@ static int dwc3_xlnx_init_zynqmp(struct
 		goto err;
 	}
 
+skip_usb3_phy:
 	/*
 	 * This routes the USB DMA traffic to go through FPD path instead
 	 * of reaching DDR directly. This traffic routing is needed to

Greg Kroah-Hartman

author maintainer

2022-01-31 11:11 UTC #59 lore raw

PATCH 59/171 usb: dwc3: xilinx: Fix error handling when getting USB3 PHY

From: Robert Hancock <[email protected]>

commit 2cc9b1c93b1c4caa2d971856c0780fb5f7d04692 upstream.

The code that looked up the USB3 PHY was ignoring all errors other than EPROBE_DEFER in an attempt to handle the PHY not being present. Fix and simplify the code by using devm_phy_optional_get and dev_err_probe so that a missing PHY is not treated as an error and unexpected errors are handled properly.

Fixes 84770f028fab ("usb: dwc3: Add driver for Xilinx platforms")

Cc stable <[email protected]>

Link https://lore.kernel.org/r/[email protected] open here

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 drivers/usb/dwc3/dwc3-xilinx.c |   10 +++++-----
 1 file changed, 5 insertions(+), 5 deletions(-)

drivers/usb/dwc3/dwc3-xilinx.c +5 -5

@@ -102,12 +102,12 @@ static int dwc3_xlnx_init_zynqmp(struct
 	int			ret;
 	u32			reg;
 
-	usb3_phy = devm_phy_get(dev, "usb3-phy");
-	if (PTR_ERR(usb3_phy) == -EPROBE_DEFER) {
-		ret = -EPROBE_DEFER;
+	usb3_phy = devm_phy_optional_get(dev, "usb3-phy");
+	if (IS_ERR(usb3_phy)) {
+		ret = PTR_ERR(usb3_phy);
+		dev_err_probe(dev, ret,
+			      "failed to get USB3 PHY\n");
 		goto err;
-	} else if (IS_ERR(usb3_phy)) {
-		usb3_phy = NULL;
 	}
 
 	/*

Greg Kroah-Hartman

author maintainer

2022-01-31 11:14 UTC #60 lore raw

PATCH 60/171 USB: core: Fix hang in usb_kill_urb by adding memory barriers

From: Alan Stern <[email protected]>

commit 26fbe9772b8c459687930511444ce443011f86bf upstream.

The syzbot fuzzer has identified a bug in which processes hang waiting for usb_kill_urb() to return. It turns out the issue is not unlinking the URB; that works just fine. Rather, the problem arises when the wakeup notification that the URB has completed is not received.

The reason is memory-access ordering on SMP systems. In outline form, usb_kill_urb() and __usb_hcd_giveback_urb() operating concurrently on different CPUs perform the following actions:

CPU 0 CPU 1
---------------------------- ---------------------------------
usb_kill_urb(): __usb_hcd_giveback_urb():
... ...
atomic_inc(&urb->reject); atomic_dec(&urb->use_count);
... ...
wait_event(usb_kill_urb_queue,

	atomic_read(&urb->use_count) == 0);
					  if (atomic_read(&urb->reject))
						wake_up(&usb_kill_urb_queue);

Confining your attention to urb->reject and urb->use_count, you can see that the overall pattern of accesses on CPU 0 is:

	write urb->reject, then read urb->use_count;

whereas the overall pattern of accesses on CPU 1 is:

	write urb->use_count, then read urb->reject.

This pattern is referred to in memory-model circles as SB (for "Store Buffering"), and it is well known that without suitable enforcement of the desired order of accesses -- in the form of memory barriers -- it is entirely possible for one or both CPUs to execute their reads ahead of their writes. The end result will be that sometimes CPU 0 sees the old un-decremented value of urb->use_count while CPU 1 sees the old un-incremented value of urb->reject. Consequently CPU 0 ends up on the wait queue and never gets woken up, leading to the observed hang in usb_kill_urb().

The same pattern of accesses occurs in usb_poison_urb() and the failure pathway of usb_hcd_submit_urb().

The problem is fixed by adding suitable memory barriers. To provide proper memory-access ordering in the SB pattern, a full barrier is required on both CPUs. The atomic_inc() and atomic_dec() accesses themselves don't provide any memory ordering, but since they are present, we can use the optimized smp_mb__after_atomic() memory barrier in the various routines to obtain the desired effect.

This patch adds the necessary memory barriers.

CC <[email protected]>

Reported-and-tested-by [email protected]

Signed-off-by Alan Stern <[email protected]>

Link https://lore.kernel.org/r/[email protected] open here

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 drivers/usb/core/hcd.c |   14 ++++++++++++++
 drivers/usb/core/urb.c |   12 ++++++++++++
 2 files changed, 26 insertions(+)

drivers/usb/core/hcd.c +14 -0

@@ -1563,6 +1563,13 @@ int usb_hcd_submit_urb (struct urb *urb,
 		urb->hcpriv = NULL;
 		INIT_LIST_HEAD(&urb->urb_list);
 		atomic_dec(&urb->use_count);
+		/*
+		 * Order the write of urb->use_count above before the read
+		 * of urb->reject below.  Pairs with the memory barriers in
+		 * usb_kill_urb() and usb_poison_urb().
+		 */
+		smp_mb__after_atomic();
+
 		atomic_dec(&urb->dev->urbnum);
 		if (atomic_read(&urb->reject))
 			wake_up(&usb_kill_urb_queue);

@@ -1665,6 +1672,13 @@ static void __usb_hcd_giveback_urb(struc
 
 	usb_anchor_resume_wakeups(anchor);
 	atomic_dec(&urb->use_count);
+	/*
+	 * Order the write of urb->use_count above before the read
+	 * of urb->reject below.  Pairs with the memory barriers in
+	 * usb_kill_urb() and usb_poison_urb().
+	 */
+	smp_mb__after_atomic();
+
 	if (unlikely(atomic_read(&urb->reject)))
 		wake_up(&usb_kill_urb_queue);
 	usb_put_urb(urb);

drivers/usb/core/urb.c +12 -0

@@ -715,6 +715,12 @@ void usb_kill_urb(struct urb *urb)
 	if (!(urb && urb->dev && urb->ep))
 		return;
 	atomic_inc(&urb->reject);
+	/*
+	 * Order the write of urb->reject above before the read
+	 * of urb->use_count below.  Pairs with the barriers in
+	 * __usb_hcd_giveback_urb() and usb_hcd_submit_urb().
+	 */
+	smp_mb__after_atomic();
 
 	usb_hcd_unlink_urb(urb, -ENOENT);
 	wait_event(usb_kill_urb_queue, atomic_read(&urb->use_count) == 0);

@@ -756,6 +762,12 @@ void usb_poison_urb(struct urb *urb)
 	if (!urb)
 		return;
 	atomic_inc(&urb->reject);
+	/*
+	 * Order the write of urb->reject above before the read
+	 * of urb->use_count below.  Pairs with the barriers in
+	 * __usb_hcd_giveback_urb() and usb_hcd_submit_urb().
+	 */
+	smp_mb__after_atomic();
 
 	if (!urb->dev || !urb->ep)
 		return;

Greg Kroah-Hartman

author maintainer

2022-01-31 11:12 UTC #61 lore raw

PATCH 61/171 usb: typec: tcpci: dont touch CC line if its Vconn source

From: Xu Yang <[email protected]>

commit 5638b0dfb6921f69943c705383ff40fb64b987f2 upstream.

With the AMS and Collision Avoidance, tcpm often needs to change the CC's termination. When one CC line is sourcing Vconn, if we still change its termination, the voltage of the another CC line is likely to be fluctuant and unstable.

Therefore, we should verify whether a CC line is sourcing Vconn before changing its termination and only change the termination that is not a Vconn line. This can be done by reading the Vconn Present bit of POWER_ STATUS register. To determine the polarity, we can read the Plug Orientation bit of TCPC_CONTROL register. Since Vconn can only be sourced if Plug Orientation is set.

Fixes 0908c5aca31e ("usb: typec: tcpm: AMS and Collision Avoidance")

cc <[email protected]>

Reviewed-by Guenter Roeck <[email protected]>

Acked-by Heikki Krogerus <[email protected]>

Signed-off-by Xu Yang <[email protected]>

Link https://lore.kernel.org/r/[email protected] open here

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 drivers/usb/typec/tcpm/tcpci.c |   26 ++++++++++++++++++++++++++
 drivers/usb/typec/tcpm/tcpci.h |    1 +
 2 files changed, 27 insertions(+)

drivers/usb/typec/tcpm/tcpci.c +26 -0

@@ -75,9 +75,25 @@ static int tcpci_write16(struct tcpci *t
 static int tcpci_set_cc(struct tcpc_dev *tcpc, enum typec_cc_status cc)
 {
 	struct tcpci *tcpci = tcpc_to_tcpci(tcpc);
+	bool vconn_pres;
+	enum typec_cc_polarity polarity = TYPEC_POLARITY_CC1;
 	unsigned int reg;
 	int ret;
 
+	ret = regmap_read(tcpci->regmap, TCPC_POWER_STATUS, &reg);
+	if (ret < 0)
+		return ret;
+
+	vconn_pres = !!(reg & TCPC_POWER_STATUS_VCONN_PRES);
+	if (vconn_pres) {
+		ret = regmap_read(tcpci->regmap, TCPC_TCPC_CTRL, &reg);
+		if (ret < 0)
+			return ret;
+
+		if (reg & TCPC_TCPC_CTRL_ORIENTATION)
+			polarity = TYPEC_POLARITY_CC2;
+	}
+
 	switch (cc) {
 	case TYPEC_CC_RA:
 		reg = (TCPC_ROLE_CTRL_CC_RA << TCPC_ROLE_CTRL_CC1_SHIFT) |

@@ -112,6 +128,16 @@ static int tcpci_set_cc(struct tcpc_dev
 		break;
 	}
 
+	if (vconn_pres) {
+		if (polarity == TYPEC_POLARITY_CC2) {
+			reg &= ~(TCPC_ROLE_CTRL_CC1_MASK << TCPC_ROLE_CTRL_CC1_SHIFT);
+			reg |= (TCPC_ROLE_CTRL_CC_OPEN << TCPC_ROLE_CTRL_CC1_SHIFT);
+		} else {
+			reg &= ~(TCPC_ROLE_CTRL_CC2_MASK << TCPC_ROLE_CTRL_CC2_SHIFT);
+			reg |= (TCPC_ROLE_CTRL_CC_OPEN << TCPC_ROLE_CTRL_CC2_SHIFT);
+		}
+	}
+
 	ret = regmap_write(tcpci->regmap, TCPC_ROLE_CTRL, reg);
 	if (ret < 0)
 		return ret;

drivers/usb/typec/tcpm/tcpci.h +1 -0

@@ -98,6 +98,7 @@
 #define TCPC_POWER_STATUS_SOURCING_VBUS	BIT(4)
 #define TCPC_POWER_STATUS_VBUS_DET	BIT(3)
 #define TCPC_POWER_STATUS_VBUS_PRES	BIT(2)
+#define TCPC_POWER_STATUS_VCONN_PRES	BIT(1)
 #define TCPC_POWER_STATUS_SINKING_VBUS	BIT(0)
 
 #define TCPC_FAULT_STATUS		0x1f

Greg Kroah-Hartman

author maintainer

2022-01-31 11:13 UTC #62 lore raw

PATCH 62/171 usb: typec: tcpm: Do not disconnect while receiving VBUS off

From: Badhri Jagan Sridharan <[email protected]>

commit 90b8aa9f5b09edae6928c0561f933fec9f7a9987 upstream.

With some chargers, vbus might momentarily raise above VSAFE5V and fall back to 0V before tcpm gets to read port->tcpc->get_vbus. This will will report a VBUS off event causing TCPM to transition to SNK_UNATTACHED where it should be waiting in either SNK_ATTACH_WAIT or SNK_DEBOUNCED state. This patch makes TCPM avoid vbus off events while in SNK_ATTACH_WAIT or SNK_DEBOUNCED state.

Stub from the spec:
"4.5.2.2.4.2 Exiting from AttachWait.SNK State
A Sink shall transition to Unattached.SNK when the state of both the CC1 and CC2 pins is SNK.Open for at least tPDDebounce. A DRP shall transition to Unattached.SRC when the state of both the CC1 and CC2 pins is SNK.Open for at least tPDDebounce."

[23.194131] CC1: 0 -> 0, CC2: 0 -> 5 [state SNK_UNATTACHED, polarity 0, connected]
[23.201777] state change SNK_UNATTACHED -> SNK_ATTACH_WAIT [rev3 NONE_AMS]
[23.209949] pending state change SNK_ATTACH_WAIT -> SNK_DEBOUNCED @ 170 ms [rev3 NONE_AMS]
[23.300579] VBUS off
[23.300668] state change SNK_ATTACH_WAIT -> SNK_UNATTACHED [rev3 NONE_AMS]
[23.301014] VBUS VSAFE0V
[23.301111] Start toggling

Fixes f0690a25a140b8 ("staging: typec: USB Type-C Port Manager (tcpm)")

Acked-by Heikki Krogerus <[email protected]>

Signed-off-by Badhri Jagan Sridharan <[email protected]>

Link https://lore.kernel.org/r/[email protected] open here

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 drivers/usb/typec/tcpm/tcpm.c |    3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

drivers/usb/typec/tcpm/tcpm.c +2 -1

@@ -5156,7 +5156,8 @@ static void _tcpm_pd_vbus_off(struct tcp
 	case SNK_TRYWAIT_DEBOUNCE:
 		break;
 	case SNK_ATTACH_WAIT:
-		tcpm_set_state(port, SNK_UNATTACHED, 0);
+	case SNK_DEBOUNCED:
+		/* Do nothing, as TCPM is still waiting for vbus to reaach VSAFE5V to connect */
 		break;
 
 	case SNK_NEGOTIATE_CAPABILITIES:

Greg Kroah-Hartman

author maintainer

2022-01-31 11:15 UTC #63 lore raw

PATCH 63/171 usb: typec: tcpm: Do not disconnect when receiving VSAFE0V

From: Badhri Jagan Sridharan <[email protected]>

commit 746f96e7d6f7a276726860f696671766bfb24cf0 upstream.

With some chargers, vbus might momentarily raise above VSAFE5V and fall back to 0V causing VSAFE0V to be triggered. This will
will report a VBUS off event causing TCPM to transition to SNK_UNATTACHED state where it should be waiting in either SNK_ATTACH_WAIT or SNK_DEBOUNCED state. This patch makes TCPM avoid VSAFE0V events while in SNK_ATTACH_WAIT or SNK_DEBOUNCED state.

[23.194131] CC1: 0 -> 0, CC2: 0 -> 5 [state SNK_UNATTACHED, polarity 0, connected]
[23.201777] state change SNK_UNATTACHED -> SNK_ATTACH_WAIT [rev3 NONE_AMS]
[23.209949] pending state change SNK_ATTACH_WAIT -> SNK_DEBOUNCED @ 170 ms [rev3 NONE_AMS]
[23.300579] VBUS off
[23.300668] state change SNK_ATTACH_WAIT -> SNK_UNATTACHED [rev3 NONE_AMS]
[23.301014] VBUS VSAFE0V
[23.301111] Start toggling

Fixes 28b43d3d746b8 ("usb: typec: tcpm: Introduce vsafe0v for vbus")

Acked-by Heikki Krogerus <[email protected]>

Signed-off-by Badhri Jagan Sridharan <[email protected]>

Link https://lore.kernel.org/r/[email protected] open here

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 drivers/usb/typec/tcpm/tcpm.c |    4 ++++
 1 file changed, 4 insertions(+)

drivers/usb/typec/tcpm/tcpm.c +4 -0

@@ -5264,6 +5264,10 @@ static void _tcpm_pd_vbus_vsafe0v(struct
 	case PR_SWAP_SNK_SRC_SOURCE_ON:
 		/* Do nothing, vsafe0v is expected during transition */
 		break;
+	case SNK_ATTACH_WAIT:
+	case SNK_DEBOUNCED:
+		/*Do nothing, still waiting for VSAFE5V for connect */
+		break;
 	default:
 		if (port->pwr_role == TYPEC_SINK && port->auto_vbus_discharge_enabled)
 			tcpm_set_state(port, SNK_UNATTACHED, 0);

Greg Kroah-Hartman

author maintainer

2022-01-31 11:20 UTC #64 lore raw

PATCH 64/171 ucsi_ccg: Check DEV_INT bit only when starting CCG4

From: Sing-Han Chen <[email protected]>

commit 825911492eb15bf8bb7fb94bc0c0421fe7a6327d upstream.

CCGx clears Bit 0:Device Interrupt in the INTR_REG if CCGx is reset successfully. However, there might be a chance that other bits in INTR_REG are not cleared due to internal data queued in PPM. This case misleads the driver that CCGx reset failed.

The commit checks bit 0 in INTR_REG and ignores other bits. The ucsi driver would reset PPM later.

Fixes 247c554a14aa ("usb: typec: ucsi: add support for Cypress CCGx")

Reviewed-by Heikki Krogerus <[email protected]>

Signed-off-by Sing-Han Chen <[email protected]>

Signed-off-by Wayne Chang <[email protected]>

Link https://lore.kernel.org/r/[email protected] open here

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 drivers/usb/typec/ucsi/ucsi_ccg.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

drivers/usb/typec/ucsi/ucsi_ccg.c +1 -1

@@ -325,7 +325,7 @@ static int ucsi_ccg_init(struct ucsi_ccg
 		if (status < 0)
 			return status;
 
-		if (!data)
+		if (!(data & DEV_INT))
 			return 0;
 
 		status = ccg_write(uc, CCGX_RAB_INTR_REG, &data, sizeof(data));

Greg Kroah-Hartman

author maintainer

2022-01-31 11:21 UTC #65 lore raw

PATCH 65/171 mm, kasan: use compare-exchange operation to set KASAN page tag

Link https://linux-review.googlesource.com/id/I456b24a2b9067d93968d43b4bb3351c0cec63101

From: Peter Collingbourne <[email protected]>

commit 27fe73394a1c6d0b07fa4d95f1bca116d1cc66e9 upstream.

It has been reported that the tag setting operation on newly-allocated pages can cause the page flags to be corrupted when performed concurrently with other flag updates as a result of the use of non-atomic operations.

Fix the problem by using a compare-exchange loop to update the tag.

Link https://lkml.kernel.org/r/[email protected] open here

Fixes 2813b9c02962 ("kasan, mm, arm64: tag non slab memory allocated via pagealloc")

Signed-off-by Peter Collingbourne <[email protected]>

Reviewed-by Andrey Konovalov <[email protected]>

Cc Peter Zijlstra <[email protected]>

Signed-off-by Andrew Morton <[email protected]>

Signed-off-by Linus Torvalds <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 include/linux/mm.h |   17 ++++++++++++-----
 1 file changed, 12 insertions(+), 5 deletions(-)

include/linux/mm.h +12 -5

@@ -1511,11 +1511,18 @@ static inline u8 page_kasan_tag(const st
 
 static inline void page_kasan_tag_set(struct page *page, u8 tag)
 {
-	if (kasan_enabled()) {
-		tag ^= 0xff;
-		page->flags &= ~(KASAN_TAG_MASK << KASAN_TAG_PGSHIFT);
-		page->flags |= (tag & KASAN_TAG_MASK) << KASAN_TAG_PGSHIFT;
-	}
+	unsigned long old_flags, flags;
+
+	if (!kasan_enabled())
+		return;
+
+	tag ^= 0xff;
+	old_flags = READ_ONCE(page->flags);
+	do {
+		flags = old_flags;
+		flags &= ~(KASAN_TAG_MASK << KASAN_TAG_PGSHIFT);
+		flags |= (tag & KASAN_TAG_MASK) << KASAN_TAG_PGSHIFT;
+	} while (unlikely(!try_cmpxchg(&page->flags, &old_flags, flags)));
 }
 
 static inline void page_kasan_tag_reset(struct page *page)

Greg Kroah-Hartman

author maintainer

2022-01-31 11:20 UTC #66 lore raw

PATCH 66/171 jbd2: export jbd2_journal_[grab|put]_journal_head

From: Joseph Qi <[email protected]>

commit 4cd1103d8c66b2cdb7e64385c274edb0ac5e8887 upstream.

Patch series "ocfs2: fix a deadlock case".

This fixes a deadlock case in ocfs2. We firstly export jbd2 symbols jbd2_journal_[grab|put]_journal_head as preparation and later use them in ocfs2 insread of jbd_[lock|unlock]_bh_journal_head to fix the deadlock.

This patch (of 2):

This exports symbols jbd2_journal_[grab|put]_journal_head, which will be used outside modules, e.g. ocfs2.

Link https://lkml.kernel.org/r/[email protected] open here

Signed-off-by Joseph Qi <[email protected]>

Cc Mark Fasheh <[email protected]>

Cc Joel Becker <[email protected]>

Cc Junxiao Bi <[email protected]>

Cc Changwei Ge <[email protected]>

Cc Gang He <[email protected]>

Cc Jun Piao <[email protected]>

Cc Andreas Dilger <[email protected]>

Cc Gautham Ananthakrishna <[email protected]>

Cc Saeed Mirzamohammadi <[email protected]>

Cc "Theodore Ts'o" <[email protected]>

Signed-off-by Andrew Morton <[email protected]>

Signed-off-by Linus Torvalds <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 fs/jbd2/journal.c |    2 ++
 1 file changed, 2 insertions(+)

fs/jbd2/journal.c +2 -0

@@ -2970,6 +2970,7 @@ struct journal_head *jbd2_journal_grab_j
 	jbd_unlock_bh_journal_head(bh);
 	return jh;
 }
+EXPORT_SYMBOL(jbd2_journal_grab_journal_head);
 
 static void __journal_remove_journal_head(struct buffer_head *bh)
 {

@@ -3022,6 +3023,7 @@ void jbd2_journal_put_journal_head(struc
 		jbd_unlock_bh_journal_head(bh);
 	}
 }
+EXPORT_SYMBOL(jbd2_journal_put_journal_head);
 
 /*
  * Initialize jbd inode head

Greg Kroah-Hartman

author maintainer

2022-01-31 11:20 UTC #67 lore raw

PATCH 67/171 ocfs2: fix a deadlock when commit trans

From: Joseph Qi <[email protected]>

commit ddf4b773aa40790dfa936bd845c18e735a49c61c upstream.

commit 6f1b228529ae introduces a regression which can deadlock as follows:

  Task1:                              Task2:
  jbd2_journal_commit_transaction     ocfs2_test_bg_bit_allocatable
  spin_lock(&jh->b_state_lock)        jbd_lock_bh_journal_head
  __jbd2_journal_remove_checkpoint    spin_lock(&jh->b_state_lock)

jbd2_journal_put_journal_head
jbd_lock_bh_journal_head

Task1 and Task2 lock bh->b_state and jh->b_state_lock in different order, which finally result in a deadlock.

So use jbd2_journal_[grab|put]_journal_head instead in ocfs2_test_bg_bit_allocatable() to fix it.

Link https://lkml.kernel.org/r/[email protected] open here

Fixes 6f1b228529ae ("ocfs2: fix race between searching chunks and release journal_head from buffer_head")

Signed-off-by Joseph Qi <[email protected]>

Reported-by Gautham Ananthakrishna <[email protected]>

Tested-by Gautham Ananthakrishna <[email protected]>

Reported-by Saeed Mirzamohammadi <[email protected]>

Cc "Theodore Ts'o" <[email protected]>

Cc Andreas Dilger <[email protected]>

Cc Changwei Ge <[email protected]>

Cc Gang He <[email protected]>

Cc Joel Becker <[email protected]>

Cc Jun Piao <[email protected]>

Cc Junxiao Bi <[email protected]>

Cc Mark Fasheh <[email protected]>

Signed-off-by Andrew Morton <[email protected]>

Signed-off-by Linus Torvalds <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 fs/ocfs2/suballoc.c |   25 +++++++++++--------------
 1 file changed, 11 insertions(+), 14 deletions(-)

fs/ocfs2/suballoc.c +11 ~~-14~~

@@ -1251,26 +1251,23 @@ static int ocfs2_test_bg_bit_allocatable
 {
 	struct ocfs2_group_desc *bg = (struct ocfs2_group_desc *) bg_bh->b_data;
 	struct journal_head *jh;
-	int ret = 1;
+	int ret;
 
 	if (ocfs2_test_bit(nr, (unsigned long *)bg->bg_bitmap))
 		return 0;
 
-	if (!buffer_jbd(bg_bh))
+	jh = jbd2_journal_grab_journal_head(bg_bh);
+	if (!jh)
 		return 1;
 
-	jbd_lock_bh_journal_head(bg_bh);
-	if (buffer_jbd(bg_bh)) {
-		jh = bh2jh(bg_bh);
-		spin_lock(&jh->b_state_lock);
-		bg = (struct ocfs2_group_desc *) jh->b_committed_data;
-		if (bg)
-			ret = !ocfs2_test_bit(nr, (unsigned long *)bg->bg_bitmap);
-		else
-			ret = 1;
-		spin_unlock(&jh->b_state_lock);
-	}
-	jbd_unlock_bh_journal_head(bg_bh);
+	spin_lock(&jh->b_state_lock);
+	bg = (struct ocfs2_group_desc *) jh->b_committed_data;
+	if (bg)
+		ret = !ocfs2_test_bit(nr, (unsigned long *)bg->bg_bitmap);
+	else
+		ret = 1;
+	spin_unlock(&jh->b_state_lock);
+	jbd2_journal_put_journal_head(jh);
 
 	return ret;
 }

Greg Kroah-Hartman

author maintainer

2022-01-31 11:21 UTC #68 lore raw

PATCH 68/171 sched/membarrier: Fix membarrier-rseq fence command missing from query bitmask

From: Mathieu Desnoyers <[email protected]>

commit 809232619f5b15e31fb3563985e705454f32621f upstream.

The membarrier command MEMBARRIER_CMD_QUERY allows querying the available membarrier commands. When the membarrier-rseq fence commands were added, a new MEMBARRIER_CMD_PRIVATE_EXPEDITED_RSEQ_BITMASK was introduced with the intent to expose them with the MEMBARRIER_CMD_QUERY command, the but it was never added to MEMBARRIER_CMD_BITMASK.

The membarrier-rseq fence commands are therefore not wired up with the query command.

Rename MEMBARRIER_CMD_PRIVATE_EXPEDITED_RSEQ_BITMASK to MEMBARRIER_PRIVATE_EXPEDITED_RSEQ_BITMASK (the bitmask is not a command per-se), and change the erroneous MEMBARRIER_CMD_REGISTER_PRIVATE_EXPEDITED_RSEQ_BITMASK (which does not actually exist) to MEMBARRIER_CMD_REGISTER_PRIVATE_EXPEDITED_RSEQ.

Wire up MEMBARRIER_PRIVATE_EXPEDITED_RSEQ_BITMASK in MEMBARRIER_CMD_BITMASK. Fixing this allows discovering availability of the membarrier-rseq fence feature.

Fixes 2a36ab717e8f ("rseq/membarrier: Add MEMBARRIER_CMD_PRIVATE_EXPEDITED_RSEQ")

Signed-off-by Mathieu Desnoyers <[email protected]>

Signed-off-by Peter Zijlstra (Intel) <[email protected]>

Cc <[email protected]> # 5.10+

Link https://lkml.kernel.org/r/[email protected] open here

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 kernel/sched/membarrier.c |    9 +++++----
 1 file changed, 5 insertions(+), 4 deletions(-)

kernel/sched/membarrier.c +5 -4

@@ -147,11 +147,11 @@
 #endif
 
 #ifdef CONFIG_RSEQ
-#define MEMBARRIER_CMD_PRIVATE_EXPEDITED_RSEQ_BITMASK		\
+#define MEMBARRIER_PRIVATE_EXPEDITED_RSEQ_BITMASK		\
 	(MEMBARRIER_CMD_PRIVATE_EXPEDITED_RSEQ			\
-	| MEMBARRIER_CMD_REGISTER_PRIVATE_EXPEDITED_RSEQ_BITMASK)
+	| MEMBARRIER_CMD_REGISTER_PRIVATE_EXPEDITED_RSEQ)
 #else
-#define MEMBARRIER_CMD_PRIVATE_EXPEDITED_RSEQ_BITMASK	0
+#define MEMBARRIER_PRIVATE_EXPEDITED_RSEQ_BITMASK	0
 #endif
 
 #define MEMBARRIER_CMD_BITMASK						\

@@ -159,7 +159,8 @@
 	| MEMBARRIER_CMD_REGISTER_GLOBAL_EXPEDITED			\
 	| MEMBARRIER_CMD_PRIVATE_EXPEDITED				\
 	| MEMBARRIER_CMD_REGISTER_PRIVATE_EXPEDITED			\
-	| MEMBARRIER_PRIVATE_EXPEDITED_SYNC_CORE_BITMASK)
+	| MEMBARRIER_PRIVATE_EXPEDITED_SYNC_CORE_BITMASK		\
+	| MEMBARRIER_PRIVATE_EXPEDITED_RSEQ_BITMASK)
 
 static void ipi_mb(void *info)
 {

Greg Kroah-Hartman

author maintainer

2022-01-31 11:14 UTC #69 lore raw

PATCH 69/171 PCI/sysfs: Find shadow ROM before static attribute initialization

From: Bjorn Helgaas <[email protected]>

commit 66d28b21fe6b3da8d1e9f0a7ba38bc61b6c547e1 upstream.

Ville reported that the sysfs "rom" file for VGA devices disappeared after 527139d738d7 ("PCI/sysfs: Convert "rom" to static attribute").

Prior to 527139d738d7, FINAL fixups, including pci_fixup_video() where we find shadow ROMs, were run before pci_create_sysfs_dev_files() created the sysfs "rom" file.

After 527139d738d7, "rom" is a static attribute and is created before FINAL fixups are run, so we didn't create "rom" files for shadow ROMs:

acpi_pci_root_add

    ...
      pci_scan_single_device
        pci_device_add
          pci_fixup_video                    # <-- new HEADER fixup
          device_add
            ...
              if (grp->is_visible())
                pci_dev_rom_attr_is_visible  # after 527139d738d7
    pci_bus_add_devices
      pci_bus_add_device
        pci_fixup_device(pci_fixup_final)
          pci_fixup_video                    # <-- previous FINAL fixup
        pci_create_sysfs_dev_files
          if (pci_resource_len(pdev, PCI_ROM_RESOURCE))
            sysfs_create_bin_file("rom")     # before 527139d738d7

Change pci_fixup_video() to be a HEADER fixup so it runs before sysfs static attributes are initialized.

Rename the Loongson pci_fixup_radeon() to pci_fixup_video() and make its dmesg logging identical to the others since it is doing the same job.

Link https://lore.kernel.org/r/[email protected] open here

Fixes 527139d738d7 ("PCI/sysfs: Convert "rom" to static attribute")

Link https://lore.kernel.org/r/[email protected] open here

Reported-by Ville Syrjälä <[email protected]>

Tested-by Ville Syrjälä <[email protected]>

Signed-off-by Bjorn Helgaas <[email protected]>

Cc [email protected] # v5.13+

Cc Huacai Chen <[email protected]>

Cc Jiaxun Yang <[email protected]>

Cc Thomas Bogendoerfer <[email protected]>

Cc Thomas Gleixner <[email protected]>

Cc Ingo Molnar <[email protected]>

Cc Borislav Petkov <[email protected]>

Cc Dave Hansen <[email protected]>

Cc Krzysztof Wilczyński <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 arch/ia64/pci/fixup.c              |    4 ++--
 arch/mips/loongson64/vbios_quirk.c |    9 ++++-----
 arch/x86/pci/fixup.c               |    4 ++--
 3 files changed, 8 insertions(+), 9 deletions(-)

arch/ia64/pci/fixup.c +2 -2

@@ -76,5 +76,5 @@ static void pci_fixup_video(struct pci_d
 		}
 	}
 }
-DECLARE_PCI_FIXUP_CLASS_FINAL(PCI_ANY_ID, PCI_ANY_ID,
-				PCI_CLASS_DISPLAY_VGA, 8, pci_fixup_video);
+DECLARE_PCI_FIXUP_CLASS_HEADER(PCI_ANY_ID, PCI_ANY_ID,
+			       PCI_CLASS_DISPLAY_VGA, 8, pci_fixup_video);

arch/mips/loongson64/vbios_quirk.c +4 -5

@@ -3,7 +3,7 @@
 #include <linux/pci.h>
 #include <loongson.h>
 
-static void pci_fixup_radeon(struct pci_dev *pdev)
+static void pci_fixup_video(struct pci_dev *pdev)
 {
 	struct resource *res = &pdev->resource[PCI_ROM_RESOURCE];

@@ -22,8 +22,7 @@ static void pci_fixup_radeon(struct pci_
 	res->flags = IORESOURCE_MEM | IORESOURCE_ROM_SHADOW |
 		     IORESOURCE_PCI_FIXED;
 
-	dev_info(&pdev->dev, "BAR %d: assigned %pR for Radeon ROM\n",
-		 PCI_ROM_RESOURCE, res);
+	dev_info(&pdev->dev, "Video device with shadowed ROM at %pR\n", res);
 }
-DECLARE_PCI_FIXUP_CLASS_FINAL(PCI_VENDOR_ID_ATI, 0x9615,
-				PCI_CLASS_DISPLAY_VGA, 8, pci_fixup_radeon);
+DECLARE_PCI_FIXUP_CLASS_HEADER(PCI_VENDOR_ID_ATI, 0x9615,
+			       PCI_CLASS_DISPLAY_VGA, 8, pci_fixup_video);

arch/x86/pci/fixup.c +2 -2

@@ -353,8 +353,8 @@ static void pci_fixup_video(struct pci_d
 		}
 	}
 }
-DECLARE_PCI_FIXUP_CLASS_FINAL(PCI_ANY_ID, PCI_ANY_ID,
-				PCI_CLASS_DISPLAY_VGA, 8, pci_fixup_video);
+DECLARE_PCI_FIXUP_CLASS_HEADER(PCI_ANY_ID, PCI_ANY_ID,
+			       PCI_CLASS_DISPLAY_VGA, 8, pci_fixup_video);
 
 
 static const struct dmi_system_id msi_k8t_dmi_table[] = {

Greg Kroah-Hartman

author maintainer

2022-01-31 11:12 UTC #70 lore raw

PATCH 70/171 x86/MCE/AMD: Allow thresholding interface updates after init

From: Yazen Ghannam <[email protected]>

commit 1f52b0aba6fd37653416375cb8a1ca673acf8d5f upstream.

Changes to the AMD Thresholding sysfs code prevents sysfs writes from updating the underlying registers once CPU init is completed, i.e. "threshold_banks" is set.

Allow the registers to be updated if the thresholding interface is already initialized or if in the init path. Use the "set_lvt_off" value to indicate if running in the init path, since this value is only set during init.

Fixes a037f3ca0ea0 ("x86/mce/amd: Make threshold bank setting hotplug robust")

Signed-off-by Yazen Ghannam <[email protected]>

Signed-off-by Borislav Petkov <[email protected]>

Link https://lore.kernel.org/r/[email protected] open here

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 arch/x86/kernel/cpu/mce/amd.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

arch/x86/kernel/cpu/mce/amd.c +1 -1

@@ -400,7 +400,7 @@ static void threshold_restart_bank(void
 	u32 hi, lo;
 
 	/* sysfs write might race against an offline operation */
-	if (this_cpu_read(threshold_banks))
+	if (!this_cpu_read(threshold_banks) && !tr->set_lvt_off)
 		return;
 
 	rdmsr(tr->b->address, lo, hi);

Greg Kroah-Hartman

author maintainer

2022-01-31 11:12 UTC #71 lore raw

PATCH 71/171 x86/cpu: Add Xeon Icelake-D to list of CPUs that support PPIN

From: Tony Luck <[email protected]>

commit e464121f2d40eabc7d11823fb26db807ce945df4 upstream.

Missed adding the Icelake-D CPU to the list. It uses the same MSRs to control and read the inventory number as all the other models.

Fixes dc6b025de95b ("x86/mce: Add Xeon Icelake to list of CPUs that support PPIN")

Reported-by Ailin Xu <[email protected]>

Signed-off-by Tony Luck <[email protected]>

Signed-off-by Borislav Petkov <[email protected]>

Link https://lore.kernel.org/r/[email protected] open here

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 arch/x86/kernel/cpu/mce/intel.c |    1 +
 1 file changed, 1 insertion(+)

arch/x86/kernel/cpu/mce/intel.c +1 -0

@@ -486,6 +486,7 @@ static void intel_ppin_init(struct cpuin
 	case INTEL_FAM6_BROADWELL_X:
 	case INTEL_FAM6_SKYLAKE_X:
 	case INTEL_FAM6_ICELAKE_X:
+	case INTEL_FAM6_ICELAKE_D:
 	case INTEL_FAM6_SAPPHIRERAPIDS_X:
 	case INTEL_FAM6_XEON_PHI_KNL:
 	case INTEL_FAM6_XEON_PHI_KNM:

Greg Kroah-Hartman

author maintainer

2022-01-31 11:12 UTC #72 lore raw

PATCH 72/171 powerpc/32s: Allocate one 256k IBAT instead of two consecutives 128k IBATs

From: Christophe Leroy <[email protected]>

commit 37eb7ca91b692e8e49e7dd50158349a6c8fb5b09 upstream.

Today we have the following IBATs allocated:

	---[ Instruction Block Address Translation ]---
	0: 0xc0000000-0xc03fffff 0x00000000         4M Kernel   x     m
	1: 0xc0400000-0xc05fffff 0x00400000         2M Kernel   x     m
	2: 0xc0600000-0xc06fffff 0x00600000         1M Kernel   x     m
	3: 0xc0700000-0xc077ffff 0x00700000       512K Kernel   x     m
	4: 0xc0780000-0xc079ffff 0x00780000       128K Kernel   x     m
	5: 0xc07a0000-0xc07bffff 0x007a0000       128K Kernel   x     m
	6:         -
	7:         -

The two 128K should be a single 256K instead.

When _etext is not aligned to 128Kbytes, the system will allocate all necessary BATs to the lower 128Kbytes boundary, then allocate an additional 128Kbytes BAT for the remaining block.

Instead, align the top to 128Kbytes so that the function directly allocates a 256Kbytes last block:

	---[ Instruction Block Address Translation ]---
	0: 0xc0000000-0xc03fffff 0x00000000         4M Kernel   x     m
	1: 0xc0400000-0xc05fffff 0x00400000         2M Kernel   x     m
	2: 0xc0600000-0xc06fffff 0x00600000         1M Kernel   x     m
	3: 0xc0700000-0xc077ffff 0x00700000       512K Kernel   x     m
	4: 0xc0780000-0xc07bffff 0x00780000       256K Kernel   x     m
	5:         -
	6:         -
	7:         -

Link https://lore.kernel.org/r/ab58b296832b0ec650e2203200e060adbcb2677d.1637930421.git.christophe.leroy@csgroup.eu open here

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 arch/powerpc/mm/book3s32/mmu.c |    5 ++---
 1 file changed, 2 insertions(+), 3 deletions(-)

arch/powerpc/mm/book3s32/mmu.c +2 -3

@@ -196,18 +196,17 @@ void mmu_mark_initmem_nx(void)
 	int nb = mmu_has_feature(MMU_FTR_USE_HIGH_BATS) ? 8 : 4;
 	int i;
 	unsigned long base = (unsigned long)_stext - PAGE_OFFSET;
-	unsigned long top = (unsigned long)_etext - PAGE_OFFSET;
+	unsigned long top = ALIGN((unsigned long)_etext - PAGE_OFFSET, SZ_128K);
 	unsigned long border = (unsigned long)__init_begin - PAGE_OFFSET;
 	unsigned long size;
 
-	for (i = 0; i < nb - 1 && base < top && top - base > (128 << 10);) {
+	for (i = 0; i < nb - 1 && base < top;) {
 		size = block_size(base, top);
 		setibat(i++, PAGE_OFFSET + base, base, size, PAGE_KERNEL_TEXT);
 		base += size;
 	}
 	if (base < top) {
 		size = block_size(base, top);
-		size = max(size, 128UL << 10);
 		if ((top - base) > size) {
 			size <<= 1;
 			if (strict_kernel_rwx_enabled() && base + size > border)

Greg Kroah-Hartman

author maintainer

2022-01-31 11:12 UTC #73 lore raw

PATCH 73/171 powerpc/32s: Fix kasan_init_region() for KASAN

From: Christophe Leroy <[email protected]>

commit d37823c3528e5e0705fc7746bcbc2afffb619259 upstream.

It has been reported some configuration where the kernel doesn't boot with KASAN enabled.

This is due to wrong BAT allocation for the KASAN area:

	---[ Data Block Address Translation ]---
	0: 0xc0000000-0xcfffffff 0x00000000       256M Kernel rw      m
	1: 0xd0000000-0xdfffffff 0x10000000       256M Kernel rw      m
	2: 0xe0000000-0xefffffff 0x20000000       256M Kernel rw      m
	3: 0xf8000000-0xf9ffffff 0x2a000000        32M Kernel rw      m
	4: 0xfa000000-0xfdffffff 0x2c000000        64M Kernel rw      m

A BAT must have both virtual and physical addresses alignment matching the size of the BAT. This is not the case for BAT 4 above.

Fix kasan_init_region() by using block_size() function that is in book3s32/mmu.c. To be able to reuse it here, make it non static and change its name to bat_block_size() in order to avoid name conflict with block_size() defined in <linux/blkdev.h>

Also reuse find_free_bat() to avoid an error message from setbat() when no BAT is available.

And allocate memory outside of linear memory mapping to avoid wasting that precious space.

With this change we get correct alignment for BATs and KASAN shadow memory is allocated outside the linear memory space.

	---[ Data Block Address Translation ]---
	0: 0xc0000000-0xcfffffff 0x00000000       256M Kernel rw
	1: 0xd0000000-0xdfffffff 0x10000000       256M Kernel rw
	2: 0xe0000000-0xefffffff 0x20000000       256M Kernel rw
	3: 0xf8000000-0xfbffffff 0x7c000000        64M Kernel rw
	4: 0xfc000000-0xfdffffff 0x7a000000        32M Kernel rw

Fixes 7974c4732642 ("powerpc/32s: Implement dedicated kasan_init_region()")

Reported-by Maxime Bizon <[email protected]>

Tested-by Maxime Bizon <[email protected]>

Link https://lore.kernel.org/r/7a50ef902494d1325227d47d33dada01e52e5518.1641818726.git.christophe.leroy@csgroup.eu open here

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 arch/powerpc/include/asm/book3s/32/mmu-hash.h |    2 
 arch/powerpc/mm/book3s32/mmu.c                |   10 ++--
 arch/powerpc/mm/kasan/book3s_32.c             |   57 +++++++++++++-------------
 3 files changed, 37 insertions(+), 32 deletions(-)

arch/powerpc/include/asm/book3s/32/mmu-hash.h +2 -0

@@ -143,6 +143,8 @@ static __always_inline void update_user_
 	update_user_segment(15, val);
 }
 
+int __init find_free_bat(void);
+unsigned int bat_block_size(unsigned long base, unsigned long top);
 #endif /* !__ASSEMBLY__ */
 
 /* We happily ignore the smaller BATs on 601, we don't actually use

arch/powerpc/mm/book3s32/mmu.c +5 -5

@@ -76,7 +76,7 @@ unsigned long p_block_mapped(phys_addr_t
 	return 0;
 }
 
-static int find_free_bat(void)
+int __init find_free_bat(void)
 {
 	int b;
 	int n = mmu_has_feature(MMU_FTR_USE_HIGH_BATS) ? 8 : 4;

@@ -100,7 +100,7 @@ static int find_free_bat(void)
  * - block size has to be a power of two. This is calculated by finding the
  *   highest bit set to 1.
  */
-static unsigned int block_size(unsigned long base, unsigned long top)
+unsigned int bat_block_size(unsigned long base, unsigned long top)
 {
 	unsigned int max_size = SZ_256M;
 	unsigned int base_shift = (ffs(base) - 1) & 31;

@@ -145,7 +145,7 @@ static unsigned long __init __mmu_mapin_
 	int idx;
 
 	while ((idx = find_free_bat()) != -1 && base != top) {
-		unsigned int size = block_size(base, top);
+		unsigned int size = bat_block_size(base, top);
 
 		if (size < 128 << 10)
 			break;

@@ -201,12 +201,12 @@ void mmu_mark_initmem_nx(void)
 	unsigned long size;
 
 	for (i = 0; i < nb - 1 && base < top;) {
-		size = block_size(base, top);
+		size = bat_block_size(base, top);
 		setibat(i++, PAGE_OFFSET + base, base, size, PAGE_KERNEL_TEXT);
 		base += size;
 	}
 	if (base < top) {
-		size = block_size(base, top);
+		size = bat_block_size(base, top);
 		if ((top - base) > size) {
 			size <<= 1;
 			if (strict_kernel_rwx_enabled() && base + size > border)

arch/powerpc/mm/kasan/book3s_32.c +30 ~~-27~~

78 lines not on this page · raw message

Greg Kroah-Hartman

author maintainer

2022-01-31 11:12 UTC #74 lore raw

PATCH 74/171 powerpc/32: Fix boot failure with GCC latent entropy plugin

From: Christophe Leroy <[email protected]>

commit bba496656a73fc1d1330b49c7f82843836e9feb1 upstream.

Boot fails with GCC latent entropy plugin enabled.

This is due to early boot functions trying to access 'latent_entropy' global data while the kernel is not relocated at its final destination yet.

As there is no way to tell GCC to use PTRRELOC() to access it, disable latent entropy plugin in early_32.o and feature-fixups.o and code-patching.o

Fixes 38addce8b600 ("gcc-plugins: Add latent_entropy plugin")

Cc [email protected] # v4.9+

Reported-by Erhard Furtner <[email protected]>

Link https://bugzilla.kernel.org/show_bug.cgi?id=215217

Link https://lore.kernel.org/r/2bac55483b8daf5b1caa163a45fa5f9cdbe18be4.1640178426.git.christophe.leroy@csgroup.eu open here

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 arch/powerpc/kernel/Makefile |    1 +
 arch/powerpc/lib/Makefile    |    3 +++
 2 files changed, 4 insertions(+)

arch/powerpc/kernel/Makefile +1 -0

@@ -11,6 +11,7 @@ CFLAGS_prom_init.o      += -fPIC
 CFLAGS_btext.o		+= -fPIC
 endif
 
+CFLAGS_early_32.o += $(DISABLE_LATENT_ENTROPY_PLUGIN)
 CFLAGS_cputable.o += $(DISABLE_LATENT_ENTROPY_PLUGIN)
 CFLAGS_prom_init.o += $(DISABLE_LATENT_ENTROPY_PLUGIN)
 CFLAGS_btext.o += $(DISABLE_LATENT_ENTROPY_PLUGIN)

arch/powerpc/lib/Makefile +3 -0

@@ -19,6 +19,9 @@ CFLAGS_code-patching.o += -DDISABLE_BRAN
 CFLAGS_feature-fixups.o += -DDISABLE_BRANCH_PROFILING
 endif
 
+CFLAGS_code-patching.o += $(DISABLE_LATENT_ENTROPY_PLUGIN)
+CFLAGS_feature-fixups.o += $(DISABLE_LATENT_ENTROPY_PLUGIN)
+
 obj-y += alloc.o code-patching.o feature-fixups.o pmem.o test_code-patching.o
 
 ifndef CONFIG_KASAN

Greg Kroah-Hartman

author maintainer

2022-01-31 11:12 UTC #75 lore raw

PATCH 75/171 i40e: Increase delay to 1 s after global EMP reset

From: Jedrzej Jagielski <[email protected]>

commit 9b13bd53134c9ddd544a790125199fdbdb505e67 upstream.

Recently simplified i40e_rebuild causes that FW sometimes is not ready after NVM update, the ping does not return.

Increase the delay in case of EMP reset.
Old delay of 300 ms was introduced for specific cards for 710 series. Now it works for all the cards and delay was increased.

Fixes 1fa51a650e1d ("i40e: Add delay after EMP reset for firmware to recover")

Signed-off-by Arkadiusz Kubalewski <[email protected]>

Signed-off-by Jedrzej Jagielski <[email protected]>

Tested-by Gurucharan G <[email protected]>

Signed-off-by Tony Nguyen <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 drivers/net/ethernet/intel/i40e/i40e_main.c |   12 +++---------
 1 file changed, 3 insertions(+), 9 deletions(-)

drivers/net/ethernet/intel/i40e/i40e_main.c +3 -9

@@ -10574,15 +10574,9 @@ static void i40e_rebuild(struct i40e_pf
 	}
 	i40e_get_oem_version(&pf->hw);
 
-	if (test_bit(__I40E_EMP_RESET_INTR_RECEIVED, pf->state) &&
-	    ((hw->aq.fw_maj_ver == 4 && hw->aq.fw_min_ver <= 33) ||
-	     hw->aq.fw_maj_ver < 4) && hw->mac.type == I40E_MAC_XL710) {
-		/* The following delay is necessary for 4.33 firmware and older
-		 * to recover after EMP reset. 200 ms should suffice but we
-		 * put here 300 ms to be sure that FW is ready to operate
-		 * after reset.
-		 */
-		mdelay(300);
+	if (test_and_clear_bit(__I40E_EMP_RESET_INTR_RECEIVED, pf->state)) {
+		/* The following delay is necessary for firmware update. */
+		mdelay(1000);
 	}
 
 	/* re-verify the eeprom if we just had an EMP reset */

Greg Kroah-Hartman

author maintainer

2022-01-31 11:12 UTC #76 lore raw

PATCH 76/171 i40e: Fix issue when maximum queues is exceeded

From: Jedrzej Jagielski <[email protected]>

commit d701658a50a471591094b3eb3961b4926cc8f104 upstream.

Before this patch VF interface vanished when maximum queue number was exceeded. Driver tried to add next queues even if there was not enough space. PF sent incorrect number of queues to
the VF when there were not enough of them.

Add an additional condition introduced to check available space in 'qp_pile' before proceeding. This condition makes it impossible to add queues if they number is greater than the number resulting from available space.
Also add the search for free space in PF queue pair piles.

Without this patch VF interfaces are not seen
when available space for queues has been
exceeded and following logs appears permanently
in dmesg:
"Unable to get VF config (-32)".
"VF 62 failed opcode 3, retval: -5"
"Unable to get VF config due to PF error condition, not retrying"

Fixes 7daa6bf3294e ("i40e: driver core headers")

Fixes 41c445ff0f48 ("i40e: main driver core")

Signed-off-by Jaroslaw Gawin <[email protected]>

Signed-off-by Slawomir Laba <[email protected]>

Signed-off-by Jedrzej Jagielski <[email protected]>

Tested-by Konrad Jankowski <[email protected]>

Signed-off-by Tony Nguyen <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 drivers/net/ethernet/intel/i40e/i40e.h             |    1 
 drivers/net/ethernet/intel/i40e/i40e_main.c        |   14 ----
 drivers/net/ethernet/intel/i40e/i40e_virtchnl_pf.c |   59 +++++++++++++++++++++
 3 files changed, 61 insertions(+), 13 deletions(-)

drivers/net/ethernet/intel/i40e/i40e.h +0 -1

@@ -174,7 +174,6 @@ enum i40e_interrupt_policy {
 
 struct i40e_lump_tracking {
 	u16 num_entries;
-	u16 search_hint;
 	u16 list[0];
 #define I40E_PILE_VALID_BIT  0x8000
 #define I40E_IWARP_IRQ_PILE_ID  (I40E_PILE_VALID_BIT - 2)

drivers/net/ethernet/intel/i40e/i40e_main.c +2 ~~-12~~

@@ -196,10 +196,6 @@ int i40e_free_virt_mem_d(struct i40e_hw
  * @id: an owner id to stick on the items assigned
  *
  * Returns the base item index of the lump, or negative for error
- *
- * The search_hint trick and lack of advanced fit-finding only work
- * because we're highly likely to have all the same size lump requests.
- * Linear search time and any fragmentation should be minimal.
  **/
 static int i40e_get_lump(struct i40e_pf *pf, struct i40e_lump_tracking *pile,
 			 u16 needed, u16 id)

@@ -214,8 +210,7 @@ static int i40e_get_lump(struct i40e_pf
 		return -EINVAL;
 	}
 
-	/* start the linear search with an imperfect hint */
-	i = pile->search_hint;
+	i = 0;
 	while (i < pile->num_entries) {
 		/* skip already allocated entries */
 		if (pile->list[i] & I40E_PILE_VALID_BIT) {

@@ -234,7 +229,6 @@ static int i40e_get_lump(struct i40e_pf
 			for (j = 0; j < needed; j++)
 				pile->list[i+j] = id | I40E_PILE_VALID_BIT;
 			ret = i;
-			pile->search_hint = i + j;
 			break;
 		}

@@ -257,7 +251,7 @@ static int i40e_put_lump(struct i40e_lum
 {
 	int valid_id = (id | I40E_PILE_VALID_BIT);
 	int count = 0;
-	int i;
+	u16 i;
 
 	if (!pile || index >= pile->num_entries)
 		return -EINVAL;

@@ -269,8 +263,6 @@ static int i40e_put_lump(struct i40e_lum
 		count++;
 	}
 
-	if (count && index < pile->search_hint)
-		pile->search_hint = index;
 
 	return count;
 }

@@ -11786,7 +11778,6 @@ static int i40e_init_interrupt_scheme(st
 		return -ENOMEM;
 
 	pf->irq_pile->num_entries = vectors;
-	pf->irq_pile->search_hint = 0;
 
 	/* track first vector for misc interrupts, ignore return */
 	(void)i40e_get_lump(pf, pf->irq_pile, 1, I40E_PILE_VALID_BIT - 1);

@@ -12589,7 +12580,6 @@ static int i40e_sw_init(struct i40e_pf *
 		goto sw_init_done;
 	}
 	pf->qp_pile->num_entries = pf->hw.func_caps.num_tx_qp;
-	pf->qp_pile->search_hint = 0;
 
 	pf->tx_timeout_recovery_level = 1;

drivers/net/ethernet/intel/i40e/i40e_virtchnl_pf.c +59 -0

71 lines not on this page · raw message

Greg Kroah-Hartman

author maintainer

2022-01-31 11:12 UTC #77 lore raw

PATCH 77/171 i40e: Fix queues reservation for XDP

From: Sylwester Dziedziuch <[email protected]>

commit 92947844b8beee988c0ce17082b705c2f75f0742 upstream.

When XDP was configured on a system with large number of CPUs and X722 NIC there was a call trace with NULL pointer dereference.

i40e 0000:87:00.0: failed to get tracking for 256 queues for VSI 0 err -12 i40e 0000:87:00.0: setup of MAIN VSI failed

BUG: kernel NULL pointer dereference, address: 0000000000000000
RIP: 0010:i40e_xdp+0xea/0x1b0 [i40e]
Call Trace:
? i40e_reconfig_rss_queues+0x130/0x130 [i40e]
dev_xdp_install+0x61/0xe0
dev_xdp_attach+0x18a/0x4c0
dev_change_xdp_fd+0x1e6/0x220
do_setlink+0x616/0x1030
? ahci_port_stop+0x80/0x80
? ata_qc_issue+0x107/0x1e0
? lock_timer_base+0x61/0x80
? __mod_timer+0x202/0x380
rtnl_setlink+0xe5/0x170
? bpf_lsm_binder_transaction+0x10/0x10
? security_capable+0x36/0x50
rtnetlink_rcv_msg+0x121/0x350
? rtnl_calcit.isra.0+0x100/0x100
netlink_rcv_skb+0x50/0xf0
netlink_unicast+0x1d3/0x2a0
netlink_sendmsg+0x22a/0x440
sock_sendmsg+0x5e/0x60
__sys_sendto+0xf0/0x160
? __sys_getsockname+0x7e/0xc0
? _copy_from_user+0x3c/0x80
? __sys_setsockopt+0xc8/0x1a0
__x64_sys_sendto+0x20/0x30
do_syscall_64+0x33/0x40
entry_SYSCALL_64_after_hwframe+0x44/0xae
RIP: 0033:0x7f83fa7a39e0

This was caused by PF queue pile fragmentation due to flow director VSI queue being placed right after main VSI. Because of this main VSI was not able to resize its queue allocation for XDP resulting in no queues allocated for main VSI when XDP was turned on.

Fix this by always allocating last queue in PF queue pile for a flow director VSI.

Fixes 41c445ff0f48 ("i40e: main driver core")

Fixes 74608d17fe29 ("i40e: add support for XDP_TX action")

Signed-off-by Sylwester Dziedziuch <[email protected]>

Signed-off-by Mateusz Palczewski <[email protected]>

Reviewed-by Maciej Fijalkowski <[email protected]>

Tested-by Kiran Bhandare <[email protected]>

Signed-off-by Tony Nguyen <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 drivers/net/ethernet/intel/i40e/i40e_main.c |   14 ++++++++++++++
 1 file changed, 14 insertions(+)

drivers/net/ethernet/intel/i40e/i40e_main.c +14 -0

@@ -210,6 +210,20 @@ static int i40e_get_lump(struct i40e_pf
 		return -EINVAL;
 	}
 
+	/* Allocate last queue in the pile for FDIR VSI queue
+	 * so it doesn't fragment the qp_pile
+	 */
+	if (pile == pf->qp_pile && pf->vsi[id]->type == I40E_VSI_FDIR) {
+		if (pile->list[pile->num_entries - 1] & I40E_PILE_VALID_BIT) {
+			dev_err(&pf->pdev->dev,
+				"Cannot allocate queue %d for I40E_VSI_FDIR\n",
+				pile->num_entries - 1);
+			return -ENOMEM;
+		}
+		pile->list[pile->num_entries - 1] = id | I40E_PILE_VALID_BIT;
+		return pile->num_entries - 1;
+	}
+
 	i = 0;
 	while (i < pile->num_entries) {
 		/* skip already allocated entries */

Greg Kroah-Hartman

author maintainer

2022-01-31 11:12 UTC #78 lore raw

PATCH 78/171 i40e: Fix for failed to init adminq while VF reset

From: Karen Sornek <[email protected]>

commit 0f344c8129a5337dae50e31b817dd50a60ff238c upstream.

Fix for failed to init adminq: -53 while VF is resetting via MAC address changing procedure.
Added sync module to avoid reading deadbeef value in reinit adminq during software reset.
Without this patch it is possible to trigger VF reset procedure during reinit adminq. This resulted in an incorrect reading of value from the AQP registers and generated the -53 error.

Fixes 5c3c48ac6bf5 ("i40e: implement virtual device interface")

Signed-off-by Grzegorz Szczurek <[email protected]>

Signed-off-by Karen Sornek <[email protected]>

Tested-by Konrad Jankowski <[email protected]>

Signed-off-by Tony Nguyen <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 drivers/net/ethernet/intel/i40e/i40e_register.h    |    3 +
 drivers/net/ethernet/intel/i40e/i40e_virtchnl_pf.c |   44 ++++++++++++++++++++-
 drivers/net/ethernet/intel/i40e/i40e_virtchnl_pf.h |    1 
 3 files changed, 46 insertions(+), 2 deletions(-)

drivers/net/ethernet/intel/i40e/i40e_register.h +3 -0

@@ -413,6 +413,9 @@
 #define I40E_VFINT_DYN_CTLN(_INTVF) (0x00024800 + ((_INTVF) * 4)) /* _i=0...511 */ /* Reset: VFR */
 #define I40E_VFINT_DYN_CTLN_CLEARPBA_SHIFT 1
 #define I40E_VFINT_DYN_CTLN_CLEARPBA_MASK I40E_MASK(0x1, I40E_VFINT_DYN_CTLN_CLEARPBA_SHIFT)
+#define I40E_VFINT_ICR0_ADMINQ_SHIFT 30
+#define I40E_VFINT_ICR0_ADMINQ_MASK I40E_MASK(0x1, I40E_VFINT_ICR0_ADMINQ_SHIFT)
+#define I40E_VFINT_ICR0_ENA(_VF) (0x0002C000 + ((_VF) * 4)) /* _i=0...127 */ /* Reset: CORER */
 #define I40E_VPINT_AEQCTL(_VF) (0x0002B800 + ((_VF) * 4)) /* _i=0...127 */ /* Reset: CORER */
 #define I40E_VPINT_AEQCTL_MSIX_INDX_SHIFT 0
 #define I40E_VPINT_AEQCTL_ITR_INDX_SHIFT 11

drivers/net/ethernet/intel/i40e/i40e_virtchnl_pf.c +42 -2

64 lines not on this page · raw message

drivers/net/ethernet/intel/i40e/i40e_virtchnl_pf.h +1 -0

@@ -19,6 +19,7 @@
 #define I40E_MAX_VF_PROMISC_FLAGS	3
 
 #define I40E_VF_STATE_WAIT_COUNT	20
+#define I40E_VFR_WAIT_COUNT		100
 
 /* Various queue ctrls */
 enum i40e_queue_ctrl {

Greg Kroah-Hartman

author maintainer

2022-01-31 11:13 UTC #79 lore raw

PATCH 79/171 i40e: fix unsigned stat widths

From: Joe Damato <[email protected]>

commit 3b8428b84539c78fdc8006c17ebd25afd4722d51 upstream.

Change i40e_update_vsi_stats and struct i40e_vsi to use u64 fields to match the width of the stats counters in struct i40e_rx_queue_stats.

Update debugfs code to use the correct format specifier for u64.

Fixes 41c445ff0f48 ("i40e: main driver core")

Signed-off-by Joe Damato <[email protected]>

Reported-by kernel test robot <[email protected]>

Tested-by Gurucharan G <[email protected]>

Signed-off-by Tony Nguyen <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 drivers/net/ethernet/intel/i40e/i40e.h         |    8 ++++----
 drivers/net/ethernet/intel/i40e/i40e_debugfs.c |    2 +-
 drivers/net/ethernet/intel/i40e/i40e_main.c    |    4 ++--
 3 files changed, 7 insertions(+), 7 deletions(-)

drivers/net/ethernet/intel/i40e/i40e.h +4 -4

@@ -847,12 +847,12 @@ struct i40e_vsi {
 	struct rtnl_link_stats64 net_stats_offsets;
 	struct i40e_eth_stats eth_stats;
 	struct i40e_eth_stats eth_stats_offsets;
-	u32 tx_restart;
-	u32 tx_busy;
+	u64 tx_restart;
+	u64 tx_busy;
 	u64 tx_linearize;
 	u64 tx_force_wb;
-	u32 rx_buf_failed;
-	u32 rx_page_failed;
+	u64 rx_buf_failed;
+	u64 rx_page_failed;
 
 	/* These are containers of ring pointers, allocated at run-time */
 	struct i40e_ring **rx_rings;

drivers/net/ethernet/intel/i40e/i40e_debugfs.c +1 -1

@@ -240,7 +240,7 @@ static void i40e_dbg_dump_vsi_seid(struc
 		 (unsigned long int)vsi->net_stats_offsets.rx_compressed,
 		 (unsigned long int)vsi->net_stats_offsets.tx_compressed);
 	dev_info(&pf->pdev->dev,
-		 "    tx_restart = %d, tx_busy = %d, rx_buf_failed = %d, rx_page_failed = %d\n",
+		 "    tx_restart = %llu, tx_busy = %llu, rx_buf_failed = %llu, rx_page_failed = %llu\n",
 		 vsi->tx_restart, vsi->tx_busy,
 		 vsi->rx_buf_failed, vsi->rx_page_failed);
 	rcu_read_lock();

drivers/net/ethernet/intel/i40e/i40e_main.c +2 -2

@@ -778,9 +778,9 @@ static void i40e_update_vsi_stats(struct
 	struct rtnl_link_stats64 *ns;   /* netdev stats */
 	struct i40e_eth_stats *oes;
 	struct i40e_eth_stats *es;     /* device's eth stats */
-	u32 tx_restart, tx_busy;
+	u64 tx_restart, tx_busy;
 	struct i40e_ring *p;
-	u32 rx_page, rx_buf;
+	u64 rx_page, rx_buf;
 	u64 bytes, packets;
 	unsigned int start;
 	u64 tx_linearize;

Greg Kroah-Hartman

author maintainer

2022-01-31 11:13 UTC #80 lore raw

PATCH 80/171 usb: roles: fix include/linux/usb/role.h compile issue

From: Linyu Yuan <[email protected]>

commit 945c37ed564770c78dfe6b9f08bed57a1b4e60ef upstream.

when CONFIG_USB_ROLE_SWITCH is not defined,
add usb_role_switch_find_by_fwnode() definition which return NULL.

Fixes c6919d5e0cd1 ("usb: roles: Add usb_role_switch_find_by_fwnode()")

Signed-off-by Linyu Yuan <[email protected]>

Link https://lore.kernel.org/r/[email protected] open here

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 include/linux/usb/role.h |    6 ++++++
 1 file changed, 6 insertions(+)

include/linux/usb/role.h +6 -0

@@ -92,6 +92,12 @@ fwnode_usb_role_switch_get(struct fwnode
 static inline void usb_role_switch_put(struct usb_role_switch *sw) { }
 
 static inline struct usb_role_switch *
+usb_role_switch_find_by_fwnode(const struct fwnode_handle *fwnode)
+{
+	return NULL;
+}
+
+static inline struct usb_role_switch *
 usb_role_switch_register(struct device *parent,
 			 const struct usb_role_switch_desc *desc)
 {

Greg Kroah-Hartman

author maintainer

2022-01-31 11:13 UTC #81 lore raw

PATCH 81/171 rpmsg: char: Fix race between the release of rpmsg_ctrldev and cdev

Link https://lore.kernel.org/r/20220110104706.v6.1.Iaac908f3e3149a89190ce006ba166e2d3fd247a3@changeid open here

From: Sujit Kautkar <[email protected]>

commit b7fb2dad571d1e21173c06cef0bced77b323990a upstream.

struct rpmsg_ctrldev contains a struct cdev. The current code frees the rpmsg_ctrldev struct in rpmsg_ctrldev_release_device(), but the cdev is a managed object, therefore its release is not predictable and the rpmsg_ctrldev could be freed before the cdev is entirely released, as in the backtrace below.

[   93.625603] ODEBUG: free active (active state 0) object type: timer_list hint: delayed_work_timer_fn+0x0/0x7c
[   93.636115] WARNING: CPU: 0 PID: 12 at lib/debugobjects.c:488 debug_print_object+0x13c/0x1b0
[   93.644799] Modules linked in: veth xt_cgroup xt_MASQUERADE rfcomm algif_hash algif_skcipher af_alg uinput ip6table_nat fuse uvcvideo videobuf2_vmalloc venus_enc venus_dec videobuf2_dma_contig hci_uart btandroid btqca snd_soc_rt5682_i2c bluetooth qcom_spmi_temp_alarm snd_soc_rt5682v
[   93.715175] CPU: 0 PID: 12 Comm: kworker/0:1 Tainted: G    B             5.4.163-lockdep #26
[   93.723855] Hardware name: Google Lazor (rev3 - 8) with LTE (DT)
[   93.730055] Workqueue: events kobject_delayed_cleanup
[   93.735271] pstate: 60c00009 (nZCv daif +PAN +UAO)
[   93.740216] pc : debug_print_object+0x13c/0x1b0
[   93.744890] lr : debug_print_object+0x13c/0x1b0
[   93.749555] sp : ffffffacf5bc7940
[   93.752978] x29: ffffffacf5bc7940 x28: dfffffd000000000
[   93.758448] x27: ffffffacdb11a800 x26: dfffffd000000000
[   93.763916] x25: ffffffd0734f856c x24: dfffffd000000000
[   93.769389] x23: 0000000000000000 x22: ffffffd0733c35b0
[   93.774860] x21: ffffffd0751994a0 x20: ffffffd075ec27c0
[   93.780338] x19: ffffffd075199100 x18: 00000000000276e0
[   93.785814] x17: 0000000000000000 x16: dfffffd000000000
[   93.791291] x15: ffffffffffffffff x14: 6e6968207473696c
[   93.796768] x13: 0000000000000000 x12: ffffffd075e2b000
[   93.802244] x11: 0000000000000001 x10: 0000000000000000
[   93.807723] x9 : d13400dff1921900 x8 : d13400dff1921900
[   93.813200] x7 : 0000000000000000 x6 : 0000000000000000
[   93.818676] x5 : 0000000000000080 x4 : 0000000000000000
[   93.824152] x3 : ffffffd0732a0fa4 x2 : 0000000000000001
[   93.829628] x1 : ffffffacf5bc7580 x0 : 0000000000000061
[   93.835104] Call trace:
[   93.837644]  debug_print_object+0x13c/0x1b0
[   93.841963]  __debug_check_no_obj_freed+0x25c/0x3c0
[   93.846987]  debug_check_no_obj_freed+0x18/0x20
[   93.851669]  slab_free_freelist_hook+0xbc/0x1e4
[   93.856346]  kfree+0xfc/0x2f4
[   93.859416]  rpmsg_ctrldev_release_device+0x78/0xb8
[   93.864445]  device_release+0x84/0x168
[   93.868310]  kobject_cleanup+0x12c/0x298
[   93.872356]  kobject_delayed_cleanup+0x10/0x18
[   93.876948]  process_one_work+0x578/0x92c
[   93.881086]  worker_thread+0x804/0xcf8
[   93.884963]  kthread+0x2a8/0x314
[   93.888303]  ret_from_fork+0x10/0x18

The cdev_device_add/del() API was created to address this issue (see commit '233ed09d7fda ("chardev: add helper function to register char devs with a struct device")'), use it instead of cdev add/del().

Fixes c0cdc19f84a4 ("rpmsg: Driver for user space endpoint interface")

Signed-off-by Sujit Kautkar <[email protected]>

Signed-off-by Matthias Kaehlcke <[email protected]>

Reviewed-by Mathieu Poirier <[email protected]>

Reviewed-by Bjorn Andersson <[email protected]>

Reviewed-by Stephen Boyd <[email protected]>

Signed-off-by Bjorn Andersson <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 drivers/rpmsg/rpmsg_char.c |   11 ++---------
 1 file changed, 2 insertions(+), 9 deletions(-)

drivers/rpmsg/rpmsg_char.c +2 -9

@@ -461,7 +461,6 @@ static void rpmsg_ctrldev_release_device
 
 	ida_simple_remove(&rpmsg_ctrl_ida, dev->id);
 	ida_simple_remove(&rpmsg_minor_ida, MINOR(dev->devt));
-	cdev_del(&ctrldev->cdev);
 	kfree(ctrldev);
 }

@@ -496,19 +495,13 @@ static int rpmsg_chrdev_probe(struct rpm
 	dev->id = ret;
 	dev_set_name(&ctrldev->dev, "rpmsg_ctrl%d", ret);
 
-	ret = cdev_add(&ctrldev->cdev, dev->devt, 1);
+	ret = cdev_device_add(&ctrldev->cdev, &ctrldev->dev);
 	if (ret)
 		goto free_ctrl_ida;
 
 	/* We can now rely on the release function for cleanup */
 	dev->release = rpmsg_ctrldev_release_device;
 
-	ret = device_add(dev);
-	if (ret) {
-		dev_err(&rpdev->dev, "device_add failed: %d\n", ret);
-		put_device(dev);
-	}
-
 	dev_set_drvdata(&rpdev->dev, ctrldev);
 
 	return ret;

@@ -534,7 +527,7 @@ static void rpmsg_chrdev_remove(struct r
 	if (ret)
 		dev_warn(&rpdev->dev, "failed to nuke endpoints: %d\n", ret);
 
-	device_del(&ctrldev->dev);
+	cdev_device_del(&ctrldev->cdev, &ctrldev->dev);
 	put_device(&ctrldev->dev);
 }

Greg Kroah-Hartman

author maintainer

2022-01-31 11:13 UTC #82 lore raw

PATCH 82/171 rpmsg: char: Fix race between the release of rpmsg_eptdev and cdev

Link https://lore.kernel.org/r/20220110104706.v6.2.Idde68b05b88d4a2e6e54766c653f3a6d9e419ce6@changeid open here

From: Matthias Kaehlcke <[email protected]>

commit 7a534ae89e34e9b51acb5a63dd0f88308178b46a upstream.

struct rpmsg_eptdev contains a struct cdev. The current code frees the rpmsg_eptdev struct in rpmsg_eptdev_destroy(), but the cdev is a managed object, therefore its release is not predictable and the rpmsg_eptdev could be freed before the cdev is entirely released.

Fixes c0cdc19f84a4 ("rpmsg: Driver for user space endpoint interface")

Signed-off-by Matthias Kaehlcke <[email protected]>

Reviewed-by Mathieu Poirier <[email protected]>

Reviewed-by Stephen Boyd <[email protected]>

Reviewed-by Bjorn Andersson <[email protected]>

Signed-off-by Bjorn Andersson <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 drivers/rpmsg/rpmsg_char.c |   11 ++---------
 1 file changed, 2 insertions(+), 9 deletions(-)

drivers/rpmsg/rpmsg_char.c +2 -9

@@ -92,7 +92,7 @@ static int rpmsg_eptdev_destroy(struct d
 	/* wake up any blocked readers */
 	wake_up_interruptible(&eptdev->readq);
 
-	device_del(&eptdev->dev);
+	cdev_device_del(&eptdev->cdev, &eptdev->dev);
 	put_device(&eptdev->dev);
 
 	return 0;

@@ -335,7 +335,6 @@ static void rpmsg_eptdev_release_device(
 
 	ida_simple_remove(&rpmsg_ept_ida, dev->id);
 	ida_simple_remove(&rpmsg_minor_ida, MINOR(eptdev->dev.devt));
-	cdev_del(&eptdev->cdev);
 	kfree(eptdev);
 }

@@ -380,19 +379,13 @@ static int rpmsg_eptdev_create(struct rp
 	dev->id = ret;
 	dev_set_name(dev, "rpmsg%d", ret);
 
-	ret = cdev_add(&eptdev->cdev, dev->devt, 1);
+	ret = cdev_device_add(&eptdev->cdev, &eptdev->dev);
 	if (ret)
 		goto free_ept_ida;
 
 	/* We can now rely on the release function for cleanup */
 	dev->release = rpmsg_eptdev_release_device;
 
-	ret = device_add(dev);
-	if (ret) {
-		dev_err(dev, "device_add failed: %d\n", ret);
-		put_device(dev);
-	}
-
 	return ret;
 
 free_ept_ida:

Greg Kroah-Hartman

author maintainer

2022-01-31 11:13 UTC #83 lore raw

PATCH 83/171 scsi: elx: efct: Dont use GFP_KERNEL under spin lock

From: Yang Yingliang <[email protected]>

commit 61263b3a11a2594b4e898f166c31162236182b5c upstream.

GFP_KERNEL/GFP_DMA can't be used under a spin lock. According the comment, els_ios_lock is used to protect els ios list so we can move down the spin lock to avoid using this flag under the lock.

Link https://lore.kernel.org/r/[email protected] open here

Fixes 8f406ef72859 ("scsi: elx: libefc: Extended link Service I/O handling")

Reported-by Hulk Robot <[email protected]>

Reviewed-by James Smart <[email protected]>

Signed-off-by Yang Yingliang <[email protected]>

Signed-off-by Martin K. Petersen <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 drivers/scsi/elx/libefc/efc_els.c |    8 ++------
 1 file changed, 2 insertions(+), 6 deletions(-)

drivers/scsi/elx/libefc/efc_els.c +2 -6

@@ -46,18 +46,14 @@ efc_els_io_alloc_size(struct efc_node *n
 
 	efc = node->efc;
 
-	spin_lock_irqsave(&node->els_ios_lock, flags);
-
 	if (!node->els_io_enabled) {
 		efc_log_err(efc, "els io alloc disabled\n");
-		spin_unlock_irqrestore(&node->els_ios_lock, flags);
 		return NULL;
 	}
 
 	els = mempool_alloc(efc->els_io_pool, GFP_ATOMIC);
 	if (!els) {
 		atomic_add_return(1, &efc->els_io_alloc_failed_count);
-		spin_unlock_irqrestore(&node->els_ios_lock, flags);
 		return NULL;
 	}

@@ -74,7 +70,6 @@ efc_els_io_alloc_size(struct efc_node *n
 					      &els->io.req.phys, GFP_DMA);
 	if (!els->io.req.virt) {
 		mempool_free(els, efc->els_io_pool);
-		spin_unlock_irqrestore(&node->els_ios_lock, flags);
 		return NULL;
 	}

@@ -94,10 +89,11 @@ efc_els_io_alloc_size(struct efc_node *n
 
 		/* add els structure to ELS IO list */
 		INIT_LIST_HEAD(&els->list_entry);
+		spin_lock_irqsave(&node->els_ios_lock, flags);
 		list_add_tail(&els->list_entry, &node->els_ios_list);
+		spin_unlock_irqrestore(&node->els_ios_lock, flags);
 	}
 
-	spin_unlock_irqrestore(&node->els_ios_lock, flags);
 	return els;
 }

Greg Kroah-Hartman

author maintainer

2022-01-31 11:13 UTC #84 lore raw

PATCH 84/171 scsi: bnx2fc: Flush destroy_work queue before calling bnx2fc_interface_put()

From: John Meneghini <[email protected]>

commit 847f9ea4c5186fdb7b84297e3eeed9e340e83fce upstream.

The bnx2fc_destroy() functions are removing the interface before calling destroy_work. This results multiple WARNings from sysfs_remove_group() as the controller rport device attributes are removed too early.

Replace the fcoe_port's destroy_work queue. It's not needed.

The problem is easily reproducible with the following steps.

Example:

  $ dmesg -w &
  $ systemctl enable --now fcoe
  $ fipvlan -s -c ens2f1
  $ fcoeadm -d ens2f1.802
  [  583.464488] host2: libfc: Link down on port (7500a1)
  [  583.472651] bnx2fc: 7500a1 - rport not created Yet!!
  [  583.490468] ------------[ cut here ]------------
  [  583.538725] sysfs group 'power' not found for kobject 'rport-2:0-0'
  [  583.568814] WARNING: CPU: 3 PID: 192 at fs/sysfs/group.c:279 sysfs_remove_group+0x6f/0x80
  [  583.607130] Modules linked in: dm_service_time 8021q garp mrp stp llc bnx2fc cnic uio rpcsec_gss_krb5 auth_rpcgss nfsv4 ...
  [  583.942994] CPU: 3 PID: 192 Comm: kworker/3:2 Kdump: loaded Not tainted 5.14.0-39.el9.x86_64 #1
  [  583.984105] Hardware name: HP ProLiant DL120 G7, BIOS J01 07/01/2013
  [  584.016535] Workqueue: fc_wq_2 fc_rport_final_delete [scsi_transport_fc]
  [  584.050691] RIP: 0010:sysfs_remove_group+0x6f/0x80
  [  584.074725] Code: ff 5b 48 89 ef 5d 41 5c e9 ee c0 ff ff 48 89 ef e8 f6 b8 ff ff eb d1 49 8b 14 24 48 8b 33 48 c7 c7 ...
  [  584.162586] RSP: 0018:ffffb567c15afdc0 EFLAGS: 00010282
  [  584.188225] RAX: 0000000000000000 RBX: ffffffff8eec4220 RCX: 0000000000000000
  [  584.221053] RDX: ffff8c1586ce84c0 RSI: ffff8c1586cd7cc0 RDI: ffff8c1586cd7cc0
  [  584.255089] RBP: 0000000000000000 R08: 0000000000000000 R09: ffffb567c15afc00
  [  584.287954] R10: ffffb567c15afbf8 R11: ffffffff8fbe7f28 R12: ffff8c1486326400
  [  584.322356] R13: ffff8c1486326480 R14: ffff8c1483a4a000 R15: 0000000000000004
  [  584.355379] FS:  0000000000000000(0000) GS:ffff8c1586cc0000(0000) knlGS:0000000000000000
  [  584.394419] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
  [  584.421123] CR2: 00007fe95a6f7840 CR3: 0000000107674002 CR4: 00000000000606e0
  [  584.454888] Call Trace:
  [  584.466108]  device_del+0xb2/0x3e0
  [  584.481701]  device_unregister+0x13/0x60
  [  584.501306]  bsg_unregister_queue+0x5b/0x80
  [  584.522029]  bsg_remove_queue+0x1c/0x40
  [  584.541884]  fc_rport_final_delete+0xf3/0x1d0 [scsi_transport_fc]
  [  584.573823]  process_one_work+0x1e3/0x3b0
  [  584.592396]  worker_thread+0x50/0x3b0
  [  584.609256]  ? rescuer_thread+0x370/0x370
  [  584.628877]  kthread+0x149/0x170
  [  584.643673]  ? set_kthread_struct+0x40/0x40
  [  584.662909]  ret_from_fork+0x22/0x30
  [  584.680002] ---[ end trace 53575ecefa942ece ]---

Link https://lore.kernel.org/r/[email protected] open here

Fixes 0cbf32e1681d ("[SCSI] bnx2fc: Avoid calling bnx2fc_if_destroy with unnecessary locks")

Tested-by Guangwu Zhang <[email protected]>

Co-developed-by Maurizio Lombardi <[email protected]>

Signed-off-by Maurizio Lombardi <[email protected]>

Signed-off-by John Meneghini <[email protected]>

Signed-off-by Martin K. Petersen <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 drivers/scsi/bnx2fc/bnx2fc_fcoe.c |   20 +++++---------------
 1 file changed, 5 insertions(+), 15 deletions(-)

drivers/scsi/bnx2fc/bnx2fc_fcoe.c +5 ~~-15~~

@@ -82,7 +82,7 @@ static int bnx2fc_bind_pcidev(struct bnx
 static void bnx2fc_unbind_pcidev(struct bnx2fc_hba *hba);
 static struct fc_lport *bnx2fc_if_create(struct bnx2fc_interface *interface,
 				  struct device *parent, int npiv);
-static void bnx2fc_destroy_work(struct work_struct *work);
+static void bnx2fc_port_destroy(struct fcoe_port *port);
 
 static struct bnx2fc_hba *bnx2fc_hba_lookup(struct net_device *phys_dev);
 static struct bnx2fc_interface *bnx2fc_interface_lookup(struct net_device

@@ -907,9 +907,6 @@ static void bnx2fc_indicate_netevent(voi
 				__bnx2fc_destroy(interface);
 		}
 		mutex_unlock(&bnx2fc_dev_lock);
-
-		/* Ensure ALL destroy work has been completed before return */
-		flush_workqueue(bnx2fc_wq);
 		return;
 
 	default:

@@ -1215,8 +1212,8 @@ static int bnx2fc_vport_destroy(struct f
 	mutex_unlock(&n_port->lp_mutex);
 	bnx2fc_free_vport(interface->hba, port->lport);
 	bnx2fc_port_shutdown(port->lport);
+	bnx2fc_port_destroy(port);
 	bnx2fc_interface_put(interface);
-	queue_work(bnx2fc_wq, &port->destroy_work);
 	return 0;
 }

@@ -1525,7 +1522,6 @@ static struct fc_lport *bnx2fc_if_create
 	port->lport = lport;
 	port->priv = interface;
 	port->get_netdev = bnx2fc_netdev;
-	INIT_WORK(&port->destroy_work, bnx2fc_destroy_work);
 
 	/* Configure fcoe_port */
 	rc = bnx2fc_lport_config(lport);

@@ -1653,8 +1649,8 @@ static void __bnx2fc_destroy(struct bnx2
 	bnx2fc_interface_cleanup(interface);
 	bnx2fc_stop(interface);
 	list_del(&interface->list);
+	bnx2fc_port_destroy(port);
 	bnx2fc_interface_put(interface);
-	queue_work(bnx2fc_wq, &port->destroy_work);
 }
 
 /**

@@ -1694,15 +1690,12 @@ netdev_err:
 	return rc;
 }
 
-static void bnx2fc_destroy_work(struct work_struct *work)
+static void bnx2fc_port_destroy(struct fcoe_port *port)
 {
-	struct fcoe_port *port;
 	struct fc_lport *lport;
 
-	port = container_of(work, struct fcoe_port, destroy_work);
 	lport = port->lport;
-
-	BNX2FC_HBA_DBG(lport, "Entered bnx2fc_destroy_work\n");
+	BNX2FC_HBA_DBG(lport, "Entered %s, destroying lport %p\n", __func__, lport);
 
 	bnx2fc_if_destroy(lport);
 }

@@ -2556,9 +2549,6 @@ static void bnx2fc_ulp_exit(struct cnic_
 			__bnx2fc_destroy(interface);
 	mutex_unlock(&bnx2fc_dev_lock);
 
-	/* Ensure ALL destroy work has been completed before return */
-	flush_workqueue(bnx2fc_wq);
-
 	bnx2fc_ulp_stop(hba);
 	/* unregister cnic device */
 	if (test_and_clear_bit(BNX2FC_CNIC_REGISTERED, &hba->reg_with_cnic))

Greg Kroah-Hartman

author maintainer

2022-01-31 11:13 UTC #85 lore raw

PATCH 85/171 ipv6_tunnel: Rate limit warning messages

From: Ido Schimmel <[email protected]>

commit 6cee105e7f2ced596373951d9ea08dacc3883c68 upstream.

The warning messages can be invoked from the data path for every packet transmitted through an ip6gre netdev, leading to high CPU utilization.

Fix that by rate limiting the messages.

Fixes 09c6bbf090ec ("[IPV6]: Do mandatory IPv6 tunnel endpoint checks in realtime")

Reported-by Maksym Yaremchuk <[email protected]>

Tested-by Maksym Yaremchuk <[email protected]>

Signed-off-by Ido Schimmel <[email protected]>

Reviewed-by Amit Cohen <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

---
 net/ipv6/ip6_tunnel.c |    8 ++++----
 1 file changed, 4 insertions(+), 4 deletions(-)

net/ipv6/ip6_tunnel.c +4 -4

@@ -1036,14 +1036,14 @@ int ip6_tnl_xmit_ctl(struct ip6_tnl *t,
 
 		if (unlikely(!ipv6_chk_addr_and_flags(net, laddr, ldev, false,
 						      0, IFA_F_TENTATIVE)))
-			pr_warn("%s xmit: Local address not yet configured!\n",
-				p->name);
+			pr_warn_ratelimited("%s xmit: Local address not yet configured!\n",
+					    p->name);
 		else if (!(p->flags & IP6_TNL_F_ALLOW_LOCAL_REMOTE) &&
 			 !ipv6_addr_is_multicast(raddr) &&
 			 unlikely(ipv6_chk_addr_and_flags(net, raddr, ldev,
 							  true, 0, IFA_F_TENTATIVE)))
-			pr_warn("%s xmit: Routing loop! Remote address found on this node!\n",
-				p->name);
+			pr_warn_ratelimited("%s xmit: Routing loop! Remote address found on this node!\n",
+					    p->name);
 		else
 			ret = 1;
 		rcu_read_unlock();

Greg Kroah-Hartman

author maintainer

2022-01-31 11:13 UTC #86 lore raw

PATCH 86/171 ARM: 9170/1: fix panic when kasan and kprobe are enabled

From: sparkhuang <[email protected]>

commit 8b59b0a53c840921b625378f137e88adfa87647e upstream.

arm32 uses software to simulate the instruction replaced by kprobe. some instructions may be simulated by constructing assembly functions. therefore, before executing instruction simulation, it is necessary to construct assembly function execution environment in C language through binding registers. after kasan is enabled, the register binding relationship will be destroyed, resulting in instruction simulation errors and causing kernel panic.

the kprobe emulate instruction function is distributed in three
files: actions-common.c actions-arm.c actions-thumb.c, so disable KASAN when compiling these files.

for example, use kprobe insert on cap_capable+20 after kasan enabled, the cap_capable assembly code is as follows:
<cap_capable>:
e92d47f0 push {r4, r5, r6, r7, r8, r9, sl, lr}
e1a05000 mov r5, r0
e280006c add r0, r0, #108 ; 0x6c
e1a04001 mov r4, r1
e1a06002 mov r6, r2
e59fa090 ldr sl, [pc, #144] ;
ebfc7bf8 bl c03aa4b4 <__asan_load4>
e595706c ldr r7, [r5, #108] ; 0x6c
e2859014 add r9, r5, #20
......
The emulate_ldr assembly code after enabling kasan is as follows:
c06f1384 <emulate_ldr>:
e92d47f0 push {r4, r5, r6, r7, r8, r9, sl, lr}
e282803c add r8, r2, #60 ; 0x3c
e1a05000 mov r5, r0
e7e37855 ubfx r7, r5, #16, #4
e1a00008 mov r0, r8
e1a09001 mov r9, r1
e1a04002 mov r4, r2
ebf35462 bl c03c6530 <__asan_load4>
e357000f cmp r7, #15
e7e36655 ubfx r6, r5, #12, #4
e205a00f and sl, r5, #15
0a000001 beq c06f13bc <emulate_ldr+0x38>
e0840107 add r0, r4, r7, lsl #2
ebf3545c bl c03c6530 <__asan_load4>
e084010a add r0, r4, sl, lsl #2
ebf3545a bl c03c6530 <__asan_load4>
e2890010 add r0, r9, #16
ebf35458 bl c03c6530 <__asan_load4>
e5990010 ldr r0, [r9, #16]
e12fff30 blx r0
e356000f cm r6, #15
1a000014 bne c06f1430 <emulate_ldr+0xac>
e1a06000 mov r6, r0
e2840040 add r0, r4, #64 ; 0x40
......

when running in emulate_ldr to simulate the ldr instruction, panic occurred, and the log is as follows:

Unable to handle kernel NULL pointer dereference at virtual address
00000090
pgd = ecb46400
[00000090] *pgd=2e0fa003, *pmd=00000000
Internal error: Oops: 206 [#1] SMP ARM
PC is at cap_capable+0x14/0xb0
LR is at emulate_ldr+0x50/0xc0

psr: 600d0293 sp : ecd63af8 ip : 00000004 fp : c0a7c30c
r10: 00000000 r9 : c30897f4 r8 : ecd63cd4
r7 : 0000000f r6 : 0000000a r5 : e59fa090 r4 : ecd63c98 r3 : c06ae294 r2 : 00000000 r1 : b7611300 r0 : bf4ec008
Flags: nZCv IRQs off FIQs on Mode SVC_32 ISA ARM Segment user
Control: 32c5387d Table: 2d546400 DAC: 55555555 Process bash (pid: 1643, stack limit = 0xecd60190) (cap_capable) from (kprobe_handler+0x218/0x340) (kprobe_handler) from (kprobe_trap_handler+0x24/0x48) (kprobe_trap_handler) from (do_undefinstr+0x13c/0x364) (do_undefinstr) from (__und_svc_finish+0x0/0x30) (__und_svc_finish) from (cap_capable+0x18/0xb0) (cap_capable) from (cap_vm_enough_memory+0x38/0x48) (cap_vm_enough_memory) from (security_vm_enough_memory_mm+0x48/0x6c) (security_vm_enough_memory_mm) from (copy_process.constprop.5+0x16b4/0x25c8) (copy_process.constprop.5) from (_do_fork+0xe8/0x55c) (_do_fork) from (SyS_clone+0x1c/0x24)
(SyS_clone) from (__sys_trace_return+0x0/0x10)

Code: 0050a0e1 6c0080e2 0140a0e1 0260a0e1 (f801f0e7)

Fixes 35aa1df43283 ("ARM kprobes: instruction single-stepping support")

Fixes 421015713b30 ("ARM: 9017/2: Enable KASan for ARM")

Signed-off-by huangshaobo <[email protected]>

Acked-by Ard Biesheuvel <[email protected]>

Signed-off-by Russell King (Oracle) <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 arch/arm/probes/kprobes/Makefile |    3 +++
 1 file changed, 3 insertions(+)

arch/arm/probes/kprobes/Makefile +3 -0

@@ -1,4 +1,7 @@
 # SPDX-License-Identifier: GPL-2.0
+KASAN_SANITIZE_actions-common.o := n
+KASAN_SANITIZE_actions-arm.o := n
+KASAN_SANITIZE_actions-thumb.o := n
 obj-$(CONFIG_KPROBES)		+= core.o actions-common.o checkers-common.o
 obj-$(CONFIG_ARM_KPROBES_TEST)	+= test-kprobes.o
 test-kprobes-objs		:= test-core.o

Greg Kroah-Hartman

author maintainer

2022-01-31 11:13 UTC #87 lore raw

PATCH 87/171 net: fix information leakage in /proc/net/ptype

From: Congyu Liu <[email protected]>

commit 47934e06b65637c88a762d9c98329ae6e3238888 upstream.

In one net namespace, after creating a packet socket without binding it to a device, users in other net namespaces can observe the new packet_type added by this packet socket by reading /proc/net/ptype file. This is minor information leakage as packet socket is namespace aware.

Add a net pointer in packet_type to keep the net namespace of of corresponding packet socket. In ptype_seq_show, this net pointer must be checked when it is not NULL.

Fixes 2feb27dbe00c ("[NETNS]: Minor information leak via /proc/net/ptype file.")

Signed-off-by Congyu Liu <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

---
 include/linux/netdevice.h |    1 +
 net/core/net-procfs.c     |    3 ++-
 net/packet/af_packet.c    |    2 ++
 3 files changed, 5 insertions(+), 1 deletion(-)

include/linux/netdevice.h +1 -0

@@ -2636,6 +2636,7 @@ struct packet_type {
 					      struct net_device *);
 	bool			(*id_match)(struct packet_type *ptype,
 					    struct sock *sk);
+	struct net		*af_packet_net;
 	void			*af_packet_priv;
 	struct list_head	list;
 };

net/core/net-procfs.c +2 -1

@@ -260,7 +260,8 @@ static int ptype_seq_show(struct seq_fil
 
 	if (v == SEQ_START_TOKEN)
 		seq_puts(seq, "Type Device      Function\n");
-	else if (pt->dev == NULL || dev_net(pt->dev) == seq_file_net(seq)) {
+	else if ((!pt->af_packet_net || net_eq(pt->af_packet_net, seq_file_net(seq))) &&
+		 (!pt->dev || net_eq(dev_net(pt->dev), seq_file_net(seq)))) {
 		if (pt->type == htons(ETH_P_ALL))
 			seq_puts(seq, "ALL ");
 		else

net/packet/af_packet.c +2 -0

@@ -1738,6 +1738,7 @@ static int fanout_add(struct sock *sk, s
 		match->prot_hook.dev = po->prot_hook.dev;
 		match->prot_hook.func = packet_rcv_fanout;
 		match->prot_hook.af_packet_priv = match;
+		match->prot_hook.af_packet_net = read_pnet(&match->net);
 		match->prot_hook.id_match = match_fanout_group;
 		match->max_num_members = args->max_num_members;
 		list_add(&match->list, &fanout_list);

@@ -3323,6 +3324,7 @@ static int packet_create(struct net *net
 		po->prot_hook.func = packet_rcv_spkt;
 
 	po->prot_hook.af_packet_priv = sk;
+	po->prot_hook.af_packet_net = sock_net(sk);
 
 	if (proto) {
 		po->prot_hook.type = proto;

Greg Kroah-Hartman

author maintainer

2022-01-31 11:14 UTC #88 lore raw

PATCH 88/171 hwmon: (lm90) Mark alert as broken for MAX6646/6647/6649

From: Guenter Roeck <[email protected]>

commit f614629f9c1080dcc844a8430e3fb4c37ebbf05d upstream.

Experiments with MAX6646 and MAX6648 show that the alert function of those chips is broken, similar to other chips supported by the lm90 driver. Mark it accordingly.

Fixes 4667bcb8d8fc ("hwmon: (lm90) Introduce chip parameter structure")

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 drivers/hwmon/lm90.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

drivers/hwmon/lm90.c +1 -1

@@ -394,7 +394,7 @@ static const struct lm90_params lm90_par
 		.max_convrate = 9,
 	},
 	[max6646] = {
-		.flags = LM90_HAVE_CRIT,
+		.flags = LM90_HAVE_CRIT | LM90_HAVE_BROKEN_ALERT,
 		.alert_alarms = 0x7c,
 		.max_convrate = 6,
 		.reg_local_ext = MAX6657_REG_R_LOCAL_TEMPL,

Greg Kroah-Hartman

author maintainer

2022-01-31 11:14 UTC #89 lore raw

PATCH 89/171 hwmon: (lm90) Mark alert as broken for MAX6680

From: Guenter Roeck <[email protected]>

commit 94746b0ba479743355e0d3cc1cb9cfe3011fb8be upstream.

Experiments with MAX6680 and MAX6681 show that the alert function of those chips is broken, similar to other chips supported by the lm90 driver. Mark it accordingly.

Fixes 4667bcb8d8fc ("hwmon: (lm90) Introduce chip parameter structure")

Signed-off-by Greg Kroah-Hartman <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

---
 drivers/hwmon/lm90.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

drivers/hwmon/lm90.c +1 -1

@@ -418,7 +418,7 @@ static const struct lm90_params lm90_par
 	},
 	[max6680] = {
 		.flags = LM90_HAVE_OFFSET | LM90_HAVE_CRIT
-		  | LM90_HAVE_CRIT_ALRM_SWP,
+		  | LM90_HAVE_CRIT_ALRM_SWP | LM90_HAVE_BROKEN_ALERT,
 		.alert_alarms = 0x7c,
 		.max_convrate = 7,
 	},

Greg Kroah-Hartman

author maintainer

2022-01-31 11:16 UTC #90 lore raw

PATCH 90/171 ping: fix the sk_bound_dev_if match in ping_lookup

From: Xin Long <[email protected]>

commit 2afc3b5a31f9edf3ef0f374f5d70610c79c93a42 upstream.

When 'ping' changes to use PING socket instead of RAW socket by:

   # sysctl -w net.ipv4.ping_group_range="0 100"

the selftests 'router_broadcast.sh' will fail, as such command

  # ip vrf exec vrf-h1 ping -I veth0 198.51.100.255 -b

can't receive the response skb by the PING socket. It's caused by mismatch of sk_bound_dev_if and dif in ping_rcv() when looking up the PING socket, as dif is vrf-h1 if dif's master was set to vrf-h1.

This patch is to fix this regression by also checking the sk_bound_dev_if against sdif so that the packets can stil be received even if the socket is not bound to the vrf device but to the real iif.

Fixes c319b4d76b9e ("net: ipv4: add IPPROTO_ICMP socket kind")

Reported-by Hangbin Liu <[email protected]>

Signed-off-by Xin Long <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

---
 net/ipv4/ping.c |    3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

net/ipv4/ping.c +2 -1

@@ -220,7 +220,8 @@ static struct sock *ping_lookup(struct n
 			continue;
 		}
 
-		if (sk->sk_bound_dev_if && sk->sk_bound_dev_if != dif)
+		if (sk->sk_bound_dev_if && sk->sk_bound_dev_if != dif &&
+		    sk->sk_bound_dev_if != inet_sdif(skb))
 			continue;
 
 		sock_hold(sk);

Greg Kroah-Hartman

author maintainer

2022-01-31 11:14 UTC #91 lore raw

PATCH 91/171 ipv4: avoid using shared IP generator for connected sockets

From: Eric Dumazet <[email protected]>

commit 23f57406b82de51809d5812afd96f210f8b627f3 upstream.

ip_select_ident_segs() has been very conservative about using the connected socket private generator only for packets with IP_DF set, claiming it was needed for some VJ compression implementations.

As mentioned in this referenced document, this can be abused. (Ref: Off-Path TCP Exploits of the Mixed IPID Assignment)

Before switching to pure random IPID generation and possibly hurt some workloads, lets use the private inet socket generator.

Not only this will remove one vulnerability, this will also improve performance of TCP flows using pmtudisc==IP_PMTUDISC_DONT

Fixes 73f156a6e8c1 ("inetpeer: get rid of ip_id_count")

Reviewed-by David Ahern <[email protected]>

Reported-by Ray Che <[email protected]>

Cc Willy Tarreau <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 include/net/ip.h |   21 ++++++++++-----------
 1 file changed, 10 insertions(+), 11 deletions(-)

include/net/ip.h +10 ~~-11~~

@@ -520,19 +520,18 @@ static inline void ip_select_ident_segs(
 {
 	struct iphdr *iph = ip_hdr(skb);
 
+	/* We had many attacks based on IPID, use the private
+	 * generator as much as we can.
+	 */
+	if (sk && inet_sk(sk)->inet_daddr) {
+		iph->id = htons(inet_sk(sk)->inet_id);
+		inet_sk(sk)->inet_id += segs;
+		return;
+	}
 	if ((iph->frag_off & htons(IP_DF)) && !skb->ignore_df) {
-		/* This is only to work around buggy Windows95/2000
-		 * VJ compression implementations.  If the ID field
-		 * does not change, they drop every other packet in
-		 * a TCP stream using header compression.
-		 */
-		if (sk && inet_sk(sk)->inet_daddr) {
-			iph->id = htons(inet_sk(sk)->inet_id);
-			inet_sk(sk)->inet_id += segs;
-		} else {
-			iph->id = 0;
-		}
+		iph->id = 0;
 	} else {
+		/* Unfortunately we need the big hammer to get a suitable IPID */
 		__ip_select_ident(net, iph, segs);
 	}
 }

Greg Kroah-Hartman

author maintainer

2022-01-31 11:16 UTC #92 lore raw

PATCH 92/171 hwmon: (lm90) Reduce maximum conversion rate for G781

From: Guenter Roeck <[email protected]>

[ Upstream commit a66c5ed539277b9f2363bbace0dba88b85b36c26 ]

According to its datasheet, G781 supports a maximum conversion rate value of 8 (62.5 ms). However, chips labeled G781 and G780 were found to only support a maximum conversion rate value of 7 (125 ms). On the other side, chips labeled G781-1 and G784 were found to support a conversion rate value of 8. There is no known means to distinguish G780 from G781 or G784; all chips report the same manufacturer ID and chip revision. Setting the conversion rate register value to 8 on chips not supporting it causes unexpected behavior since the real conversion rate is set to 0 (16 seconds) if a value of 8 is written into the conversion rate register. Limit the conversion rate register value to 7 for all G78x chips to avoid the problem.

Fixes ae544f64cc7b ("hwmon: (lm90) Add support for GMT G781")

Signed-off-by Sasha Levin <[email protected]>

---
 drivers/hwmon/lm90.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

drivers/hwmon/lm90.c +1 -1

@@ -373,7 +373,7 @@ static const struct lm90_params lm90_par
 		.flags = LM90_HAVE_OFFSET | LM90_HAVE_REM_LIMIT_EXT
 		  | LM90_HAVE_BROKEN_ALERT | LM90_HAVE_CRIT,
 		.alert_alarms = 0x7c,
-		.max_convrate = 8,
+		.max_convrate = 7,
 	},
 	[lm86] = {
 		.flags = LM90_HAVE_OFFSET | LM90_HAVE_REM_LIMIT_EXT

Greg Kroah-Hartman

author maintainer

2022-01-31 11:20 UTC #93 lore raw

PATCH 93/171 NFSv4: Handle case where the lookup of a directory fails

From: Trond Myklebust <[email protected]>

commit ac795161c93699d600db16c1a8cc23a65a1eceaf upstream.

If the application sets the O_DIRECTORY flag, and tries to open a regular file, nfs_atomic_open() will punt to doing a regular lookup. If the server then returns a regular file, we will happily return a file descriptor with uninitialised open state.

The fix is to return the expected ENOTDIR error in these cases.

Reported-by Lyu Tao <[email protected]>

Fixes 0dd2b474d0b6 ("nfs: implement i_op->atomic_open()")

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 fs/nfs/dir.c |   13 +++++++++++++
 1 file changed, 13 insertions(+)

fs/nfs/dir.c +13 -0

@@ -1982,6 +1982,19 @@ out:
 
 no_open:
 	res = nfs_lookup(dir, dentry, lookup_flags);
+	if (!res) {
+		inode = d_inode(dentry);
+		if ((lookup_flags & LOOKUP_DIRECTORY) && inode &&
+		    !S_ISDIR(inode->i_mode))
+			res = ERR_PTR(-ENOTDIR);
+	} else if (!IS_ERR(res)) {
+		inode = d_inode(res);
+		if ((lookup_flags & LOOKUP_DIRECTORY) && inode &&
+		    !S_ISDIR(inode->i_mode)) {
+			dput(res);
+			res = ERR_PTR(-ENOTDIR);
+		}
+	}
 	if (switched) {
 		d_lookup_done(dentry);
 		if (!res)

Greg Kroah-Hartman

author maintainer

2022-01-31 11:21 UTC #94 lore raw

PATCH 94/171 NFSv4: nfs_atomic_open() can race when looking up a non-regular file

From: Trond Myklebust <[email protected]>

commit 1751fc1db36f6f411709e143d5393f92d12137a9 upstream.

If the file type changes back to being a regular file on the server between the failed OPEN and our LOOKUP, then we need to re-run the OPEN.

Fixes 0dd2b474d0b6 ("nfs: implement i_op->atomic_open()")

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 fs/nfs/dir.c |    5 +++++
 1 file changed, 5 insertions(+)

fs/nfs/dir.c +5 -0

@@ -1987,12 +1987,17 @@ no_open:
 		if ((lookup_flags & LOOKUP_DIRECTORY) && inode &&
 		    !S_ISDIR(inode->i_mode))
 			res = ERR_PTR(-ENOTDIR);
+		else if (inode && S_ISREG(inode->i_mode))
+			res = ERR_PTR(-EOPENSTALE);
 	} else if (!IS_ERR(res)) {
 		inode = d_inode(res);
 		if ((lookup_flags & LOOKUP_DIRECTORY) && inode &&
 		    !S_ISDIR(inode->i_mode)) {
 			dput(res);
 			res = ERR_PTR(-ENOTDIR);
+		} else if (inode && S_ISREG(inode->i_mode)) {
+			dput(res);
+			res = ERR_PTR(-EOPENSTALE);
 		}
 	}
 	if (switched) {

Greg Kroah-Hartman

author maintainer

2022-01-31 11:17 UTC #95 lore raw

PATCH 95/171 net-procfs: show net devices bound packet types

From: Jianguo Wu <[email protected]>

commit 1d10f8a1f40b965d449e8f2d5ed7b96a7c138b77 upstream.

After commit:7866a621043f ("dev: add per net_device packet type chains"), we can not get packet types that are bound to a specified net device by /proc/net/ptype, this patch fix the regression.

Run "tcpdump -i ens192 udp -nns0" Before and after apply this patch:

Before:
[root@localhost ~]# cat /proc/net/ptype
Type Device Function

  0800          ip_rcv
  0806          arp_rcv
  86dd          ipv6_rcv

After:
[root@localhost ~]# cat /proc/net/ptype
Type Device Function

  ALL  ens192   tpacket_rcv
  0800          ip_rcv
  0806          arp_rcv
  86dd          ipv6_rcv

v1 -> v2:
- fix the regression rather than adding new /proc API as suggested by Stephen Hemminger.

Fixes 7866a621043f ("dev: add per net_device packet type chains")

Signed-off-by Jianguo Wu <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 net/core/net-procfs.c |   35 ++++++++++++++++++++++++++++++++---
 1 file changed, 32 insertions(+), 3 deletions(-)

net/core/net-procfs.c +32 -3

@@ -190,12 +190,23 @@ static const struct seq_operations softn
 	.show  = softnet_seq_show,
 };
 
-static void *ptype_get_idx(loff_t pos)
+static void *ptype_get_idx(struct seq_file *seq, loff_t pos)
 {
+	struct list_head *ptype_list = NULL;
 	struct packet_type *pt = NULL;
+	struct net_device *dev;
 	loff_t i = 0;
 	int t;
 
+	for_each_netdev_rcu(seq_file_net(seq), dev) {
+		ptype_list = &dev->ptype_all;
+		list_for_each_entry_rcu(pt, ptype_list, list) {
+			if (i == pos)
+				return pt;
+			++i;
+		}
+	}
+
 	list_for_each_entry_rcu(pt, &ptype_all, list) {
 		if (i == pos)
 			return pt;

@@ -216,22 +227,40 @@ static void *ptype_seq_start(struct seq_
 	__acquires(RCU)
 {
 	rcu_read_lock();
-	return *pos ? ptype_get_idx(*pos - 1) : SEQ_START_TOKEN;
+	return *pos ? ptype_get_idx(seq, *pos - 1) : SEQ_START_TOKEN;
 }
 
 static void *ptype_seq_next(struct seq_file *seq, void *v, loff_t *pos)
 {
+	struct net_device *dev;
 	struct packet_type *pt;
 	struct list_head *nxt;
 	int hash;
 
 	++*pos;
 	if (v == SEQ_START_TOKEN)
-		return ptype_get_idx(0);
+		return ptype_get_idx(seq, 0);
 
 	pt = v;
 	nxt = pt->list.next;
+	if (pt->dev) {
+		if (nxt != &pt->dev->ptype_all)
+			goto found;
+
+		dev = pt->dev;
+		for_each_netdev_continue_rcu(seq_file_net(seq), dev) {
+			if (!list_empty(&dev->ptype_all)) {
+				nxt = dev->ptype_all.next;
+				goto found;
+			}
+		}
+
+		nxt = ptype_all.next;
+		goto ptype_all;
+	}
+
 	if (pt->type == htons(ETH_P_ALL)) {
+ptype_all:
 		if (nxt != &ptype_all)
 			goto found;
 		hash = 0;

Greg Kroah-Hartman

author maintainer

2022-01-31 11:22 UTC #96 lore raw

PATCH 96/171 drm/msm: Fix wrong size calculation

From: Xianting Tian <[email protected]>

commit 0a727b459ee39bd4c5ced19d6024258ac87b6b2e upstream.

For example, memory-region in .dts as below,

	reg = <0x0 0x50000000 0x0 0x20000000>

We can get below values,
struct resource r;
r.start = 0x50000000;
r.end = 0x6fffffff;

So the size should be:
size = r.end - r.start + 1 = 0x20000000

Signed-off-by Xianting Tian <[email protected]>

Fixes 072f1f9168ed ("drm/msm: add support for "stolen" mem")

Link https://lore.kernel.org/r/[email protected] open here

Signed-off-by Greg Kroah-Hartman <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

---
 drivers/gpu/drm/msm/msm_drv.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

drivers/gpu/drm/msm/msm_drv.c +1 -1

@@ -437,7 +437,7 @@ static int msm_init_vram(struct drm_devi
 		of_node_put(node);
 		if (ret)
 			return ret;
-		size = r.end - r.start;
+		size = r.end - r.start + 1;
 		DRM_INFO("using VRAM carveout: %lx@%pa\n", size, &r.start);
 
 		/* if we have no IOMMU, then we need to use carveout allocator.

Greg Kroah-Hartman

author maintainer

2022-01-31 11:21 UTC #97 lore raw

PATCH 97/171 drm/msm/dsi: Fix missing put_device() call in dsi_get_phy

From: Miaoqian Lin <[email protected]>

commit c04c3148ca12227d92f91b355b4538cc333c9922 upstream.

If of_find_device_by_node() succeeds, dsi_get_phy() doesn't a corresponding put_device(). Thus add put_device() to fix the exception handling.

Fixes ec31abf ("drm/msm/dsi: Separate PHY to another platform device")

Signed-off-by Miaoqian Lin <[email protected]>

Link https://lore.kernel.org/r/[email protected] open here

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 drivers/gpu/drm/msm/dsi/dsi.c |    7 ++++++-
 1 file changed, 6 insertions(+), 1 deletion(-)

drivers/gpu/drm/msm/dsi/dsi.c +6 -1

@@ -40,7 +40,12 @@ static int dsi_get_phy(struct msm_dsi *m
 
 	of_node_put(phy_node);
 
-	if (!phy_pdev || !msm_dsi->phy) {
+	if (!phy_pdev) {
+		DRM_DEV_ERROR(&pdev->dev, "%s: phy driver is not ready\n", __func__);
+		return -EPROBE_DEFER;
+	}
+	if (!msm_dsi->phy) {
+		put_device(&phy_pdev->dev);
 		DRM_DEV_ERROR(&pdev->dev, "%s: phy driver is not ready\n", __func__);
 		return -EPROBE_DEFER;
 	}

Greg Kroah-Hartman

author maintainer

2022-01-31 11:14 UTC #98 lore raw

PATCH 98/171 drm/msm/dsi: invalid parameter check in msm_dsi_phy_enable

From: José Expósito <[email protected]>

commit 5e761a2287234bc402ba7ef07129f5103bcd775c upstream.

The function performs a check on the "phy" input parameter, however, it is used before the check.

Initialize the "dev" variable after the sanity check to avoid a possible NULL pointer dereference.

Fixes 5c8290284402b ("drm/msm/dsi: Split PHY drivers to separate files")

Addresses-Coverity-ID: 1493860 ("Null pointer dereference")

Signed-off-by José Expósito <[email protected]>

Link https://lore.kernel.org/r/[email protected] open here

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 drivers/gpu/drm/msm/dsi/phy/dsi_phy.c |    4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

drivers/gpu/drm/msm/dsi/phy/dsi_phy.c +3 -1

@@ -806,12 +806,14 @@ int msm_dsi_phy_enable(struct msm_dsi_ph
 			struct msm_dsi_phy_clk_request *clk_req,
 			struct msm_dsi_phy_shared_timings *shared_timings)
 {
-	struct device *dev = &phy->pdev->dev;
+	struct device *dev;
 	int ret;
 
 	if (!phy || !phy->cfg->ops.enable)
 		return -EINVAL;
 
+	dev = &phy->pdev->dev;
+
 	ret = dsi_phy_enable_resource(phy);
 	if (ret) {
 		DRM_DEV_ERROR(dev, "%s: resource enable failed, %d\n",

Greg Kroah-Hartman

author maintainer

2022-01-31 11:14 UTC #99 lore raw

PATCH 99/171 ipv6: annotate accesses to fn->fn_sernum

From: Eric Dumazet <[email protected]>

commit aafc2e3285c2d7a79b7ee15221c19fbeca7b1509 upstream.

struct fib6_node's fn_sernum field can be
read while other threads change it.

Add READ_ONCE()/WRITE_ONCE() annotations.

Do not change existing smp barriers in fib6_get_cookie_safe() and __fib6_update_sernum_upto_root()

syzbot reported:

BUG: KCSAN: data-race in fib6_clean_node / inet6_csk_route_socket

write to 0xffff88813df62e2c of 4 bytes by task 1920 on cpu 1:

 fib6_clean_node+0xc2/0x260 net/ipv6/ip6_fib.c:2178
 fib6_walk_continue+0x38e/0x430 net/ipv6/ip6_fib.c:2112
 fib6_walk net/ipv6/ip6_fib.c:2160 [inline]
 fib6_clean_tree net/ipv6/ip6_fib.c:2240 [inline]
 __fib6_clean_all+0x1a9/0x2e0 net/ipv6/ip6_fib.c:2256
 fib6_flush_trees+0x6c/0x80 net/ipv6/ip6_fib.c:2281
 rt_genid_bump_ipv6 include/net/net_namespace.h:488 [inline]
 addrconf_dad_completed+0x57f/0x870 net/ipv6/addrconf.c:4230
 addrconf_dad_work+0x908/0x1170
 process_one_work+0x3f6/0x960 kernel/workqueue.c:2307
 worker_thread+0x616/0xa70 kernel/workqueue.c:2454
 kthread+0x1bf/0x1e0 kernel/kthread.c:359
 ret_from_fork+0x1f/0x30

read to 0xffff88813df62e2c of 4 bytes by task 15701 on cpu 0:

 fib6_get_cookie_safe include/net/ip6_fib.h:285 [inline]
 rt6_get_cookie include/net/ip6_fib.h:306 [inline]
 ip6_dst_store include/net/ip6_route.h:234 [inline]
 inet6_csk_route_socket+0x352/0x3c0 net/ipv6/inet6_connection_sock.c:109
 inet6_csk_xmit+0x91/0x1e0 net/ipv6/inet6_connection_sock.c:121
 __tcp_transmit_skb+0x1323/0x1840 net/ipv4/tcp_output.c:1402
 tcp_transmit_skb net/ipv4/tcp_output.c:1420 [inline]
 tcp_write_xmit+0x1450/0x4460 net/ipv4/tcp_output.c:2680
 __tcp_push_pending_frames+0x68/0x1c0 net/ipv4/tcp_output.c:2864
 tcp_push+0x2d9/0x2f0 net/ipv4/tcp.c:725
 mptcp_push_release net/mptcp/protocol.c:1491 [inline]
 __mptcp_push_pending+0x46c/0x490 net/mptcp/protocol.c:1578
 mptcp_sendmsg+0x9ec/0xa50 net/mptcp/protocol.c:1764
 inet6_sendmsg+0x5f/0x80 net/ipv6/af_inet6.c:643
 sock_sendmsg_nosec net/socket.c:705 [inline]
 sock_sendmsg net/socket.c:725 [inline]
 kernel_sendmsg+0x97/0xd0 net/socket.c:745
 sock_no_sendpage+0x84/0xb0 net/core/sock.c:3086
 inet_sendpage+0x9d/0xc0 net/ipv4/af_inet.c:834
 kernel_sendpage+0x187/0x200 net/socket.c:3492
 sock_sendpage+0x5a/0x70 net/socket.c:1007
 pipe_to_sendpage+0x128/0x160 fs/splice.c:364
 splice_from_pipe_feed fs/splice.c:418 [inline]
 __splice_from_pipe+0x207/0x500 fs/splice.c:562
 splice_from_pipe fs/splice.c:597 [inline]
 generic_splice_sendpage+0x94/0xd0 fs/splice.c:746
 do_splice_from fs/splice.c:767 [inline]
 direct_splice_actor+0x80/0xa0 fs/splice.c:936
 splice_direct_to_actor+0x345/0x650 fs/splice.c:891
 do_splice_direct+0x106/0x190 fs/splice.c:979
 do_sendfile+0x675/0xc40 fs/read_write.c:1245
 __do_sys_sendfile64 fs/read_write.c:1310 [inline]
 __se_sys_sendfile64 fs/read_write.c:1296 [inline]
 __x64_sys_sendfile64+0x102/0x140 fs/read_write.c:1296
 do_syscall_x64 arch/x86/entry/common.c:50 [inline]
 do_syscall_64+0x44/0xd0 arch/x86/entry/common.c:80
 entry_SYSCALL_64_after_hwframe+0x44/0xae

value changed: 0x0000026f -> 0x00000271

Reported by Kernel Concurrency Sanitizer on:

CPU: 0 PID: 15701 Comm: syz-executor.2 Not tainted 5.16.0-syzkaller #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011

The Fixes tag I chose is probably arbitrary, I do not think we need to backport this patch to older kernels.

Fixes c5cff8561d2d ("ipv6: add rcu grace period before freeing fib6_node")

Reported-by syzbot <[email protected]>

Link https://lore.kernel.org/r/[email protected] open here

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 include/net/ip6_fib.h |    2 +-
 net/ipv6/ip6_fib.c    |   23 +++++++++++++----------
 net/ipv6/route.c      |    2 +-
 3 files changed, 15 insertions(+), 12 deletions(-)

include/net/ip6_fib.h +1 -1

@@ -281,7 +281,7 @@ static inline bool fib6_get_cookie_safe(
 	fn = rcu_dereference(f6i->fib6_node);
 
 	if (fn) {
-		*cookie = fn->fn_sernum;
+		*cookie = READ_ONCE(fn->fn_sernum);
 		/* pairs with smp_wmb() in __fib6_update_sernum_upto_root() */
 		smp_rmb();
 		status = true;

net/ipv6/ip6_fib.c +13 ~~-10~~

@@ -111,7 +111,7 @@ void fib6_update_sernum(struct net *net,
 	fn = rcu_dereference_protected(f6i->fib6_node,
 			lockdep_is_held(&f6i->fib6_table->tb6_lock));
 	if (fn)
-		fn->fn_sernum = fib6_new_sernum(net);
+		WRITE_ONCE(fn->fn_sernum, fib6_new_sernum(net));
 }
 
 /*

@@ -589,12 +589,13 @@ static int fib6_dump_table(struct fib6_t
 		spin_unlock_bh(&table->tb6_lock);
 		if (res > 0) {
 			cb->args[4] = 1;
-			cb->args[5] = w->root->fn_sernum;
+			cb->args[5] = READ_ONCE(w->root->fn_sernum);
 		}
 	} else {
-		if (cb->args[5] != w->root->fn_sernum) {
+		int sernum = READ_ONCE(w->root->fn_sernum);
+		if (cb->args[5] != sernum) {
 			/* Begin at the root if the tree changed */
-			cb->args[5] = w->root->fn_sernum;
+			cb->args[5] = sernum;
 			w->state = FWS_INIT;
 			w->node = w->root;
 			w->skip = w->count;

@@ -1344,7 +1345,7 @@ static void __fib6_update_sernum_upto_ro
 	/* paired with smp_rmb() in fib6_get_cookie_safe() */
 	smp_wmb();
 	while (fn) {
-		fn->fn_sernum = sernum;
+		WRITE_ONCE(fn->fn_sernum, sernum);
 		fn = rcu_dereference_protected(fn->parent,
 				lockdep_is_held(&rt->fib6_table->tb6_lock));
 	}

@@ -2173,8 +2174,8 @@ static int fib6_clean_node(struct fib6_w
 	};
 
 	if (c->sernum != FIB6_NO_SERNUM_CHANGE &&
-	    w->node->fn_sernum != c->sernum)
-		w->node->fn_sernum = c->sernum;
+	    READ_ONCE(w->node->fn_sernum) != c->sernum)
+		WRITE_ONCE(w->node->fn_sernum, c->sernum);
 
 	if (!c->func) {
 		WARN_ON_ONCE(c->sernum == FIB6_NO_SERNUM_CHANGE);

@@ -2542,7 +2543,7 @@ static void ipv6_route_seq_setup_walk(st
 	iter->w.state = FWS_INIT;
 	iter->w.node = iter->w.root;
 	iter->w.args = iter;
-	iter->sernum = iter->w.root->fn_sernum;
+	iter->sernum = READ_ONCE(iter->w.root->fn_sernum);
 	INIT_LIST_HEAD(&iter->w.lh);
 	fib6_walker_link(net, &iter->w);
 }

@@ -2570,8 +2571,10 @@ static struct fib6_table *ipv6_route_seq
 
 static void ipv6_route_check_sernum(struct ipv6_route_iter *iter)
 {
-	if (iter->sernum != iter->w.root->fn_sernum) {
-		iter->sernum = iter->w.root->fn_sernum;
+	int sernum = READ_ONCE(iter->w.root->fn_sernum);
+
+	if (iter->sernum != sernum) {
+		iter->sernum = sernum;
 		iter->w.state = FWS_INIT;
 		iter->w.node = iter->w.root;
 		WARN_ON(iter->w.skip);

net/ipv6/route.c +1 -1

@@ -2802,7 +2802,7 @@ static void ip6_link_failure(struct sk_b
 			if (from) {
 				fn = rcu_dereference(from->fib6_node);
 				if (fn && (rt->rt6i_flags & RTF_DEFAULT))
-					fn->fn_sernum = -1;
+					WRITE_ONCE(fn->fn_sernum, -1);
 			}
 		}
 		rcu_read_unlock();

Greg Kroah-Hartman

author maintainer

2022-01-31 11:22 UTC #100 lore raw

PATCH 100/171 NFS: Ensure the server has an up to date ctime before hardlinking

From: Trond Myklebust <[email protected]>

[ Upstream commit 204975036b34f55237bc44c8a302a88468ef21b5 ]

Creating a hard link is required by POSIX to update the file ctime, so ensure that the file data is synced to disk so that we don't clobber the updated ctime by writing back after creating the hard link.

Fixes 9f7682728728 ("NFS: Move the delegation return down into nfs4_proc_link()")

Signed-off-by Sasha Levin <[email protected]>

---
 fs/nfs/dir.c |    2 ++
 1 file changed, 2 insertions(+)

fs/nfs/dir.c +2 -0

@@ -2400,6 +2400,8 @@ nfs_link(struct dentry *old_dentry, stru
 
 	trace_nfs_link_enter(inode, dir, dentry);
 	d_drop(dentry);
+	if (S_ISREG(inode->i_mode))
+		nfs_sync_inode(inode);
 	error = NFS_PROTO(dir)->link(inode, dir, &dentry->d_name);
 	if (error == 0) {
 		ihold(inode);

Greg Kroah-Hartman

author maintainer

2022-01-31 11:22 UTC #101 lore raw

PATCH 101/171 NFS: Ensure the server has an up to date ctime before renaming

From: Trond Myklebust <[email protected]>

[ Upstream commit 6ff9d99bb88faebf134ca668842349d9718e5464 ]

Renaming a file is required by POSIX to update the file ctime, so ensure that the file data is synced to disk so that we don't clobber the updated ctime by writing back after creating the hard link.

Fixes f2c2c552f119 ("NFS: Move delegation recall into the NFSv4 callback for rename_setup()")

Signed-off-by Sasha Levin <[email protected]>

---
 fs/nfs/dir.c |    2 ++
 1 file changed, 2 insertions(+)

fs/nfs/dir.c +2 -0

@@ -2490,6 +2490,8 @@ int nfs_rename(struct user_namespace *mn
 		}
 	}
 
+	if (S_ISREG(old_inode->i_mode))
+		nfs_sync_inode(old_inode);
 	task = nfs_async_rename(old_dir, new_dir, old_dentry, new_dentry, NULL);
 	if (IS_ERR(task)) {
 		error = PTR_ERR(task);

Greg Kroah-Hartman

author maintainer

2022-01-31 11:22 UTC #102 lore raw

PATCH 102/171 KVM: arm64: pkvm: Use the mm_ops indirection for cache maintenance

From: Marc Zyngier <[email protected]>

[ Upstream commit 094d00f8ca58c5d29b25e23b4daaed1ff1f13b41 ]

CMOs issued from EL2 cannot directly use the kernel helpers, as EL2 doesn't have a mapping of the guest pages. Oops.

Instead, use the mm_ops indirection to use helpers that will perform a mapping at EL2 and allow the CMO to be effective.

Fixes 25aa28691bb9 ("KVM: arm64: Move guest CMOs to the fault handlers")

Reviewed-by Quentin Perret <[email protected]>

Link https://lore.kernel.org/r/[email protected] open here

Signed-off-by Sasha Levin <[email protected]>

---
 arch/arm64/kvm/hyp/pgtable.c | 18 ++++++------------
 1 file changed, 6 insertions(+), 12 deletions(-)

arch/arm64/kvm/hyp/pgtable.c +6 ~~-12~~

index f8ceebe4982eb..4c77ff556f0ae 100644
@@ -921,13 +921,9 @@ static int stage2_unmap_walker(u64 addr, u64 end, u32 level, kvm_pte_t *ptep,
 	 */
 	stage2_put_pte(ptep, mmu, addr, level, mm_ops);
 
-	if (need_flush) {
-		kvm_pte_t *pte_follow = kvm_pte_follow(pte, mm_ops);
-
-		dcache_clean_inval_poc((unsigned long)pte_follow,
-				    (unsigned long)pte_follow +
-					    kvm_granule_size(level));
-	}
+	if (need_flush && mm_ops->dcache_clean_inval_poc)
+		mm_ops->dcache_clean_inval_poc(kvm_pte_follow(pte, mm_ops),
+					       kvm_granule_size(level));
 
 	if (childp)
 		mm_ops->put_page(childp);

@@ -1089,15 +1085,13 @@ static int stage2_flush_walker(u64 addr, u64 end, u32 level, kvm_pte_t *ptep,
 	struct kvm_pgtable *pgt = arg;
 	struct kvm_pgtable_mm_ops *mm_ops = pgt->mm_ops;
 	kvm_pte_t pte = *ptep;
-	kvm_pte_t *pte_follow;
 
 	if (!kvm_pte_valid(pte) || !stage2_pte_cacheable(pgt, pte))
 		return 0;
 
-	pte_follow = kvm_pte_follow(pte, mm_ops);
-	dcache_clean_inval_poc((unsigned long)pte_follow,
-			    (unsigned long)pte_follow +
-				    kvm_granule_size(level));
+	if (mm_ops->dcache_clean_inval_poc)
+		mm_ops->dcache_clean_inval_poc(kvm_pte_follow(pte, mm_ops),
+					       kvm_granule_size(level));
 	return 0;
 }

Signature · 1 line

2.34.1

Greg Kroah-Hartman

author maintainer

2022-01-31 11:15 UTC #103 lore raw

PATCH 103/171 SUNRPC: Use BIT() macro in rpc_show_xprt_state()

From: Chuck Lever <[email protected]>

[ Upstream commit 76497b1adb89175eee85afc437f08a68247314b3 ]

Clean up: BIT() is preferred over open-coding the shift.

Signed-off-by Chuck Lever <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

---
 include/trace/events/sunrpc.h | 24 ++++++++++++------------
 1 file changed, 12 insertions(+), 12 deletions(-)

include/trace/events/sunrpc.h +12 ~~-12~~

index 2d04eb96d4183..312507cb341f4 100644
@@ -925,18 +925,18 @@ TRACE_EVENT(rpc_socket_nospace,
 
 #define rpc_show_xprt_state(x)						\
 	__print_flags(x, "|",						\
-		{ (1UL << XPRT_LOCKED),		"LOCKED"},		\
-		{ (1UL << XPRT_CONNECTED),	"CONNECTED"},		\
-		{ (1UL << XPRT_CONNECTING),	"CONNECTING"},		\
-		{ (1UL << XPRT_CLOSE_WAIT),	"CLOSE_WAIT"},		\
-		{ (1UL << XPRT_BOUND),		"BOUND"},		\
-		{ (1UL << XPRT_BINDING),	"BINDING"},		\
-		{ (1UL << XPRT_CLOSING),	"CLOSING"},		\
-		{ (1UL << XPRT_OFFLINE),	"OFFLINE"},		\
-		{ (1UL << XPRT_REMOVE),		"REMOVE"},		\
-		{ (1UL << XPRT_CONGESTED),	"CONGESTED"},		\
-		{ (1UL << XPRT_CWND_WAIT),	"CWND_WAIT"},		\
-		{ (1UL << XPRT_WRITE_SPACE),	"WRITE_SPACE"})
+		{ BIT(XPRT_LOCKED),		"LOCKED" },		\
+		{ BIT(XPRT_CONNECTED),		"CONNECTED" },		\
+		{ BIT(XPRT_CONNECTING),		"CONNECTING" },		\
+		{ BIT(XPRT_CLOSE_WAIT),		"CLOSE_WAIT" },		\
+		{ BIT(XPRT_BOUND),		"BOUND" },		\
+		{ BIT(XPRT_BINDING),		"BINDING" },		\
+		{ BIT(XPRT_CLOSING),		"CLOSING" },		\
+		{ BIT(XPRT_OFFLINE),		"OFFLINE" },		\
+		{ BIT(XPRT_REMOVE),		"REMOVE" },		\
+		{ BIT(XPRT_CONGESTED),		"CONGESTED" },		\
+		{ BIT(XPRT_CWND_WAIT),		"CWND_WAIT" },		\
+		{ BIT(XPRT_WRITE_SPACE),	"WRITE_SPACE" })
 
 DECLARE_EVENT_CLASS(rpc_xprt_lifetime_class,
 	TP_PROTO(

Signature · 1 line

2.34.1

Greg Kroah-Hartman

author maintainer

2022-01-31 11:15 UTC #104 lore raw

PATCH 104/171 SUNRPC: Dont dereference xprt->snd_task if its a cookie

From: Chuck Lever <[email protected]>

[ Upstream commit aed28b7a2d620cb5cd0c554cb889075c02e25e8e ]

Fixes e26d9972720e ("SUNRPC: Clean up scheduling of autoclose")

Signed-off-by Chuck Lever <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

---
 include/trace/events/sunrpc.h | 18 +++++++++++++-----
 1 file changed, 13 insertions(+), 5 deletions(-)

include/trace/events/sunrpc.h +13 -5

index 312507cb341f4..daaf407e9e494 100644
@@ -936,7 +936,8 @@ TRACE_EVENT(rpc_socket_nospace,
 		{ BIT(XPRT_REMOVE),		"REMOVE" },		\
 		{ BIT(XPRT_CONGESTED),		"CONGESTED" },		\
 		{ BIT(XPRT_CWND_WAIT),		"CWND_WAIT" },		\
-		{ BIT(XPRT_WRITE_SPACE),	"WRITE_SPACE" })
+		{ BIT(XPRT_WRITE_SPACE),	"WRITE_SPACE" },	\
+		{ BIT(XPRT_SND_IS_COOKIE),	"SND_IS_COOKIE" })
 
 DECLARE_EVENT_CLASS(rpc_xprt_lifetime_class,
 	TP_PROTO(

@@ -1133,8 +1134,11 @@ DECLARE_EVENT_CLASS(xprt_writelock_event,
 			__entry->task_id = -1;
 			__entry->client_id = -1;
 		}
-		__entry->snd_task_id = xprt->snd_task ?
-					xprt->snd_task->tk_pid : -1;
+		if (xprt->snd_task &&
+		    !test_bit(XPRT_SND_IS_COOKIE, &xprt->state))
+			__entry->snd_task_id = xprt->snd_task->tk_pid;
+		else
+			__entry->snd_task_id = -1;
 	),
 
 	TP_printk("task:%u@%u snd_task:%u",

@@ -1178,8 +1182,12 @@ DECLARE_EVENT_CLASS(xprt_cong_event,
 			__entry->task_id = -1;
 			__entry->client_id = -1;
 		}
-		__entry->snd_task_id = xprt->snd_task ?
-					xprt->snd_task->tk_pid : -1;
+		if (xprt->snd_task &&
+		    !test_bit(XPRT_SND_IS_COOKIE, &xprt->state))
+			__entry->snd_task_id = xprt->snd_task->tk_pid;
+		else
+			__entry->snd_task_id = -1;
+
 		__entry->cong = xprt->cong;
 		__entry->cwnd = xprt->cwnd;
 		__entry->wait = test_bit(XPRT_CWND_WAIT, &xprt->state);

Signature · 1 line

2.34.1

Greg Kroah-Hartman

author maintainer

2022-01-31 11:15 UTC #105 lore raw

PATCH 105/171 powerpc64/bpf: Limit ldbrx to processors compliant with ISA v2.06

From: Naveen N. Rao <[email protected]>

[ Upstream commit 3f5f766d5f7f95a69a630da3544a1a0cee1cdddf ]

Johan reported the below crash with test_bpf on ppc64 e5500:

test_bpf: #296 ALU_END_FROM_LE 64: 0x0123456789abcdef -> 0x67452301 jited:1

  Oops: Exception in kernel mode, sig: 4 [#1]
  BE PAGE_SIZE=4K SMP NR_CPUS=24 QEMU e500
  Modules linked in: test_bpf(+)
  CPU: 0 PID: 76 Comm: insmod Not tainted 5.14.0-03771-g98c2059e008a-dirty #1
  NIP:  8000000000061c3c LR: 80000000006dea64 CTR: 8000000000061c18
  REGS: c0000000032d3420 TRAP: 0700   Not tainted (5.14.0-03771-g98c2059e008a-dirty)
  MSR:  0000000080089000 <EE,ME>  CR: 88002822  XER: 20000000 IRQMASK: 0
  <...>
  NIP [8000000000061c3c] 0x8000000000061c3c
  LR [80000000006dea64] .__run_one+0x104/0x17c [test_bpf]
  Call Trace:
   .__run_one+0x60/0x17c [test_bpf] (unreliable)
   .test_bpf_init+0x6a8/0xdc8 [test_bpf]
   .do_one_initcall+0x6c/0x28c
   .do_init_module+0x68/0x28c
   .load_module+0x2460/0x2abc
   .__do_sys_init_module+0x120/0x18c
   .system_call_exception+0x110/0x1b8
   system_call_common+0xf0/0x210
  --- interrupt: c00 at 0x101d0acc
  <...>
  ---[ end trace 47b2bf19090bb3d0 ]---

Illegal instruction

The illegal instruction turned out to be 'ldbrx' emitted for BPF_FROM_[L|B]E, which was only introduced in ISA v2.06. Guard use of the same and implement an alternative approach for older processors.

Fixes 156d0e290e969c ("powerpc/ebpf/jit: Implement JIT compiler for extended BPF")

Reported-by Johan Almbladh <[email protected]>

Tested-by Johan Almbladh <[email protected]>

Acked-by Johan Almbladh <[email protected]>

Link https://lore.kernel.org/r/d1e51c6fdf572062cf3009a751c3406bda01b832.1641468127.git.naveen.n.rao@linux.vnet.ibm.com open here

Signed-off-by Sasha Levin <[email protected]>

---
 arch/powerpc/include/asm/ppc-opcode.h |  1 +
 arch/powerpc/net/bpf_jit_comp64.c     | 22 +++++++++++++---------
 2 files changed, 14 insertions(+), 9 deletions(-)

arch/powerpc/include/asm/ppc-opcode.h +1 -0

index baea657bc8687..bca31a61e57f8 100644
@@ -498,6 +498,7 @@
 #define PPC_RAW_LDX(r, base, b)		(0x7c00002a | ___PPC_RT(r) | ___PPC_RA(base) | ___PPC_RB(b))
 #define PPC_RAW_LHZ(r, base, i)		(0xa0000000 | ___PPC_RT(r) | ___PPC_RA(base) | IMM_L(i))
 #define PPC_RAW_LHBRX(r, base, b)	(0x7c00062c | ___PPC_RT(r) | ___PPC_RA(base) | ___PPC_RB(b))
+#define PPC_RAW_LWBRX(r, base, b)	(0x7c00042c | ___PPC_RT(r) | ___PPC_RA(base) | ___PPC_RB(b))
 #define PPC_RAW_LDBRX(r, base, b)	(0x7c000428 | ___PPC_RT(r) | ___PPC_RA(base) | ___PPC_RB(b))
 #define PPC_RAW_STWCX(s, a, b)		(0x7c00012d | ___PPC_RS(s) | ___PPC_RA(a) | ___PPC_RB(b))
 #define PPC_RAW_CMPWI(a, i)		(0x2c000000 | ___PPC_RA(a) | IMM_L(i))

arch/powerpc/net/bpf_jit_comp64.c +13 -9

index 95a337b5dc2b4..57e1b6680365c 100644
@@ -633,17 +633,21 @@ bpf_alu32_trunc:
 				EMIT(PPC_RAW_MR(dst_reg, b2p[TMP_REG_1]));
 				break;
 			case 64:
-				/*
-				 * Way easier and faster(?) to store the value
-				 * into stack and then use ldbrx
-				 *
-				 * ctx->seen will be reliable in pass2, but
-				 * the instructions generated will remain the
-				 * same across all passes
-				 */
+				/* Store the value to stack and then use byte-reverse loads */
 				PPC_BPF_STL(dst_reg, 1, bpf_jit_stack_local(ctx));
 				EMIT(PPC_RAW_ADDI(b2p[TMP_REG_1], 1, bpf_jit_stack_local(ctx)));
-				EMIT(PPC_RAW_LDBRX(dst_reg, 0, b2p[TMP_REG_1]));
+				if (cpu_has_feature(CPU_FTR_ARCH_206)) {
+					EMIT(PPC_RAW_LDBRX(dst_reg, 0, b2p[TMP_REG_1]));
+				} else {
+					EMIT(PPC_RAW_LWBRX(dst_reg, 0, b2p[TMP_REG_1]));
+					if (IS_ENABLED(CONFIG_CPU_LITTLE_ENDIAN))
+						EMIT(PPC_RAW_SLDI(dst_reg, dst_reg, 32));
+					EMIT(PPC_RAW_LI(b2p[TMP_REG_2], 4));
+					EMIT(PPC_RAW_LWBRX(b2p[TMP_REG_2], b2p[TMP_REG_2], b2p[TMP_REG_1]));
+					if (IS_ENABLED(CONFIG_CPU_BIG_ENDIAN))
+						EMIT(PPC_RAW_SLDI(b2p[TMP_REG_2], b2p[TMP_REG_2], 32));
+					EMIT(PPC_RAW_OR(dst_reg, dst_reg, b2p[TMP_REG_2]));
+				}
 				break;
 			}
 			break;

Signature · 1 line

2.34.1

Greg Kroah-Hartman

author maintainer

2022-01-31 11:21 UTC #106 lore raw

PATCH 106/171 netfilter: conntrack: dont increment invalid counter on NF_REPEAT

From: Florian Westphal <[email protected]>

[ Upstream commit 830af2eba40327abec64325a5b08b1e85c37a2e0 ]

The packet isn't invalid, REPEAT means we're trying again after cleaning out a stale connection, e.g. via tcp tracker.

This caused increases of invalid stat counter in a test case involving frequent connection reuse, even though no packet is actually invalid.

Fixes 56a62e2218f5 ("netfilter: conntrack: fix NF_REPEAT handling")

Signed-off-by Florian Westphal <[email protected]>

Signed-off-by Pablo Neira Ayuso <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

---
 net/netfilter/nf_conntrack_core.c | 8 +++++---
 1 file changed, 5 insertions(+), 3 deletions(-)

net/netfilter/nf_conntrack_core.c +5 -3

index 4712a90a1820c..7f79974607643 100644
@@ -1922,15 +1922,17 @@ repeat:
 		pr_debug("nf_conntrack_in: Can't track with proto module\n");
 		nf_conntrack_put(&ct->ct_general);
 		skb->_nfct = 0;
-		NF_CT_STAT_INC_ATOMIC(state->net, invalid);
-		if (ret == -NF_DROP)
-			NF_CT_STAT_INC_ATOMIC(state->net, drop);
 		/* Special case: TCP tracker reports an attempt to reopen a
 		 * closed/aborted connection. We have to go back and create a
 		 * fresh conntrack.
 		 */
 		if (ret == -NF_REPEAT)
 			goto repeat;
+
+		NF_CT_STAT_INC_ATOMIC(state->net, invalid);
+		if (ret == -NF_DROP)
+			NF_CT_STAT_INC_ATOMIC(state->net, drop);
+
 		ret = -ret;
 		goto out;
 	}

Signature · 1 line

2.34.1

Greg Kroah-Hartman

author maintainer

2022-01-31 11:21 UTC #107 lore raw

PATCH 107/171 powerpc/64s: Mask SRR0 before checking against the masked NIP

From: Nicholas Piggin <[email protected]>

[ Upstream commit aee101d7b95a03078945681dd7f7ea5e4a1e7686 ]

Commit 314f6c23dd8d ("powerpc/64s: Mask NIP before checking against SRR0") masked off the low 2 bits of the NIP value in the interrupt stack frame in case they are non-zero and mis-compare against a SRR0 register value of a CPU which always reads back 0 from the 2 low bits which are reserved.

This now causes the opposite problem that an implementation which does implement those bits in SRR0 will mis-compare against the masked NIP value in which they have been cleared. QEMU is one such implementation, and this is allowed by the architecture.

This can be triggered by sigfuz by setting low bits of PT_NIP in the signal context.

Fix this for now by masking the SRR0 bits as well. Cleaner is probably to sanitise these values before putting them in registers or stack, but this is the quick and backportable fix.

Fixes 314f6c23dd8d ("powerpc/64s: Mask NIP before checking against SRR0")

Signed-off-by Nicholas Piggin <[email protected]>

Link https://lore.kernel.org/r/[email protected] open here

Signed-off-by Sasha Levin <[email protected]>

---
 arch/powerpc/kernel/interrupt_64.S | 2 ++
 1 file changed, 2 insertions(+)

arch/powerpc/kernel/interrupt_64.S +2 -0

index 4b1ff94e67eb4..4c6d1a8dcefed 100644
@@ -30,6 +30,7 @@ COMPAT_SYS_CALL_TABLE:
 	.ifc \srr,srr
 	mfspr	r11,SPRN_SRR0
 	ld	r12,_NIP(r1)
+	clrrdi  r11,r11,2
 	clrrdi  r12,r12,2
 100:	tdne	r11,r12
 	EMIT_WARN_ENTRY 100b,__FILE__,__LINE__,(BUGFLAG_WARNING | BUGFLAG_ONCE)

@@ -40,6 +41,7 @@ COMPAT_SYS_CALL_TABLE:
 	.else
 	mfspr	r11,SPRN_HSRR0
 	ld	r12,_NIP(r1)
+	clrrdi  r11,r11,2
 	clrrdi  r12,r12,2
 100:	tdne	r11,r12
 	EMIT_WARN_ENTRY 100b,__FILE__,__LINE__,(BUGFLAG_WARNING | BUGFLAG_ONCE)

Signature · 1 line

2.34.1

Greg Kroah-Hartman

author maintainer

2022-01-31 11:21 UTC #108 lore raw

PATCH 108/171 perf: Fix perf_event_read_local() time

From: Peter Zijlstra <[email protected]>

[ Upstream commit 09f5e7dc7ad705289e1b1ec065439aa3c42951c4 ]

Time readers that cannot take locks (due to NMI etc..) currently make use of perf_event::shadow_ctx_time, which, for that event gives:

time' = now + (time - timestamp)

or, alternatively arranged:

time' = time + (now - timestamp)

IOW, the progression of time since the last time the shadow_ctx_time was updated.

There's problems with this:

A) the shadow_ctx_time is per-event, even though the ctx_time it reflects is obviously per context. The direct concequence of this is that the context needs to iterate all events all the time to keep the shadow_ctx_time in sync.

B) even with the prior point, the context itself might not be active meaning its time should not advance to begin with.

C) shadow_ctx_time isn't consistently updated when ctx_time is

There are 3 users of this stuff, that suffer differently from this:

- calc_timer_values()
- perf_output_read()
- perf_event_update_userpage() /* A */

- perf_event_read_local() /* A,B */

In particular, perf_output_read() doesn't suffer at all, because it's sample driven and hence only relevant when the event is actually running.

This same was supposed to be true for perf_event_update_userpage(), after all self-monitoring implies the context is active *HOWEVER*, as per commit f79256532682 ("perf/core: fix userpage->time_enabled of inactive events") this goes wrong when combined with counter overcommit, in that case those events that do not get scheduled when the context becomes active (task events typically) miss out on the EVENT_TIME update and ENABLED time is inflated (for a little while) with the time the context was inactive. Once the event gets rotated in, this gets corrected, leading to a non-monotonic timeflow.

perf_event_read_local() made things even worse, it can request time at any point, suffering all the problems perf_event_update_userpage() does and more. Because while perf_event_update_userpage() is limited by the context being active, perf_event_read_local() users have no such constraint.

Therefore, completely overhaul things and do away with perf_event::shadow_ctx_time. Instead have regular context time updates keep track of this offset directly and provide perf_event_time_now() to complement perf_event_time().

perf_event_time_now() will, in adition to being context wide, also take into account if the context is active. For inactive context, it will not advance time.

This latter property means the cgroup perf_cgroup_info context needs to grow addition state to track this.

Additionally, since all this is strictly per-cpu, we can use barrier() to order context activity vs context time.

Fixes 7d9285e82db5 ("perf/bpf: Extend the perf_event_read_local() interface, a.k.a. "bpf: perf event change needed for subsequent bpf helpers"")

Signed-off-by Peter Zijlstra (Intel) <[email protected]>

Tested-by Song Liu <[email protected]>

Tested-by Namhyung Kim <[email protected]>

Link https://lkml.kernel.org/r/[email protected] open here

Signed-off-by Sasha Levin <[email protected]>

---
 include/linux/perf_event.h |  15 +--
 kernel/events/core.c       | 246 ++++++++++++++++++++++---------------
 2 files changed, 149 insertions(+), 112 deletions(-)

include/linux/perf_event.h +3 ~~-12~~

index ae1f0c8b75623..6cce33e7e7acc 100644
@@ -680,18 +680,6 @@ struct perf_event {
 	u64				total_time_running;
 	u64				tstamp;
 
-	/*
-	 * timestamp shadows the actual context timing but it can
-	 * be safely used in NMI interrupt context. It reflects the
-	 * context time as it was when the event was last scheduled in,
-	 * or when ctx_sched_in failed to schedule the event because we
-	 * run out of PMC.
-	 *
-	 * ctx_time already accounts for ctx->timestamp. Therefore to
-	 * compute ctx_time for a sample, simply add perf_clock().
-	 */
-	u64				shadow_ctx_time;
-
 	struct perf_event_attr		attr;
 	u16				header_size;
 	u16				id_header_size;

@@ -838,6 +826,7 @@ struct perf_event_context {
 	 */
 	u64				time;
 	u64				timestamp;
+	u64				timeoffset;
 
 	/*
 	 * These fields let us detect when two contexts have both

@@ -920,6 +909,8 @@ struct bpf_perf_event_data_kern {
 struct perf_cgroup_info {
 	u64				time;
 	u64				timestamp;
+	u64				timeoffset;
+	int				active;
 };
 
 struct perf_cgroup {

kernel/events/core.c +146 ~~-100~~

420 lines not on this page · raw message

Signature · 1 line

2.34.1

Greg Kroah-Hartman

author maintainer

2022-01-31 11:14 UTC #109 lore raw

PATCH 109/171 sched/pelt: Relax the sync of util_sum with util_avg

From: Vincent Guittot <[email protected]>

[ Upstream commit 98b0d890220d45418cfbc5157b3382e6da5a12ab ]

Rick reported performance regressions in bugzilla because of cpu frequency being lower than before:

    https://bugzilla.kernel.org/show_bug.cgi?id=215045

He bisected the problem to:
commit 1c35b07e6d39 ("sched/fair: Ensure _sum and _avg values stay consistent")

This commit forces util_sum to be synced with the new util_avg after removing the contribution of a task and before the next periodic sync. By doing so util_sum is rounded to its lower bound and might lost up to LOAD_AVG_MAX-1 of accumulated contribution which has not yet been reflected in util_avg.

Instead of always setting util_sum to the low bound of util_avg, which can significantly lower the utilization of root cfs_rq after propagating the change down into the hierarchy, we revert the change of util_sum and propagate the difference.

In addition, we also check that cfs's util_sum always stays above the lower bound for a given util_avg as it has been observed that sched_entity's util_sum is sometimes above cfs one.

Fixes 1c35b07e6d39 ("sched/fair: Ensure _sum and _avg values stay consistent")

Reported-by Rick Yiu <[email protected]>

Signed-off-by Vincent Guittot <[email protected]>

Signed-off-by Peter Zijlstra (Intel) <[email protected]>

Reviewed-by Dietmar Eggemann <[email protected]>

Tested-by Sachin Sant <[email protected]>

Link https://lkml.kernel.org/r/[email protected] open here

Signed-off-by Sasha Levin <[email protected]>

---
 kernel/sched/fair.c | 16 +++++++++++++---
 kernel/sched/pelt.h |  4 +++-
 2 files changed, 16 insertions(+), 4 deletions(-)

kernel/sched/fair.c +13 -3

index d41f966f5866a..6420580f2730b 100644
@@ -3422,7 +3422,6 @@ void set_task_rq_fair(struct sched_entity *se,
 	se->avg.last_update_time = n_last_update_time;
 }
 
-
 /*
  * When on migration a sched_entity joins/leaves the PELT hierarchy, we need to
  * propagate its contribution. The key to this propagation is the invariant

@@ -3490,7 +3489,6 @@ void set_task_rq_fair(struct sched_entity *se,
  * XXX: only do this for the part of runnable > running ?
  *
  */
-
 static inline void
 update_tg_cfs_util(struct cfs_rq *cfs_rq, struct sched_entity *se, struct cfs_rq *gcfs_rq)
 {

@@ -3722,7 +3720,19 @@ update_cfs_rq_load_avg(u64 now, struct cfs_rq *cfs_rq)
 
 		r = removed_util;
 		sub_positive(&sa->util_avg, r);
-		sa->util_sum = sa->util_avg * divider;
+		sub_positive(&sa->util_sum, r * divider);
+		/*
+		 * Because of rounding, se->util_sum might ends up being +1 more than
+		 * cfs->util_sum. Although this is not a problem by itself, detaching
+		 * a lot of tasks with the rounding problem between 2 updates of
+		 * util_avg (~1ms) can make cfs->util_sum becoming null whereas
+		 * cfs_util_avg is not.
+		 * Check that util_sum is still above its lower bound for the new
+		 * util_avg. Given that period_contrib might have moved since the last
+		 * sync, we are only sure that util_sum must be above or equal to
+		 *    util_avg * minimum possible divider
+		 */
+		sa->util_sum = max_t(u32, sa->util_sum, sa->util_avg * PELT_MIN_DIVIDER);
 
 		r = removed_runnable;
 		sub_positive(&sa->runnable_avg, r);

kernel/sched/pelt.h +3 -1

index e06071bf3472c..c336f5f481bca 100644
@@ -37,9 +37,11 @@ update_irq_load_avg(struct rq *rq, u64 running)
 }
 #endif
 
+#define PELT_MIN_DIVIDER	(LOAD_AVG_MAX - 1024)
+
 static inline u32 get_pelt_divider(struct sched_avg *avg)
 {
-	return LOAD_AVG_MAX - 1024 + avg->period_contrib;
+	return PELT_MIN_DIVIDER + avg->period_contrib;
 }
 
 static inline void cfs_se_util_change(struct sched_avg *avg)

Signature · 1 line

2.34.1

Greg Kroah-Hartman

author maintainer

2022-01-31 11:14 UTC #110 lore raw

PATCH 110/171 net: phy: broadcom: hook up soft_reset for BCM54616S

From: Robert Hancock <[email protected]>

[ Upstream commit d15c7e875d44367005370e6a82e8f3a382a04f9b ]

A problem was encountered with the Bel-Fuse 1GBT-SFP05 SFP module (which is a 1 Gbps copper module operating in SGMII mode with an internal BCM54616S PHY device) using the Xilinx AXI Ethernet MAC core, where the module would work properly on the initial insertion or boot of the device, but after the device was rebooted, the link would either only come up at 100 Mbps speeds or go up and down erratically.

I found no meaningful changes in the PHY configuration registers between the working and non-working boots, but the status registers seemed to have a lot of error indications set on the SERDES side of the device on the non-working boot. I suspect the problem is that whatever happens on the SGMII link when the device is rebooted and the FPGA logic gets reloaded ends up putting the module's onboard PHY into a bad state.

Since commit 6e2d85ec0559 ("net: phy: Stop with excessive soft reset") the genphy_soft_reset call is not made automatically by the PHY core unless the callback is explicitly specified in the driver structure. For most of these Broadcom devices, there is probably a hardware reset that gets asserted to reset the PHY during boot, however for SFP modules (where the BCM54616S is commonly found) no such reset line exists, so if the board keeps the SFP cage powered up across a reboot, it will end up with no reset occurring during reboots.

Hook up the genphy_soft_reset callback for BCM54616S to ensure that a PHY reset is performed before the device is initialized. This appears to fix the issue with erratic operation after a reboot with this SFP module.

Fixes 6e2d85ec0559 ("net: phy: Stop with excessive soft reset")

Reviewed-by Florian Fainelli <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

---
 drivers/net/phy/broadcom.c | 1 +
 1 file changed, 1 insertion(+)

drivers/net/phy/broadcom.c +1 -0

index 83aea5c5cd03c..db26ff8ce7dbb 100644
@@ -768,6 +768,7 @@ static struct phy_driver broadcom_drivers[] = {
 	.phy_id_mask	= 0xfffffff0,
 	.name		= "Broadcom BCM54616S",
 	/* PHY_GBIT_FEATURES */
+	.soft_reset     = genphy_soft_reset,
 	.config_init	= bcm54xx_config_init,
 	.config_aneg	= bcm54616s_config_aneg,
 	.config_intr	= bcm_phy_config_intr,

Signature · 1 line

2.34.1

Greg Kroah-Hartman

author maintainer

2022-01-31 11:14 UTC #111 lore raw

PATCH 111/171 net: stmmac: dwmac-visconti: Fix bit definitions for ETHER_CLK_SEL

From: Yuji Ishikawa <[email protected]>

[ Upstream commit 1ba1a4a90fa416a6f389206416c5f488cf8b1543 ]

just 0 should be used to represent cleared bits

* ETHER_CLK_SEL_DIV_SEL_20
* ETHER_CLK_SEL_TX_CLK_EXT_SEL_IN
* ETHER_CLK_SEL_RX_CLK_EXT_SEL_IN
* ETHER_CLK_SEL_TX_CLK_O_TX_I
* ETHER_CLK_SEL_RMII_CLK_SEL_IN

Fixes b38dd98ff8d0 ("net: stmmac: Add Toshiba Visconti SoCs glue driver")

Signed-off-by Yuji Ishikawa <[email protected]>

Reviewed-by Nobuhiro Iwamatsu <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

---
 drivers/net/ethernet/stmicro/stmmac/dwmac-visconti.c | 10 +++++-----
 1 file changed, 5 insertions(+), 5 deletions(-)

drivers/net/ethernet/stmicro/stmmac/dwmac-visconti.c +5 -5

index fac788718c045..1c599a005aab6 100644
@@ -22,21 +22,21 @@
 #define ETHER_CLK_SEL_RMII_CLK_EN BIT(2)
 #define ETHER_CLK_SEL_RMII_CLK_RST BIT(3)
 #define ETHER_CLK_SEL_DIV_SEL_2 BIT(4)
-#define ETHER_CLK_SEL_DIV_SEL_20 BIT(0)
+#define ETHER_CLK_SEL_DIV_SEL_20 0
 #define ETHER_CLK_SEL_FREQ_SEL_125M	(BIT(9) | BIT(8))
 #define ETHER_CLK_SEL_FREQ_SEL_50M	BIT(9)
 #define ETHER_CLK_SEL_FREQ_SEL_25M	BIT(8)
 #define ETHER_CLK_SEL_FREQ_SEL_2P5M	0
-#define ETHER_CLK_SEL_TX_CLK_EXT_SEL_IN BIT(0)
+#define ETHER_CLK_SEL_TX_CLK_EXT_SEL_IN 0
 #define ETHER_CLK_SEL_TX_CLK_EXT_SEL_TXC BIT(10)
 #define ETHER_CLK_SEL_TX_CLK_EXT_SEL_DIV BIT(11)
-#define ETHER_CLK_SEL_RX_CLK_EXT_SEL_IN  BIT(0)
+#define ETHER_CLK_SEL_RX_CLK_EXT_SEL_IN  0
 #define ETHER_CLK_SEL_RX_CLK_EXT_SEL_RXC BIT(12)
 #define ETHER_CLK_SEL_RX_CLK_EXT_SEL_DIV BIT(13)
-#define ETHER_CLK_SEL_TX_CLK_O_TX_I	 BIT(0)
+#define ETHER_CLK_SEL_TX_CLK_O_TX_I	 0
 #define ETHER_CLK_SEL_TX_CLK_O_RMII_I	 BIT(14)
 #define ETHER_CLK_SEL_TX_O_E_N_IN	 BIT(15)
-#define ETHER_CLK_SEL_RMII_CLK_SEL_IN	 BIT(0)
+#define ETHER_CLK_SEL_RMII_CLK_SEL_IN	 0
 #define ETHER_CLK_SEL_RMII_CLK_SEL_RX_C	 BIT(16)
 
 #define ETHER_CLK_SEL_RX_TX_CLK_EN (ETHER_CLK_SEL_RX_CLK_EN | ETHER_CLK_SEL_TX_CLK_EN)

Signature · 1 line

2.34.1

Greg Kroah-Hartman

author maintainer

2022-01-31 11:14 UTC #112 lore raw

PATCH 112/171 net: stmmac: dwmac-visconti: Fix clock configuration for RMII mode

From: Yuji Ishikawa <[email protected]>

[ Upstream commit 0959bc4bd4206433ed101a1332a23e93ad16ec77 ]

Bit pattern of the ETHER_CLOCK_SEL register for RMII/MII mode should be fixed. Also, some control bits should be modified with a specific sequence.

Fixes b38dd98ff8d0 ("net: stmmac: Add Toshiba Visconti SoCs glue driver")

Signed-off-by Yuji Ishikawa <[email protected]>

Reviewed-by Nobuhiro Iwamatsu <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

---
 .../ethernet/stmicro/stmmac/dwmac-visconti.c  | 32 ++++++++++++-------
 1 file changed, 21 insertions(+), 11 deletions(-)

drivers/net/ethernet/stmicro/stmmac/dwmac-visconti.c +21 ~~-11~~

index 1c599a005aab6..4578c64953eac 100644
@@ -96,31 +96,41 @@ static void visconti_eth_fix_mac_speed(void *priv, unsigned int speed)
 	val |= ETHER_CLK_SEL_TX_O_E_N_IN;
 	writel(val, dwmac->reg + REG_ETHER_CLOCK_SEL);
 
+	/* Set Clock-Mux, Start clock, Set TX_O direction */
 	switch (dwmac->phy_intf_sel) {
 	case ETHER_CONFIG_INTF_RGMII:
 		val = clk_sel_val | ETHER_CLK_SEL_RX_CLK_EXT_SEL_RXC;
+		writel(val, dwmac->reg + REG_ETHER_CLOCK_SEL);
+
+		val |= ETHER_CLK_SEL_RX_TX_CLK_EN;
+		writel(val, dwmac->reg + REG_ETHER_CLOCK_SEL);
+
+		val &= ~ETHER_CLK_SEL_TX_O_E_N_IN;
+		writel(val, dwmac->reg + REG_ETHER_CLOCK_SEL);
 		break;
 	case ETHER_CONFIG_INTF_RMII:
 		val = clk_sel_val | ETHER_CLK_SEL_RX_CLK_EXT_SEL_DIV |
-			ETHER_CLK_SEL_TX_CLK_EXT_SEL_TXC | ETHER_CLK_SEL_TX_O_E_N_IN |
+			ETHER_CLK_SEL_TX_CLK_EXT_SEL_DIV | ETHER_CLK_SEL_TX_O_E_N_IN |
 			ETHER_CLK_SEL_RMII_CLK_SEL_RX_C;
+		writel(val, dwmac->reg + REG_ETHER_CLOCK_SEL);
+
+		val |= ETHER_CLK_SEL_RMII_CLK_RST;
+		writel(val, dwmac->reg + REG_ETHER_CLOCK_SEL);
+
+		val |= ETHER_CLK_SEL_RMII_CLK_EN | ETHER_CLK_SEL_RX_TX_CLK_EN;
+		writel(val, dwmac->reg + REG_ETHER_CLOCK_SEL);
 		break;
 	case ETHER_CONFIG_INTF_MII:
 	default:
 		val = clk_sel_val | ETHER_CLK_SEL_RX_CLK_EXT_SEL_RXC |
-			ETHER_CLK_SEL_TX_CLK_EXT_SEL_DIV | ETHER_CLK_SEL_TX_O_E_N_IN |
-			ETHER_CLK_SEL_RMII_CLK_EN;
+			ETHER_CLK_SEL_TX_CLK_EXT_SEL_TXC | ETHER_CLK_SEL_TX_O_E_N_IN;
+		writel(val, dwmac->reg + REG_ETHER_CLOCK_SEL);
+
+		val |= ETHER_CLK_SEL_RX_TX_CLK_EN;
+		writel(val, dwmac->reg + REG_ETHER_CLOCK_SEL);
 		break;
 	}
 
-	/* Start clock */
-	writel(val, dwmac->reg + REG_ETHER_CLOCK_SEL);
-	val |= ETHER_CLK_SEL_RX_TX_CLK_EN;
-	writel(val, dwmac->reg + REG_ETHER_CLOCK_SEL);
-
-	val &= ~ETHER_CLK_SEL_TX_O_E_N_IN;
-	writel(val, dwmac->reg + REG_ETHER_CLOCK_SEL);
-
 	spin_unlock_irqrestore(&dwmac->lock, flags);
 }

Signature · 1 line

2.34.1

Greg Kroah-Hartman

author maintainer

2022-01-31 11:21 UTC #113 lore raw

PATCH 113/171 phylib: fix potential use-after-free

From: Marek Behún <[email protected]>

[ Upstream commit cbda1b16687580d5beee38273f6241ae3725960c ]

Commit bafbdd527d56 ("phylib: Add device reset GPIO support") added call to phy_device_reset(phydev) after the put_device() call in phy_detach().

The comment before the put_device() call says that the phydev might go away with put_device().

Fix potential use-after-free by calling phy_device_reset() before put_device().

Fixes bafbdd527d56 ("phylib: Add device reset GPIO support")

Signed-off-by Marek Behún <[email protected]>

Reviewed-by Andrew Lunn <[email protected]>

Link https://lore.kernel.org/r/[email protected] open here

Signed-off-by Sasha Levin <[email protected]>

---
 drivers/net/phy/phy_device.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

drivers/net/phy/phy_device.c +3 -3

index 4f9990b47a377..28f4a383aba72 100644
@@ -1746,6 +1746,9 @@ void phy_detach(struct phy_device *phydev)
 	    phy_driver_is_genphy_10g(phydev))
 		device_release_driver(&phydev->mdio.dev);
 
+	/* Assert the reset signal */
+	phy_device_reset(phydev, 1);
+
 	/*
 	 * The phydev might go away on the put_device() below, so avoid
 	 * a use-after-free bug by reading the underlying bus first.

@@ -1757,9 +1760,6 @@ void phy_detach(struct phy_device *phydev)
 		ndev_owner = dev->dev.parent->driver->owner;
 	if (ndev_owner != bus->owner)
 		module_put(bus->owner);
-
-	/* Assert the reset signal */
-	phy_device_reset(phydev, 1);
 }
 EXPORT_SYMBOL(phy_detach);

Signature · 1 line

2.34.1

Greg Kroah-Hartman

author maintainer

2022-01-31 11:14 UTC #114 lore raw

PATCH 114/171 mptcp: allow changing the "backup" bit by endpoint id

Link https://github.com/multipath-tcp/mptcp_net-next/issues/158

From: Davide Caratti <[email protected]>

[ Upstream commit 602837e8479d20d49559b4b97b79d34c0efe7ecb ]

a non-zero 'id' is sufficient to identify MPTCP endpoints: allow changing the value of 'backup' bit by simply specifying the endpoint id.

Signed-off-by Davide Caratti <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

---
 net/mptcp/pm_netlink.c | 14 ++++++++++----
 1 file changed, 10 insertions(+), 4 deletions(-)

net/mptcp/pm_netlink.c +10 -4

index d96860053816a..3be10bf22cf7c 100644
@@ -1711,22 +1711,28 @@ next:
 
 static int mptcp_nl_cmd_set_flags(struct sk_buff *skb, struct genl_info *info)
 {
+	struct mptcp_pm_addr_entry addr = { .addr = { .family = AF_UNSPEC }, }, *entry;
 	struct nlattr *attr = info->attrs[MPTCP_PM_ATTR_ADDR];
 	struct pm_nl_pernet *pernet = genl_info_pm_nl(info);
-	struct mptcp_pm_addr_entry addr, *entry;
 	struct net *net = sock_net(skb->sk);
-	u8 bkup = 0;
+	u8 bkup = 0, lookup_by_id = 0;
 	int ret;
 
-	ret = mptcp_pm_parse_addr(attr, info, true, &addr);
+	ret = mptcp_pm_parse_addr(attr, info, false, &addr);
 	if (ret < 0)
 		return ret;
 
 	if (addr.flags & MPTCP_PM_ADDR_FLAG_BACKUP)
 		bkup = 1;
+	if (addr.addr.family == AF_UNSPEC) {
+		lookup_by_id = 1;
+		if (!addr.addr.id)
+			return -EOPNOTSUPP;
+	}
 
 	list_for_each_entry(entry, &pernet->local_addr_list, list) {
-		if (addresses_equal(&entry->addr, &addr.addr, true)) {
+		if ((!lookup_by_id && addresses_equal(&entry->addr, &addr.addr, true)) ||
+		    (lookup_by_id && entry->addr.id == addr.addr.id)) {
 			mptcp_nl_addr_backup(net, &entry->addr, bkup);
 
 			if (bkup)

Signature · 1 line

2.34.1

Greg Kroah-Hartman

author maintainer

2022-01-31 11:14 UTC #115 lore raw

PATCH 115/171 mptcp: clean up harmless false expressions

From: Jean Sacren <[email protected]>

[ Upstream commit 59060a47ca50bbdb1d863b73667a1065873ecc06 ]

entry->addr.id is u8 with a range from 0 to 255 and MAX_ADDR_ID is 255. We should drop both false expressions of (entry->addr.id > MAX_ADDR_ID).

We should also remove the obsolete parentheses in the first if branch.

Use U8_MAX for MAX_ADDR_ID and add a comment to show the link to mptcp_addr_info.id as suggested by Mr. Matthieu Baerts.

Reviewed-by Matthieu Baerts <[email protected]>

Signed-off-by Jean Sacren <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

---
 net/mptcp/pm_netlink.c | 8 ++++----
 1 file changed, 4 insertions(+), 4 deletions(-)

net/mptcp/pm_netlink.c +4 -4

index 3be10bf22cf7c..15c89d4fea4d2 100644
@@ -38,7 +38,8 @@ struct mptcp_pm_add_entry {
 	u8			retrans_times;
 };
 
-#define MAX_ADDR_ID		255
+/* max value of mptcp_addr_info.id */
+#define MAX_ADDR_ID		U8_MAX
 #define BITMAP_SZ DIV_ROUND_UP(MAX_ADDR_ID + 1, BITS_PER_LONG)
 
 struct pm_nl_pernet {

@@ -831,14 +832,13 @@ find_next:
 		entry->addr.id = find_next_zero_bit(pernet->id_bitmap,
 						    MAX_ADDR_ID + 1,
 						    pernet->next_id);
-		if ((!entry->addr.id || entry->addr.id > MAX_ADDR_ID) &&
-		    pernet->next_id != 1) {
+		if (!entry->addr.id && pernet->next_id != 1) {
 			pernet->next_id = 1;
 			goto find_next;
 		}
 	}
 
-	if (!entry->addr.id || entry->addr.id > MAX_ADDR_ID)
+	if (!entry->addr.id)
 		goto out;
 
 	__set_bit(entry->addr.id, pernet->id_bitmap);

Signature · 1 line

2.34.1

Greg Kroah-Hartman

author maintainer

2022-01-31 11:14 UTC #116 lore raw

PATCH 116/171 mptcp: keep track of local endpoint still available for each msk

From: Paolo Abeni <[email protected]>

[ Upstream commit 86e39e04482b0aadf3ee3ed5fcf2d63816559d36 ]

Include into the path manager status a bitmap tracking the list of local endpoints still available - not yet used - for the relevant mptcp socket.

Keep such map updated at endpoint creation/deletion time, so that we can easily skip already used endpoint at local address selection time.

The endpoint used by the initial subflow is lazyly accounted at subflow creation time: the usage bitmap is be up2date before endpoint selection and we avoid such unneeded task in some relevant scenarios - e.g. busy servers accepting incoming subflows but not creating any additional ones nor annuncing additional addresses.

Overall this allows for fair local endpoints usage in case of subflow failure.

As a side effect, this patch also enforces that each endpoint is used at most once for each mptcp connection.

Signed-off-by Paolo Abeni <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

---
 net/mptcp/pm.c                                |   1 +
 net/mptcp/pm_netlink.c                        | 125 +++++++++++-------
 net/mptcp/protocol.c                          |   3 +-
 net/mptcp/protocol.h                          |  12 +-
 .../testing/selftests/net/mptcp/mptcp_join.sh |   5 +-
 5 files changed, 91 insertions(+), 55 deletions(-)

net/mptcp/pm.c +1 -0

index 6ab386ff32944..332ac6eda3ba4 100644
@@ -370,6 +370,7 @@ void mptcp_pm_data_init(struct mptcp_sock *msk)
 	WRITE_ONCE(msk->pm.accept_subflow, false);
 	WRITE_ONCE(msk->pm.remote_deny_join_id0, false);
 	msk->pm.status = 0;
+	bitmap_fill(msk->pm.id_avail_bitmap, MPTCP_PM_MAX_ADDR_ID + 1);
 
 	spin_lock_init(&msk->pm.lock);
 	INIT_LIST_HEAD(&msk->pm.anno_list);

net/mptcp/pm_netlink.c +74 ~~-51~~

258 lines not on this page · raw message

net/mptcp/protocol.c +1 -2

index 4c889552cde77..354f169ca120a 100644
@@ -2435,8 +2435,7 @@ static void mptcp_worker(struct work_struct *work)
 
 	mptcp_check_fastclose(msk);
 
-	if (msk->pm.status)
-		mptcp_pm_nl_work(msk);
+	mptcp_pm_nl_work(msk);
 
 	if (test_and_clear_bit(MPTCP_WORK_EOF, &msk->flags))
 		mptcp_check_for_eof(msk);

net/mptcp/protocol.h +11 -1

index 82c5dc4d6b49d..9fc6f494075fa 100644
@@ -174,16 +174,25 @@ enum mptcp_pm_status {
 	MPTCP_PM_ADD_ADDR_SEND_ACK,
 	MPTCP_PM_RM_ADDR_RECEIVED,
 	MPTCP_PM_ESTABLISHED,
-	MPTCP_PM_ALREADY_ESTABLISHED,	/* persistent status, set after ESTABLISHED event */
 	MPTCP_PM_SUBFLOW_ESTABLISHED,
+	MPTCP_PM_ALREADY_ESTABLISHED,	/* persistent status, set after ESTABLISHED event */
+	MPTCP_PM_MPC_ENDPOINT_ACCOUNTED /* persistent status, set after MPC local address is
+					 * accounted int id_avail_bitmap
+					 */
 };
 
+/* Status bits below MPTCP_PM_ALREADY_ESTABLISHED need pm worker actions */
+#define MPTCP_PM_WORK_MASK ((1 << MPTCP_PM_ALREADY_ESTABLISHED) - 1)
+
 enum mptcp_addr_signal_status {
 	MPTCP_ADD_ADDR_SIGNAL,
 	MPTCP_ADD_ADDR_ECHO,
 	MPTCP_RM_ADDR_SIGNAL,
 };
 
+/* max value of mptcp_addr_info.id */
+#define MPTCP_PM_MAX_ADDR_ID		U8_MAX
+
 struct mptcp_pm_data {
 	struct mptcp_addr_info local;
 	struct mptcp_addr_info remote;

@@ -202,6 +211,7 @@ struct mptcp_pm_data {
 	u8		local_addr_used;
 	u8		subflows;
 	u8		status;
+	DECLARE_BITMAP(id_avail_bitmap, MPTCP_PM_MAX_ADDR_ID + 1);
 	struct mptcp_rm_list rm_list_tx;
 	struct mptcp_rm_list rm_list_rx;
 };

tools/testing/selftests/net/mptcp/mptcp_join.sh +4 -1

index 586af88194e56..0c12602fa22e8 100755
@@ -1068,7 +1068,10 @@ signal_address_tests()
 	ip netns exec $ns2 ./pm_nl_ctl add 10.0.3.2 flags signal
 	ip netns exec $ns2 ./pm_nl_ctl add 10.0.4.2 flags signal
 	run_tests $ns1 $ns2 10.0.1.1
-	chk_add_nr 4 4
+
+	# the server will not signal the address terminating
+	# the MPC subflow
+	chk_add_nr 3 3
 }
 
 link_failure_tests()

Signature · 1 line

2.34.1

Greg Kroah-Hartman

author maintainer

2022-01-31 11:21 UTC #117 lore raw

PATCH 117/171 mptcp: fix msk traversal in mptcp_nl_cmd_set_flags()

From: Paolo Abeni <[email protected]>

[ Upstream commit 8e9eacad7ec7a9cbf262649ebf1fa6e6f6cc7d82 ]

The MPTCP endpoint list is under RCU protection, guarded by the pernet spinlock. mptcp_nl_cmd_set_flags() traverses the list without acquiring the spin-lock nor under the RCU critical section.

This change addresses the issue performing the lookup and the endpoint update under the pernet spinlock.

Fixes 0f9f696a502e ("mptcp: add set_flags command in PM netlink")

Signed-off-by Paolo Abeni <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

---
 net/mptcp/pm_netlink.c | 37 +++++++++++++++++++++++++++----------
 1 file changed, 27 insertions(+), 10 deletions(-)

net/mptcp/pm_netlink.c +27 ~~-10~~

index bba166ddacc78..7f11eb3e35137 100644
@@ -469,6 +469,20 @@ __lookup_addr_by_id(struct pm_nl_pernet *pernet, unsigned int id)
 	return NULL;
 }
 
+static struct mptcp_pm_addr_entry *
+__lookup_addr(struct pm_nl_pernet *pernet, const struct mptcp_addr_info *info,
+	      bool lookup_by_id)
+{
+	struct mptcp_pm_addr_entry *entry;
+
+	list_for_each_entry(entry, &pernet->local_addr_list, list) {
+		if ((!lookup_by_id && addresses_equal(&entry->addr, info, true)) ||
+		    (lookup_by_id && entry->addr.id == info->id))
+			return entry;
+	}
+	return NULL;
+}
+
 static int
 lookup_id_by_addr(struct pm_nl_pernet *pernet, const struct mptcp_addr_info *addr)
 {

@@ -1753,18 +1767,21 @@ static int mptcp_nl_cmd_set_flags(struct sk_buff *skb, struct genl_info *info)
 			return -EOPNOTSUPP;
 	}
 
-	list_for_each_entry(entry, &pernet->local_addr_list, list) {
-		if ((!lookup_by_id && addresses_equal(&entry->addr, &addr.addr, true)) ||
-		    (lookup_by_id && entry->addr.id == addr.addr.id)) {
-			mptcp_nl_addr_backup(net, &entry->addr, bkup);
-
-			if (bkup)
-				entry->flags |= MPTCP_PM_ADDR_FLAG_BACKUP;
-			else
-				entry->flags &= ~MPTCP_PM_ADDR_FLAG_BACKUP;
-		}
+	spin_lock_bh(&pernet->lock);
+	entry = __lookup_addr(pernet, &addr.addr, lookup_by_id);
+	if (!entry) {
+		spin_unlock_bh(&pernet->lock);
+		return -EINVAL;
 	}
 
+	if (bkup)
+		entry->flags |= MPTCP_PM_ADDR_FLAG_BACKUP;
+	else
+		entry->flags &= ~MPTCP_PM_ADDR_FLAG_BACKUP;
+	addr = *entry;
+	spin_unlock_bh(&pernet->lock);
+
+	mptcp_nl_addr_backup(net, &addr.addr, bkup);
 	return 0;
 }

Signature · 1 line

2.34.1

Greg Kroah-Hartman

author maintainer

2022-01-31 11:14 UTC #118 lore raw

PATCH 118/171 mptcp: fix removing ids bitmap setting

From: Geliang Tang <[email protected]>

[ Upstream commit a4c0214fbee97c46e3f41fee37931d66c0fc3cb1 ]

In mptcp_pm_nl_rm_addr_or_subflow(), the bit of rm_list->ids[i] in the id_avail_bitmap should be set, not rm_list->ids[1]. This patch fixed it.

Fixes 86e39e04482b ("mptcp: keep track of local endpoint still available for each msk")

Acked-by Paolo Abeni <[email protected]>

Signed-off-by Geliang Tang <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

---
 net/mptcp/pm_netlink.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

net/mptcp/pm_netlink.c +1 -1

index 7f11eb3e35137..84e6b55375e1d 100644
@@ -781,7 +781,7 @@ static void mptcp_pm_nl_rm_addr_or_subflow(struct mptcp_sock *msk,
 			msk->pm.subflows--;
 			__MPTCP_INC_STATS(sock_net(sk), rm_type);
 		}
-		__set_bit(rm_list->ids[1], msk->pm.id_avail_bitmap);
+		__set_bit(rm_list->ids[i], msk->pm.id_avail_bitmap);
 		if (!removed)
 			continue;

Signature · 1 line

2.34.1

Greg Kroah-Hartman

author maintainer

2022-01-31 11:21 UTC #119 lore raw

PATCH 119/171 selftests: mptcp: fix ipv6 routing setup

From: Paolo Abeni <[email protected]>

[ Upstream commit 9846921dba4936d92f7608315b5d1e0a8ec3a538 ]

MPJ ipv6 selftests currently lack per link route to the server net. Additionally, ipv6 subflows endpoints are created without any interface specified. The end-result is that in ipv6 self-tests subflows are created all on the same link, leading to expected delays and sporadic self-tests failures.

Fix the issue by adding the missing setup bits.

Fixes 523514ed0a99 ("selftests: mptcp: add ADD_ADDR IPv6 test cases")

Reported-and-tested-by Geliang Tang <[email protected]>

Signed-off-by Paolo Abeni <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

---
 tools/testing/selftests/net/mptcp/mptcp_join.sh | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

tools/testing/selftests/net/mptcp/mptcp_join.sh +3 -2

index 0c12602fa22e8..38777d1ef766f 100755
@@ -75,6 +75,7 @@ init()
 
 		# let $ns2 reach any $ns1 address from any interface
 		ip -net "$ns2" route add default via 10.0.$i.1 dev ns2eth$i metric 10$i
+		ip -net "$ns2" route add default via dead:beef:$i::1 dev ns2eth$i metric 10$i
 	done
 }

@@ -1386,7 +1387,7 @@ ipv6_tests()
 	reset
 	ip netns exec $ns1 ./pm_nl_ctl limits 0 1
 	ip netns exec $ns2 ./pm_nl_ctl limits 0 1
-	ip netns exec $ns2 ./pm_nl_ctl add dead:beef:3::2 flags subflow
+	ip netns exec $ns2 ./pm_nl_ctl add dead:beef:3::2 dev ns2eth3 flags subflow
 	run_tests $ns1 $ns2 dead:beef:1::1 0 0 0 slow
 	chk_join_nr "single subflow IPv6" 1 1 1

@@ -1421,7 +1422,7 @@ ipv6_tests()
 	ip netns exec $ns1 ./pm_nl_ctl limits 0 2
 	ip netns exec $ns1 ./pm_nl_ctl add dead:beef:2::1 flags signal
 	ip netns exec $ns2 ./pm_nl_ctl limits 1 2
-	ip netns exec $ns2 ./pm_nl_ctl add dead:beef:3::2 flags subflow
+	ip netns exec $ns2 ./pm_nl_ctl add dead:beef:3::2 dev ns2eth3 flags subflow
 	run_tests $ns1 $ns2 dead:beef:1::1 0 -1 -1 slow
 	chk_join_nr "remove subflow and signal IPv6" 2 2 2
 	chk_add_nr 1 1

Signature · 1 line

2.34.1

Greg Kroah-Hartman

author maintainer

2022-01-31 11:21 UTC #120 lore raw

PATCH 120/171 octeontx2-af: Do not fixup all VF action entries

From: Subbaraya Sundeep <[email protected]>

[ Upstream commit d225c449ab2be25273a3674f476c6c0b57c50254 ]

AF modifies all the rules destined for VF to use the action same as default RSS action. This fixup was needed because AF only installs default rules with RSS action. But the action in rules installed by a PF for its VFs should not be changed by this fixup. This is because action can be drop or direct to queue as specified by user(ntuple filters). This patch fixes that problem.

Fixes 967db3529eca ("octeontx2-af: add support for multicast/promisc packet")

Signed-off-by Subbaraya Sundeep <[email protected]>

Signed-off-by Naveen Mamindlapalli <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

---
 .../ethernet/marvell/octeontx2/af/rvu_npc.c   | 22 ++++++++++++++++---
 .../marvell/octeontx2/af/rvu_npc_fs.c         | 20 ++++++++++-------
 2 files changed, 31 insertions(+), 11 deletions(-)

drivers/net/ethernet/marvell/octeontx2/af/rvu_npc.c +19 -3

index 5efb4174e82df..87f18e32b4634 100644
@@ -402,6 +402,7 @@ static void npc_fixup_vf_rule(struct rvu *rvu, struct npc_mcam *mcam,
 			      int blkaddr, int index, struct mcam_entry *entry,
 			      bool *enable)
 {
+	struct rvu_npc_mcam_rule *rule;
 	u16 owner, target_func;
 	struct rvu_pfvf *pfvf;
 	u64 rx_action;

@@ -423,6 +424,12 @@ static void npc_fixup_vf_rule(struct rvu *rvu, struct npc_mcam *mcam,
 	      test_bit(NIXLF_INITIALIZED, &pfvf->flags)))
 		*enable = false;
 
+	/* fix up not needed for the rules added by user(ntuple filters) */
+	list_for_each_entry(rule, &mcam->mcam_rules, list) {
+		if (rule->entry == index)
+			return;
+	}
+
 	/* copy VF default entry action to the VF mcam entry */
 	rx_action = npc_get_default_entry_action(rvu, mcam, blkaddr,
 						 target_func);

@@ -489,8 +496,8 @@ static void npc_config_mcam_entry(struct rvu *rvu, struct npc_mcam *mcam,
 	}
 
 	/* PF installing VF rule */
-	if (intf == NIX_INTF_RX && actindex < mcam->bmap_entries)
-		npc_fixup_vf_rule(rvu, mcam, blkaddr, index, entry, &enable);
+	if (is_npc_intf_rx(intf) && actindex < mcam->bmap_entries)
+		npc_fixup_vf_rule(rvu, mcam, blkaddr, actindex, entry, &enable);
 
 	/* Set 'action' */
 	rvu_write64(rvu, blkaddr,

@@ -916,7 +923,8 @@ static void npc_update_vf_flow_entry(struct rvu *rvu, struct npc_mcam *mcam,
 				     int blkaddr, u16 pcifunc, u64 rx_action)
 {
 	int actindex, index, bank, entry;
-	bool enable;
+	struct rvu_npc_mcam_rule *rule;
+	bool enable, update;
 
 	if (!(pcifunc & RVU_PFVF_FUNC_MASK))
 		return;

@@ -924,6 +932,14 @@ static void npc_update_vf_flow_entry(struct rvu *rvu, struct npc_mcam *mcam,
 	mutex_lock(&mcam->lock);
 	for (index = 0; index < mcam->bmap_entries; index++) {
 		if (mcam->entry2target_pffunc[index] == pcifunc) {
+			update = true;
+			/* update not needed for the rules added via ntuple filters */
+			list_for_each_entry(rule, &mcam->mcam_rules, list) {
+				if (rule->entry == index)
+					update = false;
+			}
+			if (!update)
+				continue;
 			bank = npc_get_bank(mcam, index);
 			actindex = index;
 			entry = index & (mcam->banksize - 1);

drivers/net/ethernet/marvell/octeontx2/af/rvu_npc_fs.c +12 -8

index 51ddc7b81d0bd..ca404d51d9f56 100644
@@ -1098,14 +1098,6 @@ find_rule:
 		write_req.cntr = rule->cntr;
 	}
 
-	err = rvu_mbox_handler_npc_mcam_write_entry(rvu, &write_req,
-						    &write_rsp);
-	if (err) {
-		rvu_mcam_remove_counter_from_rule(rvu, owner, rule);
-		if (new)
-			kfree(rule);
-		return err;
-	}
 	/* update rule */
 	memcpy(&rule->packet, &dummy.packet, sizeof(rule->packet));
 	memcpy(&rule->mask, &dummy.mask, sizeof(rule->mask));

@@ -1129,6 +1121,18 @@ find_rule:
 	if (req->default_rule)
 		pfvf->def_ucast_rule = rule;
 
+	/* write to mcam entry registers */
+	err = rvu_mbox_handler_npc_mcam_write_entry(rvu, &write_req,
+						    &write_rsp);
+	if (err) {
+		rvu_mcam_remove_counter_from_rule(rvu, owner, rule);
+		if (new) {
+			list_del(&rule->list);
+			kfree(rule);
+		}
+		return err;
+	}
+
 	/* VF's MAC address is being changed via PF  */
 	if (pf_set_vfs_mac) {
 		ether_addr_copy(pfvf->default_mac, req->packet.dmac);

Signature · 1 line

2.34.1

Greg Kroah-Hartman

author maintainer

2022-01-31 11:14 UTC #121 lore raw

PATCH 121/171 octeontx2-af: Fix LBK backpressure id count

From: Sunil Goutham <[email protected]>

[ Upstream commit 00bfe94e388fe12bfd0d4f6361b1b1343374ff5b ]

In rvu_nix_get_bpid() lbk_bpid_cnt is being read from wrong register. Due to this backpressure enable is failing for LBK VF32 onwards. This patch fixes that.

Fixes fe1939bb2340 ("octeontx2-af: Add SDP interface support")

Signed-off-by Subbaraya Sundeep <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

---
 drivers/net/ethernet/marvell/octeontx2/af/rvu_nix.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

drivers/net/ethernet/marvell/octeontx2/af/rvu_nix.c +3 -3

index 6970540dc4709..8ee324aabf2d6 100644
@@ -511,11 +511,11 @@ static int rvu_nix_get_bpid(struct rvu *rvu, struct nix_bp_cfg_req *req,
 	cfg = rvu_read64(rvu, blkaddr, NIX_AF_CONST);
 	lmac_chan_cnt = cfg & 0xFF;
 
-	cfg = rvu_read64(rvu, blkaddr, NIX_AF_CONST1);
-	sdp_chan_cnt = cfg & 0xFFF;
-
 	cgx_bpid_cnt = hw->cgx_links * lmac_chan_cnt;
 	lbk_bpid_cnt = hw->lbk_links * ((cfg >> 16) & 0xFF);
+
+	cfg = rvu_read64(rvu, blkaddr, NIX_AF_CONST1);
+	sdp_chan_cnt = cfg & 0xFFF;
 	sdp_bpid_cnt = hw->sdp_links * sdp_chan_cnt;
 
 	pfvf = rvu_get_pfvf(rvu, req->hdr.pcifunc);

Signature · 1 line

2.34.1

Greg Kroah-Hartman

author maintainer

2022-01-31 11:22 UTC #122 lore raw

PATCH 122/171 octeontx2-af: Retry until RVU block reset complete

From: Geetha sowjanya <[email protected]>

[ Upstream commit 03ffbc9914bd1130fba464f0a41c01372e5fc359 ]

Few RVU blocks like SSO require more time for reset on some silicons. Hence retrying the block reset until success.

Fixes c0fa2cff8822c ("octeontx2-af: Handle return value in block reset")

Signed-off-by Subbaraya Sundeep <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

---
 drivers/net/ethernet/marvell/octeontx2/af/rvu.c | 7 +++++--
 1 file changed, 5 insertions(+), 2 deletions(-)

drivers/net/ethernet/marvell/octeontx2/af/rvu.c +5 -2

index 90dc5343827f0..11ef46e72ddd9 100644
@@ -520,8 +520,11 @@ static void rvu_block_reset(struct rvu *rvu, int blkaddr, u64 rst_reg)
 
 	rvu_write64(rvu, blkaddr, rst_reg, BIT_ULL(0));
 	err = rvu_poll_reg(rvu, blkaddr, rst_reg, BIT_ULL(63), true);
-	if (err)
-		dev_err(rvu->dev, "HW block:%d reset failed\n", blkaddr);
+	if (err) {
+		dev_err(rvu->dev, "HW block:%d reset timeout retrying again\n", blkaddr);
+		while (rvu_poll_reg(rvu, blkaddr, rst_reg, BIT_ULL(63), true) == -EBUSY)
+			;
+	}
 }
 
 static void rvu_reset_all_blocks(struct rvu *rvu)

Signature · 1 line

2.34.1

Greg Kroah-Hartman

author maintainer

2022-01-31 11:22 UTC #123 lore raw

PATCH 123/171 octeontx2-pf: cn10k: Ensure valid pointers are freed to aura

From: Geetha sowjanya <[email protected]>

[ Upstream commit c5d731c54a17677939bd59ee8be4ed74d7485ba4 ]

While freeing SQB pointers to aura, driver first memcpy to target address and then triggers lmtst operation to free pointer to the aura. We need to ensure(by adding dmb barrier)that memcpy is finished before pointers are freed to the aura. This patch also adds the missing sq context structure entry in debugfs.

Fixes ef6c8da71eaf ("octeontx2-pf: cn10K: Reserve LMTST lines per core")

Signed-off-by Subbaraya Sundeep <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

---
 drivers/net/ethernet/marvell/octeontx2/af/rvu_debugfs.c  | 2 ++
 drivers/net/ethernet/marvell/octeontx2/nic/otx2_common.h | 1 +
 2 files changed, 3 insertions(+)

drivers/net/ethernet/marvell/octeontx2/af/rvu_debugfs.c +2 -0

index 49d822a98adab..f001579569a2b 100644
@@ -1131,6 +1131,8 @@ static void print_nix_cn10k_sq_ctx(struct seq_file *m,
 	seq_printf(m, "W3: head_offset\t\t\t%d\nW3: smenq_next_sqb_vld\t\t%d\n\n",
 		   sq_ctx->head_offset, sq_ctx->smenq_next_sqb_vld);
 
+	seq_printf(m, "W3: smq_next_sq_vld\t\t%d\nW3: smq_pend\t\t\t%d\n",
+		   sq_ctx->smq_next_sq_vld, sq_ctx->smq_pend);
 	seq_printf(m, "W4: next_sqb \t\t\t%llx\n\n", sq_ctx->next_sqb);
 	seq_printf(m, "W5: tail_sqb \t\t\t%llx\n\n", sq_ctx->tail_sqb);
 	seq_printf(m, "W6: smenq_sqb \t\t\t%llx\n\n", sq_ctx->smenq_sqb);

drivers/net/ethernet/marvell/octeontx2/nic/otx2_common.h +1 -0

index a51ecd771d075..637450de189c8 100644
@@ -591,6 +591,7 @@ static inline void __cn10k_aura_freeptr(struct otx2_nic *pfvf, u64 aura,
 			size++;
 		tar_addr |=  ((size - 1) & 0x7) << 4;
 	}
+	dma_wmb();
 	memcpy((u64 *)lmt_info->lmt_addr, ptrs, sizeof(u64) * num_ptrs);
 	/* Perform LMTST flush */
 	cn10k_lmt_flush(val, tar_addr);

Signature · 1 line

2.34.1

Greg Kroah-Hartman

author maintainer

2022-01-31 11:22 UTC #124 lore raw

PATCH 124/171 octeontx2-af: verify CQ context updates

From: Hariprasad Kelam <[email protected]>

[ Upstream commit 14e94f9445a9e91d460f5d4b519f8892c3fb14bb ]

As per HW errata AQ modification to CQ could be discarded on heavy traffic. This patch implements workaround for the same after each CQ write by AQ check whether the requested fields (except those which HW can update eg: avg_level) are properly updated or not.

If CQ context is not updated then perform AQ write again.

Signed-off-by Hariprasad Kelam <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

---
 .../net/ethernet/marvell/octeontx2/af/mbox.h  |  2 +
 .../ethernet/marvell/octeontx2/af/rvu_nix.c   | 78 ++++++++++++++++++-
 2 files changed, 79 insertions(+), 1 deletion(-)

drivers/net/ethernet/marvell/octeontx2/af/mbox.h +2 -0

index 154877706a0e1..a8618259de943 100644
@@ -698,6 +698,8 @@ enum nix_af_status {
 	NIX_AF_ERR_INVALID_BANDPROF = -426,
 	NIX_AF_ERR_IPOLICER_NOTSUPP = -427,
 	NIX_AF_ERR_BANDPROF_INVAL_REQ  = -428,
+	NIX_AF_ERR_CQ_CTX_WRITE_ERR  = -429,
+	NIX_AF_ERR_AQ_CTX_RETRY_WRITE  = -430,
 };
 
 /* For NIX RX vtag action  */

drivers/net/ethernet/marvell/octeontx2/af/rvu_nix.c +77 -1

100 lines not on this page · raw message

Signature · 1 line

2.34.1

Greg Kroah-Hartman

author maintainer

2022-01-31 11:22 UTC #125 lore raw

PATCH 125/171 octeontx2-af: Increase link credit restore polling timeout

From: Geetha sowjanya <[email protected]>

[ Upstream commit 1581d61b42d985cefe7b71eea67ab3bfcbf34d0f ]

It's been observed that sometimes link credit restore takes a lot of time than the current timeout. This patch increases the default timeout value and return the proper error value on failure.

Fixes 1c74b89171c3 ("octeontx2-af: Wait for TX link idle for credits change")

Signed-off-by Subbaraya Sundeep <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

---
 drivers/net/ethernet/marvell/octeontx2/af/mbox.h    | 1 +
 drivers/net/ethernet/marvell/octeontx2/af/rvu_nix.c | 4 ++--
 2 files changed, 3 insertions(+), 2 deletions(-)

drivers/net/ethernet/marvell/octeontx2/af/mbox.h +1 -0

index a8618259de943..26ad71842b3b2 100644
@@ -700,6 +700,7 @@ enum nix_af_status {
 	NIX_AF_ERR_BANDPROF_INVAL_REQ  = -428,
 	NIX_AF_ERR_CQ_CTX_WRITE_ERR  = -429,
 	NIX_AF_ERR_AQ_CTX_RETRY_WRITE  = -430,
+	NIX_AF_ERR_LINK_CREDITS  = -431,
 };
 
 /* For NIX RX vtag action  */

drivers/net/ethernet/marvell/octeontx2/af/rvu_nix.c +2 -2

index 9d4cc0ae61474..959266894cf15 100644
@@ -3891,8 +3891,8 @@ nix_config_link_credits(struct rvu *rvu, int blkaddr, int link,
 			    NIX_AF_TL1X_SW_XOFF(schq), BIT_ULL(0));
 	}
 
-	rc = -EBUSY;
-	poll_tmo = jiffies + usecs_to_jiffies(10000);
+	rc = NIX_AF_ERR_LINK_CREDITS;
+	poll_tmo = jiffies + usecs_to_jiffies(200000);
 	/* Wait for credits to return */
 	do {
 		if (time_after(jiffies, poll_tmo))

Signature · 1 line

2.34.1

Greg Kroah-Hartman

author maintainer

2022-01-31 11:22 UTC #126 lore raw

PATCH 126/171 octeontx2-af: cn10k: Do not enable RPM loopback for LPC interfaces

From: Geetha sowjanya <[email protected]>

[ Upstream commit df66b6ebc5dcf7253e35a640b9ec4add54195c25 ]

Internal looback is not supported to low rate LPCS interface like SGMII/QSGMII. Hence don't allow to enable for such interfaces.

Fixes 3ad3f8f93c81 ("octeontx2-af: cn10k: MAC internal loopback support")

Signed-off-by Subbaraya Sundeep <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

---
 .../net/ethernet/marvell/octeontx2/af/rpm.c   | 27 +++++++++----------
 1 file changed, 12 insertions(+), 15 deletions(-)

drivers/net/ethernet/marvell/octeontx2/af/rpm.c +12 ~~-15~~

index 07b0eafccad87..b3803577324e6 100644
@@ -251,22 +251,19 @@ int rpm_lmac_internal_loopback(void *rpmd, int lmac_id, bool enable)
 	if (!rpm || lmac_id >= rpm->lmac_count)
 		return -ENODEV;
 	lmac_type = rpm->mac_ops->get_lmac_type(rpm, lmac_id);
-	if (lmac_type == LMAC_MODE_100G_R) {
-		cfg = rpm_read(rpm, lmac_id, RPMX_MTI_PCS100X_CONTROL1);
-
-		if (enable)
-			cfg |= RPMX_MTI_PCS_LBK;
-		else
-			cfg &= ~RPMX_MTI_PCS_LBK;
-		rpm_write(rpm, lmac_id, RPMX_MTI_PCS100X_CONTROL1, cfg);
-	} else {
-		cfg = rpm_read(rpm, lmac_id, RPMX_MTI_LPCSX_CONTROL1);
-		if (enable)
-			cfg |= RPMX_MTI_PCS_LBK;
-		else
-			cfg &= ~RPMX_MTI_PCS_LBK;
-		rpm_write(rpm, lmac_id, RPMX_MTI_LPCSX_CONTROL1, cfg);
+
+	if (lmac_type == LMAC_MODE_QSGMII || lmac_type == LMAC_MODE_SGMII) {
+		dev_err(&rpm->pdev->dev, "loopback not supported for LPC mode\n");
+		return 0;
 	}
 
+	cfg = rpm_read(rpm, lmac_id, RPMX_MTI_PCS100X_CONTROL1);
+
+	if (enable)
+		cfg |= RPMX_MTI_PCS_LBK;
+	else
+		cfg &= ~RPMX_MTI_PCS_LBK;
+	rpm_write(rpm, lmac_id, RPMX_MTI_PCS100X_CONTROL1, cfg);
+
 	return 0;
 }

Signature · 1 line

2.34.1

Greg Kroah-Hartman

author maintainer

2022-01-31 11:22 UTC #127 lore raw

PATCH 127/171 octeontx2-pf: Forward error codes to VF

From: Subbaraya Sundeep <[email protected]>

[ Upstream commit a8db854be28622a2477cb21cdf7f829adbb2c42d ]

PF forwards its VF messages to AF and corresponding replies from AF to VF. AF sets proper error code in the replies after processing message requests. Currently PF checks the error codes in replies and sends invalid message to VF. This way VF lacks the information of error code set by AF for its messages. This patch changes that such that PF simply forwards AF replies so that VF can handle error codes.

Fixes d424b6c02415 ("octeontx2-pf: Enable SRIOV and added VF mbox handling")

Signed-off-by Subbaraya Sundeep <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

---
 drivers/net/ethernet/marvell/octeontx2/nic/otx2_pf.c | 7 ++++++-
 1 file changed, 6 insertions(+), 1 deletion(-)

drivers/net/ethernet/marvell/octeontx2/nic/otx2_pf.c +6 -1

index 53a3e8de1a51e..b1894d4045b8d 100644
@@ -386,7 +386,12 @@ static int otx2_forward_vf_mbox_msgs(struct otx2_nic *pf,
 		dst_mdev->msg_size = mbox_hdr->msg_size;
 		dst_mdev->num_msgs = num_msgs;
 		err = otx2_sync_mbox_msg(dst_mbox);
-		if (err) {
+		/* Error code -EIO indicate there is a communication failure
+		 * to the AF. Rest of the error codes indicate that AF processed
+		 * VF messages and set the error codes in response messages
+		 * (if any) so simply forward responses to VF.
+		 */
+		if (err == -EIO) {
 			dev_warn(pf->dev,
 				 "AF not responding to VF%d messages\n", vf);
 			/* restore PF mbase and exit */

Signature · 1 line

2.34.1

Greg Kroah-Hartman

author maintainer

2022-01-31 11:14 UTC #128 lore raw

PATCH 128/171 rxrpc: Adjust retransmission backoff

Link https://lore.kernel.org/r/164138117069.2023386.17446904856843997127.stgit@warthog.procyon.org.uk/ open here

From: David Howells <[email protected]>

[ Upstream commit 2c13c05c5ff4b9fc907b07f7311821910ebaaf8a ]

Improve retransmission backoff by only backing off when we retransmit data packets rather than when we set the lost ack timer.

To this end:

(1) In rxrpc_resend(), use rxrpc_get_rto_backoff() when setting the retransmission timer and only tell it that we are retransmitting if we actually have things to retransmit.

Note that it's possible for the retransmission algorithm to race with the processing of a received ACK, so we may see no packets needing retransmission.

(2) In rxrpc_send_data_packet(), don't bump the backoff when setting the ack_lost_at timer, as it may then get bumped twice.

With this, when looking at one particular packet, the retransmission intervals were seen to be 1.5ms, 2ms, 3ms, 5ms, 9ms, 17ms, 33ms, 71ms, 136ms, 264ms, 544ms, 1.088s, 2.1s, 4.2s and 8.3s.

Fixes c410bf01933e ("rxrpc: Fix the excessive initial retransmission timeout")

Signed-off-by David Howells <[email protected]>

Reviewed-by Marc Dionne <[email protected]>

Tested-by Marc Dionne <[email protected]>

cc [email protected]

Signed-off-by Sasha Levin <[email protected]>

---
 net/rxrpc/call_event.c | 8 +++-----
 net/rxrpc/output.c     | 2 +-
 2 files changed, 4 insertions(+), 6 deletions(-)

net/rxrpc/call_event.c +3 -5

index 6be2672a65eab..df864e6922679 100644
@@ -157,7 +157,7 @@ static void rxrpc_congestion_timeout(struct rxrpc_call *call)
 static void rxrpc_resend(struct rxrpc_call *call, unsigned long now_j)
 {
 	struct sk_buff *skb;
-	unsigned long resend_at, rto_j;
+	unsigned long resend_at;
 	rxrpc_seq_t cursor, seq, top;
 	ktime_t now, max_age, oldest, ack_ts;
 	int ix;

@@ -165,10 +165,8 @@ static void rxrpc_resend(struct rxrpc_call *call, unsigned long now_j)
 
 	_enter("{%d,%d}", call->tx_hard_ack, call->tx_top);
 
-	rto_j = call->peer->rto_j;
-
 	now = ktime_get_real();
-	max_age = ktime_sub(now, jiffies_to_usecs(rto_j));
+	max_age = ktime_sub(now, jiffies_to_usecs(call->peer->rto_j));
 
 	spin_lock_bh(&call->lock);

@@ -213,7 +211,7 @@ static void rxrpc_resend(struct rxrpc_call *call, unsigned long now_j)
 	}
 
 	resend_at = nsecs_to_jiffies(ktime_to_ns(ktime_sub(now, oldest)));
-	resend_at += jiffies + rto_j;
+	resend_at += jiffies + rxrpc_get_rto_backoff(call->peer, retrans);
 	WRITE_ONCE(call->resend_at, resend_at);
 
 	if (unacked)

net/rxrpc/output.c +1 -1

index 10f2bf2e9068a..a45c83f22236e 100644
@@ -468,7 +468,7 @@ done:
 			if (call->peer->rtt_count > 1) {
 				unsigned long nowj = jiffies, ack_lost_at;
 
-				ack_lost_at = rxrpc_get_rto_backoff(call->peer, retrans);
+				ack_lost_at = rxrpc_get_rto_backoff(call->peer, false);
 				ack_lost_at += nowj;
 				WRITE_ONCE(call->ack_lost_at, ack_lost_at);
 				rxrpc_reduce_call_timer(call, ack_lost_at, nowj,

Signature · 1 line

2.34.1

Greg Kroah-Hartman

author maintainer

2022-01-31 11:14 UTC #129 lore raw

PATCH 129/171 efi/libstub: arm64: Fix image check alignment at entry

From: Mihai Carabas <[email protected]>

[ Upstream commit e9b7c3a4263bdcfd31bc3d03d48ce0ded7a94635 ]

The kernel is aligned at SEGMENT_SIZE and this is the size populated in the PE headers:

arch/arm64/kernel/efi-header.S: .long SEGMENT_ALIGN // SectionAlignment

EFI_KIMG_ALIGN is defined as: (SEGMENT_ALIGN > THREAD_ALIGN ? SEGMENT_ALIGN :
THREAD_ALIGN)

So it depends on THREAD_ALIGN. On newer builds this message started to appear even though the loader is taking into account the PE header (which is stating SEGMENT_ALIGN).

Fixes c32ac11da3f8 ("efi/libstub: arm64: Double check image alignment at entry")

Signed-off-by Mihai Carabas <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

---
 drivers/firmware/efi/libstub/arm64-stub.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

drivers/firmware/efi/libstub/arm64-stub.c +3 -3

index 2363fee9211c9..9cc556013d085 100644
@@ -119,9 +119,9 @@ efi_status_t handle_kernel_image(unsigned long *image_addr,
 	if (image->image_base != _text)
 		efi_err("FIRMWARE BUG: efi_loaded_image_t::image_base has bogus value\n");
 
-	if (!IS_ALIGNED((u64)_text, EFI_KIMG_ALIGN))
-		efi_err("FIRMWARE BUG: kernel image not aligned on %ldk boundary\n",
-			EFI_KIMG_ALIGN >> 10);
+	if (!IS_ALIGNED((u64)_text, SEGMENT_ALIGN))
+		efi_err("FIRMWARE BUG: kernel image not aligned on %dk boundary\n",
+			SEGMENT_ALIGN >> 10);
 
 	kernel_size = _edata - _text;
 	kernel_memsize = kernel_size + (_end - _edata);

Signature · 1 line

2.34.1

Greg Kroah-Hartman

author maintainer

2022-01-31 11:22 UTC #130 lore raw

PATCH 130/171 io_uring: fix bug in slow unregistering of nodes

From: Dylan Yudaken <[email protected]>

[ Upstream commit b36a2050040b2d839bdc044007cdd57101d7f881 ]

In some cases io_rsrc_ref_quiesce will call io_rsrc_node_switch_start, and then immediately flush the delayed work queue &ctx->rsrc_put_work.

However the percpu_ref_put does not immediately destroy the node, it will be called asynchronously via RCU. That ends up with io_rsrc_node_ref_zero only being called after rsrc_put_work has been flushed, and so the process ends up sleeping for 1 second unnecessarily.

This patch executes the put code immediately if we are busy quiescing.

Fixes 4a38aed2a0a7 ("io_uring: batch reap of dead file registrations")

Signed-off-by Dylan Yudaken <[email protected]>

Link https://lore.kernel.org/r/[email protected] open here

Signed-off-by Jens Axboe <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

---
 fs/io_uring.c | 7 ++++++-
 1 file changed, 6 insertions(+), 1 deletion(-)

fs/io_uring.c +6 -1

index f713b91537f41..993913c585fbf 100644
@@ -7718,10 +7718,15 @@ static void io_rsrc_node_ref_zero(struct percpu_ref *ref)
 	struct io_ring_ctx *ctx = node->rsrc_data->ctx;
 	unsigned long flags;
 	bool first_add = false;
+	unsigned long delay = HZ;
 
 	spin_lock_irqsave(&ctx->rsrc_ref_lock, flags);
 	node->done = true;
 
+	/* if we are mid-quiesce then do not delay */
+	if (node->rsrc_data->quiesce)
+		delay = 0;
+
 	while (!list_empty(&ctx->rsrc_ref_list)) {
 		node = list_first_entry(&ctx->rsrc_ref_list,
 					    struct io_rsrc_node, node);

@@ -7734,7 +7739,7 @@ static void io_rsrc_node_ref_zero(struct percpu_ref *ref)
 	spin_unlock_irqrestore(&ctx->rsrc_ref_lock, flags);
 
 	if (first_add)
-		mod_delayed_work(system_wq, &ctx->rsrc_put_work, HZ);
+		mod_delayed_work(system_wq, &ctx->rsrc_put_work, delay);
 }
 
 static struct io_rsrc_node *io_rsrc_node_alloc(struct io_ring_ctx *ctx)

Signature · 1 line

2.34.1

Greg Kroah-Hartman

author maintainer

2022-01-31 11:15 UTC #131 lore raw

PATCH 131/171 Drivers: hv: balloon: account for vmbus packet header in max_pkt_size

From: Yanming Liu <[email protected]>

[ Upstream commit 96d9d1fa5cd505078534113308ced0aa56d8da58 ]

Commit adae1e931acd ("Drivers: hv: vmbus: Copy packets sent by Hyper-V out of the ring buffer") introduced a notion of maximum packet size in vmbus channel and used that size to initialize a buffer holding all incoming packet along with their vmbus packet header. hv_balloon uses the default maximum packet size VMBUS_DEFAULT_MAX_PKT_SIZE which matches its maximum message size, however vmbus_open expects this size to also include vmbus packet header. This leads to 4096 bytes dm_unballoon_request messages being truncated to 4080 bytes. When the driver tries to read next packet it starts from a wrong read_index, receives garbage and prints a lot of "Unhandled message: type:
<garbage>" in dmesg.

Allocate the buffer with HV_HYP_PAGE_SIZE more bytes to make room for the header.

Fixes adae1e931acd ("Drivers: hv: vmbus: Copy packets sent by Hyper-V out of the ring buffer")

Signed-off-by Yanming Liu <[email protected]>

Reviewed-by Michael Kelley <[email protected]>

Reviewed-by Andrea Parri (Microsoft) <[email protected]>

Link https://lore.kernel.org/r/[email protected] open here

Signed-off-by Wei Liu <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

---
 drivers/hv/hv_balloon.c | 7 +++++++
 1 file changed, 7 insertions(+)

drivers/hv/hv_balloon.c +7 -0

index ca873a3b98dbe..f2d05bff42453 100644
@@ -1660,6 +1660,13 @@ static int balloon_connect_vsp(struct hv_device *dev)
 	unsigned long t;
 	int ret;
 
+	/*
+	 * max_pkt_size should be large enough for one vmbus packet header plus
+	 * our receive buffer size. Hyper-V sends messages up to
+	 * HV_HYP_PAGE_SIZE bytes long on balloon channel.
+	 */
+	dev->channel->max_pkt_size = HV_HYP_PAGE_SIZE * 2;
+
 	ret = vmbus_open(dev->channel, dm_ring_size, dm_ring_size, NULL, 0,
 			 balloon_onchannelcallback, dev);
 	if (ret)

Signature · 1 line

2.34.1

Greg Kroah-Hartman

author maintainer

2022-01-31 11:27 UTC #132 lore raw

PATCH 132/171 hwmon: (lm90) Re-enable interrupts after alert clears

From: Guenter Roeck <[email protected]>

[ Upstream commit bc341a1a98827925082e95db174734fc8bd68af6 ]

If alert handling is broken, interrupts are disabled after an alert and re-enabled after the alert clears. However, if there is an interrupt handler, this does not apply if alerts were originally disabled and enabled when the driver was loaded. In that case, interrupts will stay disabled after an alert was handled though the alert handler even after the alert condition clears. Address the situation by always re-enabling interrupts after the alert condition clears if there is an interrupt handler.

Fixes 2abdc357c55d9 ("hwmon: (lm90) Unmask hardware interrupt")

Cc Dmitry Osipenko <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

---
 drivers/hwmon/lm90.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

drivers/hwmon/lm90.c +1 -1

index cc5e48fe304b1..e4ecf3440d7cf 100644
@@ -848,7 +848,7 @@ static int lm90_update_device(struct device *dev)
 		 * Re-enable ALERT# output if it was originally enabled and
 		 * relevant alarms are all clear
 		 */
-		if (!(data->config_orig & 0x80) &&
+		if ((client->irq || !(data->config_orig & 0x80)) &&
 		    !(data->alarms & data->alert_alarms)) {
 			if (data->config & 0x80) {
 				dev_dbg(&client->dev, "Re-enabling ALERT#\n");

Signature · 1 line

2.34.1

Greg Kroah-Hartman

author maintainer

2022-01-31 11:15 UTC #133 lore raw

PATCH 133/171 hwmon: (lm90) Mark alert as broken for MAX6654

From: Guenter Roeck <[email protected]>

[ Upstream commit a53fff96f35763d132a36c620b183fdf11022d7a ]

Experiments with MAX6654 show that its alert function is broken, similar to other chips supported by the lm90 driver. Mark it accordingly.

Fixes 229d495d8189 ("hwmon: (lm90) Add max6654 support to lm90 driver")

Cc Josh Lehan <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

---
 drivers/hwmon/lm90.c | 1 +
 1 file changed, 1 insertion(+)

drivers/hwmon/lm90.c +1 -0

index e4ecf3440d7cf..280ae5f58187b 100644
@@ -400,6 +400,7 @@ static const struct lm90_params lm90_params[] = {
 		.reg_local_ext = MAX6657_REG_R_LOCAL_TEMPL,
 	},
 	[max6654] = {
+		.flags = LM90_HAVE_BROKEN_ALERT,
 		.alert_alarms = 0x7c,
 		.max_convrate = 7,
 		.reg_local_ext = MAX6657_REG_R_LOCAL_TEMPL,

Signature · 1 line

2.34.1

Greg Kroah-Hartman

author maintainer

2022-01-31 11:15 UTC #134 lore raw

PATCH 134/171 hwmon: (lm90) Fix sysfs and udev notifications

From: Guenter Roeck <[email protected]>

[ Upstream commit d379880d9adb9f1ada3f1266aa49ea2561328e08 ]

sysfs and udev notifications need to be sent to the _alarm attributes, not to the value attributes.

Fixes 94dbd23ed88c ("hwmon: (lm90) Use hwmon_notify_event()")

Cc Dmitry Osipenko <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

---
 drivers/hwmon/lm90.c | 12 ++++++------
 1 file changed, 6 insertions(+), 6 deletions(-)

drivers/hwmon/lm90.c +6 -6

index ba01127c1deb1..1c9493c708132 100644
@@ -1808,22 +1808,22 @@ static bool lm90_is_tripped(struct i2c_client *client, u16 *status)
 
 	if (st & LM90_STATUS_LLOW)
 		hwmon_notify_event(data->hwmon_dev, hwmon_temp,
-				   hwmon_temp_min, 0);
+				   hwmon_temp_min_alarm, 0);
 	if (st & LM90_STATUS_RLOW)
 		hwmon_notify_event(data->hwmon_dev, hwmon_temp,
-				   hwmon_temp_min, 1);
+				   hwmon_temp_min_alarm, 1);
 	if (st2 & MAX6696_STATUS2_R2LOW)
 		hwmon_notify_event(data->hwmon_dev, hwmon_temp,
-				   hwmon_temp_min, 2);
+				   hwmon_temp_min_alarm, 2);
 	if (st & LM90_STATUS_LHIGH)
 		hwmon_notify_event(data->hwmon_dev, hwmon_temp,
-				   hwmon_temp_max, 0);
+				   hwmon_temp_max_alarm, 0);
 	if (st & LM90_STATUS_RHIGH)
 		hwmon_notify_event(data->hwmon_dev, hwmon_temp,
-				   hwmon_temp_max, 1);
+				   hwmon_temp_max_alarm, 1);
 	if (st2 & MAX6696_STATUS2_R2HIGH)
 		hwmon_notify_event(data->hwmon_dev, hwmon_temp,
-				   hwmon_temp_max, 2);
+				   hwmon_temp_max_alarm, 2);
 
 	return true;
 }

Signature · 1 line

2.34.1

Greg Kroah-Hartman

author maintainer

2022-01-31 11:16 UTC #135 lore raw

PATCH 135/171 hwmon: (adt7470) Prevent divide by zero in adt7470_fan_write()

From: Dan Carpenter <[email protected]>

[ Upstream commit c1ec0cabc36718efc7fe8b4157d41b82d08ec1d2 ]

The "val" variable is controlled by the user and comes from hwmon_attr_store(). The FAN_RPM_TO_PERIOD() macro divides by "val" so a zero will crash the system. Check for that and return -EINVAL. Negatives are also invalid so return -EINVAL for those too.

Fixes fc958a61ff6d ("hwmon: (adt7470) Convert to devm_hwmon_device_register_with_info API")

Signed-off-by Dan Carpenter <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

---
 drivers/hwmon/adt7470.c | 3 +++
 1 file changed, 3 insertions(+)

drivers/hwmon/adt7470.c +3 -0

index d519aca4a9d64..fb6d14d213a18 100644
@@ -662,6 +662,9 @@ static int adt7470_fan_write(struct device *dev, u32 attr, int channel, long val
 	struct adt7470_data *data = dev_get_drvdata(dev);
 	int err;
 
+	if (val <= 0)
+		return -EINVAL;
+
 	val = FAN_RPM_TO_PERIOD(val);
 	val = clamp_val(val, 1, 65534);

Signature · 1 line

2.34.1

Greg Kroah-Hartman

author maintainer

2022-01-31 11:35 UTC #136 lore raw

PATCH 136/171 powerpc/perf: Fix power_pmu_disable to call clear_pmi_irq_pending only if PMI is pending

From: Athira Rajeev <[email protected]>

[ Upstream commit fb6433b48a178d4672cb26632454ee0b21056eaa ]

Running selftest with CONFIG_PPC_IRQ_SOFT_MASK_DEBUG enabled in kernel triggered below warning:

[  172.851380] ------------[ cut here ]------------
[  172.851391] WARNING: CPU: 8 PID: 2901 at arch/powerpc/include/asm/hw_irq.h:246 power_pmu_disable+0x270/0x280
[  172.851402] Modules linked in: dm_mod bonding nft_ct nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 ip_set nf_tables rfkill nfnetlink sunrpc xfs libcrc32c pseries_rng xts vmx_crypto uio_pdrv_genirq uio sch_fq_codel ip_tables ext4 mbcache jbd2 sd_mod t10_pi sg ibmvscsi ibmveth scsi_transport_srp fuse
[  172.851442] CPU: 8 PID: 2901 Comm: lost_exception_ Not tainted 5.16.0-rc5-03218-g798527287598 #2
[  172.851451] NIP:  c00000000013d600 LR: c00000000013d5a4 CTR: c00000000013b180
[  172.851458] REGS: c000000017687860 TRAP: 0700   Not tainted  (5.16.0-rc5-03218-g798527287598)
[  172.851465] MSR:  8000000000029033 <SF,EE,ME,IR,DR,RI,LE>  CR: 48004884  XER: 20040000
[  172.851482] CFAR: c00000000013d5b4 IRQMASK: 1
[  172.851482] GPR00: c00000000013d5a4 c000000017687b00 c000000002a10600 0000000000000004
[  172.851482] GPR04: 0000000082004000 c0000008ba08f0a8 0000000000000000 00000008b7ed0000
[  172.851482] GPR08: 00000000446194f6 0000000000008000 c00000000013b118 c000000000d58e68
[  172.851482] GPR12: c00000000013d390 c00000001ec54a80 0000000000000000 0000000000000000
[  172.851482] GPR16: 0000000000000000 0000000000000000 c000000015d5c708 c0000000025396d0
[  172.851482] GPR20: 0000000000000000 0000000000000000 c00000000a3bbf40 0000000000000003
[  172.851482] GPR24: 0000000000000000 c0000008ba097400 c0000000161e0d00 c00000000a3bb600
[  172.851482] GPR28: c000000015d5c700 0000000000000001 0000000082384090 c0000008ba0020d8
[  172.851549] NIP [c00000000013d600] power_pmu_disable+0x270/0x280
[  172.851557] LR [c00000000013d5a4] power_pmu_disable+0x214/0x280
[  172.851565] Call Trace:
[  172.851568] [c000000017687b00] [c00000000013d5a4] power_pmu_disable+0x214/0x280 (unreliable)
[  172.851579] [c000000017687b40] [c0000000003403ac] perf_pmu_disable+0x4c/0x60
[  172.851588] [c000000017687b60] [c0000000003445e4] __perf_event_task_sched_out+0x1d4/0x660
[  172.851596] [c000000017687c50] [c000000000d1175c] __schedule+0xbcc/0x12a0
[  172.851602] [c000000017687d60] [c000000000d11ea8] schedule+0x78/0x140
[  172.851608] [c000000017687d90] [c0000000001a8080] sys_sched_yield+0x20/0x40
[  172.851615] [c000000017687db0] [c0000000000334dc] system_call_exception+0x18c/0x380
[  172.851622] [c000000017687e10] [c00000000000c74c] system_call_common+0xec/0x268

The warning indicates that MSR_EE being set(interrupt enabled) when there was an overflown PMC detected. This could happen in power_pmu_disable since it runs under interrupt soft disable condition ( local_irq_save ) and not with interrupts hard disabled. commit 2c9ac51b850d ("powerpc/perf: Fix PMU callbacks to clear pending PMI before resetting an overflown PMC") intended to clear PMI pending bit in Paca when disabling the PMU. It could happen that PMC gets overflown while code is in power_pmu_disable callback function. Hence add a check to see if PMI pending bit is set in Paca before clearing it via clear_pmi_pending.

Fixes 2c9ac51b850d ("powerpc/perf: Fix PMU callbacks to clear pending PMI before resetting an overflown PMC")

Reported-by Sachin Sant <[email protected]>

Signed-off-by Athira Rajeev <[email protected]>

Tested-by Sachin Sant <[email protected]>

Reviewed-by Nicholas Piggin <[email protected]>

Link https://lore.kernel.org/r/[email protected] open here

Signed-off-by Sasha Levin <[email protected]>

---
 arch/powerpc/perf/core-book3s.c | 17 ++++++++++++++---
 1 file changed, 14 insertions(+), 3 deletions(-)

arch/powerpc/perf/core-book3s.c +14 -3

index bef6b1abce702..e78de70509472 100644
@@ -1326,9 +1326,20 @@ static void power_pmu_disable(struct pmu *pmu)
 		 * Otherwise provide a warning if there is PMI pending, but
 		 * no counter is found overflown.
 		 */
-		if (any_pmc_overflown(cpuhw))
-			clear_pmi_irq_pending();
-		else
+		if (any_pmc_overflown(cpuhw)) {
+			/*
+			 * Since power_pmu_disable runs under local_irq_save, it
+			 * could happen that code hits a PMC overflow without PMI
+			 * pending in paca. Hence only clear PMI pending if it was
+			 * set.
+			 *
+			 * If a PMI is pending, then MSR[EE] must be disabled (because
+			 * the masked PMI handler disabling EE). So it is safe to
+			 * call clear_pmi_irq_pending().
+			 */
+			if (pmi_irq_pending())
+				clear_pmi_irq_pending();
+		} else
 			WARN_ON(pmi_irq_pending());
 
 		val = mmcra = cpuhw->mmcr.mmcra;

Signature · 1 line

2.34.1

Greg Kroah-Hartman

author maintainer

2022-01-31 11:17 UTC #137 lore raw

PATCH 137/171 ipv4: fix ip option filtering for locally generated fragments

Link https://lore.kernel.org/netdev/[email protected]/ open here

From: Jakub Kicinski <[email protected]>

[ Upstream commit 27a8caa59babb96c5890569e131bc0eb6d45daee ]

During IP fragmentation we sanitize IP options. This means overwriting options which should not be copied with NOPs. Only the first fragment has the original, full options.

ip_fraglist_prepare() copies the IP header and options from previous fragment to the next one. Commit 19c3401a917b ("net: ipv4: place control buffer handling away from fragmentation iterators") moved sanitizing options before ip_fraglist_prepare() which means options are sanitized and then overwritten again with the old values.

Fixing this is not enough, however, nor did the sanitization work prior to aforementioned commit.

ip_options_fragment() (which does the sanitization) uses ipcb->opt.optlen for the length of the options. ipcb->opt of fragments is not populated (it's 0), only the head skb has the state properly built. So even when called at the right time ip_options_fragment() does nothing. This seems to date back all the way to v2.5.44 when the fast path for pre-fragmented skbs had been introduced. Prior to that ip_options_build() would have been called for every fragment (in fact ever since v2.5.44 the fragmentation handing in ip_options_build() has been dead code, I'll clean it up in -next).

In the original patch (see Link) caixf mentions fixing the handling for fragments other than the second one, but I'm not sure how _any_ fragment could have had their options sanitized with the code as it stood.

Tested with python (MTU on lo lowered to 1000 to force fragmentation):

import socket
s = socket.socket(socket.AF_INET, socket.SOCK_DGRAM) s.setsockopt(socket.IPPROTO_IP, socket.IP_OPTIONS,

               bytearray([7,4,5,192, 20|0x80,4,1,0]))

s.sendto(b'1'*2000, ('127.0.0.1', 1234))

Before:

IP (tos 0x0, ttl 64, id 1053, offset 0, flags [+], proto UDP (17), length 996, options (RR [bad length 4] [bad ptr 5] 192.148.4.1,,RA value 256))

    localhost.36500 > localhost.search-agent: UDP, length 2000

IP (tos 0x0, ttl 64, id 1053, offset 968, flags [+], proto UDP (17), length 996, options (RR [bad length 4] [bad ptr 5] 192.148.4.1,,RA value 256))
localhost > localhost: udp
IP (tos 0x0, ttl 64, id 1053, offset 1936, flags [none], proto UDP (17), length 100, options (RR [bad length 4] [bad ptr 5] 192.148.4.1,,RA value 256))
localhost > localhost: udp

After:

IP (tos 0x0, ttl 96, id 42549, offset 0, flags [+], proto UDP (17), length 996, options (RR [bad length 4] [bad ptr 5] 192.148.4.1,,RA value 256))

    localhost.51607 > localhost.search-agent: UDP, bad length 2000 > 960

IP (tos 0x0, ttl 96, id 42549, offset 968, flags [+], proto UDP (17), length 996, options (NOP,NOP,NOP,NOP,RA value 256))
localhost > localhost: udp
IP (tos 0x0, ttl 96, id 42549, offset 1936, flags [none], proto UDP (17), length 100, options (NOP,NOP,NOP,NOP,RA value 256))
localhost > localhost: udp

RA (20 | 0x80) is now copied as expected, RR (7) is "NOPed out".

Fixes 19c3401a917b ("net: ipv4: place control buffer handling away from fragmentation iterators")

Fixes 1da177e4c3f4 ("Linux-2.6.12-rc2")

Signed-off-by caixf <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

---
 net/ipv4/ip_output.c | 15 ++++++++++++---
 1 file changed, 12 insertions(+), 3 deletions(-)

net/ipv4/ip_output.c +12 -3

index 9bca57ef8b838..ff38b46bd4b0f 100644
@@ -826,15 +826,24 @@ int ip_do_fragment(struct net *net, struct sock *sk, struct sk_buff *skb,
 		/* Everything is OK. Generate! */
 		ip_fraglist_init(skb, iph, hlen, &iter);
 
-		if (iter.frag)
-			ip_options_fragment(iter.frag);
-
 		for (;;) {
 			/* Prepare header of the next frame,
 			 * before previous one went down. */
 			if (iter.frag) {
+				bool first_frag = (iter.offset == 0);
+
 				IPCB(iter.frag)->flags = IPCB(skb)->flags;
 				ip_fraglist_prepare(skb, &iter);
+				if (first_frag && IPCB(skb)->opt.optlen) {
+					/* ipcb->opt is not populated for frags
+					 * coming from __ip_make_skb(),
+					 * ip_options_fragment() needs optlen
+					 */
+					IPCB(iter.frag)->opt.optlen =
+						IPCB(skb)->opt.optlen;
+					ip_options_fragment(iter.frag);
+					ip_send_check(iter.iph);
+				}
 			}
 
 			skb->tstamp = tstamp;

Signature · 1 line

2.34.1

Greg Kroah-Hartman

author maintainer

2022-01-31 11:35 UTC #138 lore raw

PATCH 138/171 ibmvnic: Allow extra failures before disabling

From: Sukadev Bhattiprolu <[email protected]>

[ Upstream commit db9f0e8bf79e6da7068b5818fea0ffd9d0d4b4da ]

If auto-priority-failover (APF) is enabled and there are at least two backing devices of different priorities, some resets like fail-over, change-param etc can cause at least two back to back failovers. (Failover from high priority backing device to lower priority one and then back to the higher priority one if that is still functional).

Depending on the timimg of the two failovers it is possible to trigger a "hard" reset and for the hard reset to fail due to failovers. When this occurs, the driver assumes that the network is unstable and disables the VNIC for a 60-second "settling time". This in turn can cause the ethtool command to fail with "No such device" while the vnic automatically recovers a little while later.

Given that it's possible to have two back to back failures, allow for extra failures before disabling the vnic for the settling time.

Fixes f15fde9d47b8 ("ibmvnic: delay next reset if hard reset fails")

Signed-off-by Sukadev Bhattiprolu <[email protected]>

Reviewed-by Dany Madden <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

---
 drivers/net/ethernet/ibm/ibmvnic.c | 21 +++++++++++++++++----
 1 file changed, 17 insertions(+), 4 deletions(-)

drivers/net/ethernet/ibm/ibmvnic.c +17 -4

index 352ffe982d849..191b3b7350182 100644
@@ -2424,6 +2424,7 @@ static void __ibmvnic_reset(struct work_struct *work)
 	struct ibmvnic_rwi *rwi;
 	unsigned long flags;
 	u32 reset_state;
+	int num_fails = 0;
 	int rc = 0;
 
 	adapter = container_of(work, struct ibmvnic_adapter, ibmvnic_reset);

@@ -2477,11 +2478,23 @@ static void __ibmvnic_reset(struct work_struct *work)
 				rc = do_hard_reset(adapter, rwi, reset_state);
 				rtnl_unlock();
 			}
-			if (rc) {
-				/* give backing device time to settle down */
+			if (rc)
+				num_fails++;
+			else
+				num_fails = 0;
+
+			/* If auto-priority-failover is enabled we can get
+			 * back to back failovers during resets, resulting
+			 * in at least two failed resets (from high-priority
+			 * backing device to low-priority one and then back)
+			 * If resets continue to fail beyond that, give the
+			 * adapter some time to settle down before retrying.
+			 */
+			if (num_fails >= 3) {
 				netdev_dbg(adapter->netdev,
-					   "[S:%s] Hard reset failed, waiting 60 secs\n",
-					   adapter_state_to_string(adapter->state));
+					   "[S:%s] Hard reset failed %d times, waiting 60 secs\n",
+					   adapter_state_to_string(adapter->state),
+					   num_fails);
 				set_current_state(TASK_UNINTERRUPTIBLE);
 				schedule_timeout(60 * HZ);
 			}

Signature · 1 line

2.34.1

Greg Kroah-Hartman

author maintainer

2022-01-31 11:35 UTC #139 lore raw

PATCH 139/171 ibmvnic: init ->running_cap_crqs early

From: Sukadev Bhattiprolu <[email protected]>

[ Upstream commit 151b6a5c06b678687f64f2d9a99fd04d5cd32b72 ]

We use ->running_cap_crqs to determine when the ibmvnic_tasklet() should send out the next protocol message type. i.e when we get back responses to all our QUERY_CAPABILITY CRQs we send out REQUEST_CAPABILITY crqs. Similiary, when we get responses to all the REQUEST_CAPABILITY crqs, we send out the QUERY_IP_OFFLOAD CRQ.

We currently increment ->running_cap_crqs as we send out each CRQ and have the ibmvnic_tasklet() send out the next message type, when this running_cap_crqs count drops to 0.

This assumes that all the CRQs of the current type were sent out before the count drops to 0. However it is possible that we send out say 6 CRQs, get preempted and receive all the 6 responses before we send out the remaining CRQs. This can result in ->running_cap_crqs count dropping to zero before all messages of the current type were sent and we end up sending the next protocol message too early.

Instead initialize the ->running_cap_crqs upfront so the tasklet will only send the next protocol message after all responses are received.

Use the cap_reqs local variable to also detect any discrepancy (either now or in future) in the number of capability requests we actually send.

Currently only send_query_cap() is affected by this behavior (of sending next message early) since it is called from the worker thread (during reset) and from application thread (during ->ndo_open()) and they can be preempted. send_request_cap() is only called from the tasklet which processes CRQ responses sequentially, is not be affected. But to maintain the existing symmtery with send_query_capability() we update send_request_capability() also.

Fixes 249168ad07cd ("ibmvnic: Make CRQ interrupt tasklet wait for all capabilities crqs")

Signed-off-by Sukadev Bhattiprolu <[email protected]>

Reviewed-by Dany Madden <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

---
 drivers/net/ethernet/ibm/ibmvnic.c | 106 +++++++++++++++++++----------
 1 file changed, 71 insertions(+), 35 deletions(-)

drivers/net/ethernet/ibm/ibmvnic.c +71 ~~-35~~

index 191b3b7350182..a3dd5c648fecd 100644
@@ -3675,11 +3675,25 @@ static void send_request_cap(struct ibmvnic_adapter *adapter, int retry)
 	struct device *dev = &adapter->vdev->dev;
 	union ibmvnic_crq crq;
 	int max_entries;
+	int cap_reqs;
+
+	/* We send out 6 or 7 REQUEST_CAPABILITY CRQs below (depending on
+	 * the PROMISC flag). Initialize this count upfront. When the tasklet
+	 * receives a response to all of these, it will send the next protocol
+	 * message (QUERY_IP_OFFLOAD).
+	 */
+	if (!(adapter->netdev->flags & IFF_PROMISC) ||
+	    adapter->promisc_supported)
+		cap_reqs = 7;
+	else
+		cap_reqs = 6;
 
 	if (!retry) {
 		/* Sub-CRQ entries are 32 byte long */
 		int entries_page = 4 * PAGE_SIZE / (sizeof(u64) * 4);
 
+		atomic_set(&adapter->running_cap_crqs, cap_reqs);
+
 		if (adapter->min_tx_entries_per_subcrq > entries_page ||
 		    adapter->min_rx_add_entries_per_subcrq > entries_page) {
 			dev_err(dev, "Fatal, invalid entries per sub-crq\n");

@@ -3740,44 +3754,45 @@ static void send_request_cap(struct ibmvnic_adapter *adapter, int retry)
 					adapter->opt_rx_comp_queues;
 
 		adapter->req_rx_add_queues = adapter->max_rx_add_queues;
+	} else {
+		atomic_add(cap_reqs, &adapter->running_cap_crqs);
 	}
-
 	memset(&crq, 0, sizeof(crq));
 	crq.request_capability.first = IBMVNIC_CRQ_CMD;
 	crq.request_capability.cmd = REQUEST_CAPABILITY;
 
 	crq.request_capability.capability = cpu_to_be16(REQ_TX_QUEUES);
 	crq.request_capability.number = cpu_to_be64(adapter->req_tx_queues);
-	atomic_inc(&adapter->running_cap_crqs);
+	cap_reqs--;
 	ibmvnic_send_crq(adapter, &crq);
 
 	crq.request_capability.capability = cpu_to_be16(REQ_RX_QUEUES);
 	crq.request_capability.number = cpu_to_be64(adapter->req_rx_queues);
-	atomic_inc(&adapter->running_cap_crqs);
+	cap_reqs--;
 	ibmvnic_send_crq(adapter, &crq);
 
 	crq.request_capability.capability = cpu_to_be16(REQ_RX_ADD_QUEUES);
 	crq.request_capability.number = cpu_to_be64(adapter->req_rx_add_queues);
-	atomic_inc(&adapter->running_cap_crqs);
+	cap_reqs--;
 	ibmvnic_send_crq(adapter, &crq);
 
 	crq.request_capability.capability =
 	    cpu_to_be16(REQ_TX_ENTRIES_PER_SUBCRQ);
 	crq.request_capability.number =
 	    cpu_to_be64(adapter->req_tx_entries_per_subcrq);
-	atomic_inc(&adapter->running_cap_crqs);
+	cap_reqs--;
 	ibmvnic_send_crq(adapter, &crq);
 
 	crq.request_capability.capability =
 	    cpu_to_be16(REQ_RX_ADD_ENTRIES_PER_SUBCRQ);
 	crq.request_capability.number =
 	    cpu_to_be64(adapter->req_rx_add_entries_per_subcrq);
-	atomic_inc(&adapter->running_cap_crqs);
+	cap_reqs--;
 	ibmvnic_send_crq(adapter, &crq);
 
 	crq.request_capability.capability = cpu_to_be16(REQ_MTU);
 	crq.request_capability.number = cpu_to_be64(adapter->req_mtu);
-	atomic_inc(&adapter->running_cap_crqs);
+	cap_reqs--;
 	ibmvnic_send_crq(adapter, &crq);
 
 	if (adapter->netdev->flags & IFF_PROMISC) {

@@ -3785,16 +3800,21 @@ static void send_request_cap(struct ibmvnic_adapter *adapter, int retry)
 			crq.request_capability.capability =
 			    cpu_to_be16(PROMISC_REQUESTED);
 			crq.request_capability.number = cpu_to_be64(1);
-			atomic_inc(&adapter->running_cap_crqs);
+			cap_reqs--;
 			ibmvnic_send_crq(adapter, &crq);
 		}
 	} else {
 		crq.request_capability.capability =
 		    cpu_to_be16(PROMISC_REQUESTED);
 		crq.request_capability.number = cpu_to_be64(0);
-		atomic_inc(&adapter->running_cap_crqs);
+		cap_reqs--;
 		ibmvnic_send_crq(adapter, &crq);
 	}
+
+	/* Keep at end to catch any discrepancy between expected and actual
+	 * CRQs sent.
+	 */
+	WARN_ON(cap_reqs != 0);
 }
 
 static int pending_scrq(struct ibmvnic_adapter *adapter,

@@ -4188,118 +4208,132 @@ static void send_query_map(struct ibmvnic_adapter *adapter)
 static void send_query_cap(struct ibmvnic_adapter *adapter)
 {
 	union ibmvnic_crq crq;
+	int cap_reqs;
+
+	/* We send out 25 QUERY_CAPABILITY CRQs below.  Initialize this count
+	 * upfront. When the tasklet receives a response to all of these, it
+	 * can send out the next protocol messaage (REQUEST_CAPABILITY).
+	 */
+	cap_reqs = 25;
+
+	atomic_set(&adapter->running_cap_crqs, cap_reqs);
 
-	atomic_set(&adapter->running_cap_crqs, 0);
 	memset(&crq, 0, sizeof(crq));
 	crq.query_capability.first = IBMVNIC_CRQ_CMD;
 	crq.query_capability.cmd = QUERY_CAPABILITY;
 
 	crq.query_capability.capability = cpu_to_be16(MIN_TX_QUEUES);
-	atomic_inc(&adapter->running_cap_crqs);
 	ibmvnic_send_crq(adapter, &crq);
+	cap_reqs--;
 
 	crq.query_capability.capability = cpu_to_be16(MIN_RX_QUEUES);
-	atomic_inc(&adapter->running_cap_crqs);
 	ibmvnic_send_crq(adapter, &crq);
+	cap_reqs--;
 
 	crq.query_capability.capability = cpu_to_be16(MIN_RX_ADD_QUEUES);
-	atomic_inc(&adapter->running_cap_crqs);
 	ibmvnic_send_crq(adapter, &crq);
+	cap_reqs--;
 
 	crq.query_capability.capability = cpu_to_be16(MAX_TX_QUEUES);
-	atomic_inc(&adapter->running_cap_crqs);
 	ibmvnic_send_crq(adapter, &crq);
+	cap_reqs--;
 
 	crq.query_capability.capability = cpu_to_be16(MAX_RX_QUEUES);
-	atomic_inc(&adapter->running_cap_crqs);
 	ibmvnic_send_crq(adapter, &crq);
+	cap_reqs--;
 
 	crq.query_capability.capability = cpu_to_be16(MAX_RX_ADD_QUEUES);
-	atomic_inc(&adapter->running_cap_crqs);
 	ibmvnic_send_crq(adapter, &crq);
+	cap_reqs--;
 
 	crq.query_capability.capability =
 	    cpu_to_be16(MIN_TX_ENTRIES_PER_SUBCRQ);
-	atomic_inc(&adapter->running_cap_crqs);
 	ibmvnic_send_crq(adapter, &crq);
+	cap_reqs--;
 
 	crq.query_capability.capability =
 	    cpu_to_be16(MIN_RX_ADD_ENTRIES_PER_SUBCRQ);
-	atomic_inc(&adapter->running_cap_crqs);
 	ibmvnic_send_crq(adapter, &crq);
+	cap_reqs--;
 
 	crq.query_capability.capability =
 	    cpu_to_be16(MAX_TX_ENTRIES_PER_SUBCRQ);
-	atomic_inc(&adapter->running_cap_crqs);
 	ibmvnic_send_crq(adapter, &crq);
+	cap_reqs--;
 
 	crq.query_capability.capability =
 	    cpu_to_be16(MAX_RX_ADD_ENTRIES_PER_SUBCRQ);
-	atomic_inc(&adapter->running_cap_crqs);
 	ibmvnic_send_crq(adapter, &crq);
+	cap_reqs--;
 
 	crq.query_capability.capability = cpu_to_be16(TCP_IP_OFFLOAD);
-	atomic_inc(&adapter->running_cap_crqs);
 	ibmvnic_send_crq(adapter, &crq);
+	cap_reqs--;
 
 	crq.query_capability.capability = cpu_to_be16(PROMISC_SUPPORTED);
-	atomic_inc(&adapter->running_cap_crqs);
 	ibmvnic_send_crq(adapter, &crq);
+	cap_reqs--;
 
 	crq.query_capability.capability = cpu_to_be16(MIN_MTU);
-	atomic_inc(&adapter->running_cap_crqs);
 	ibmvnic_send_crq(adapter, &crq);
+	cap_reqs--;
 
 	crq.query_capability.capability = cpu_to_be16(MAX_MTU);
-	atomic_inc(&adapter->running_cap_crqs);
 	ibmvnic_send_crq(adapter, &crq);
+	cap_reqs--;
 
 	crq.query_capability.capability = cpu_to_be16(MAX_MULTICAST_FILTERS);
-	atomic_inc(&adapter->running_cap_crqs);
 	ibmvnic_send_crq(adapter, &crq);
+	cap_reqs--;
 
 	crq.query_capability.capability = cpu_to_be16(VLAN_HEADER_INSERTION);
-	atomic_inc(&adapter->running_cap_crqs);
 	ibmvnic_send_crq(adapter, &crq);
+	cap_reqs--;
 
 	crq.query_capability.capability = cpu_to_be16(RX_VLAN_HEADER_INSERTION);
-	atomic_inc(&adapter->running_cap_crqs);
 	ibmvnic_send_crq(adapter, &crq);
+	cap_reqs--;
 
 	crq.query_capability.capability = cpu_to_be16(MAX_TX_SG_ENTRIES);
-	atomic_inc(&adapter->running_cap_crqs);
 	ibmvnic_send_crq(adapter, &crq);
+	cap_reqs--;
 
 	crq.query_capability.capability = cpu_to_be16(RX_SG_SUPPORTED);
-	atomic_inc(&adapter->running_cap_crqs);
 	ibmvnic_send_crq(adapter, &crq);
+	cap_reqs--;
 
 	crq.query_capability.capability = cpu_to_be16(OPT_TX_COMP_SUB_QUEUES);
-	atomic_inc(&adapter->running_cap_crqs);
 	ibmvnic_send_crq(adapter, &crq);
+	cap_reqs--;
 
 	crq.query_capability.capability = cpu_to_be16(OPT_RX_COMP_QUEUES);
-	atomic_inc(&adapter->running_cap_crqs);
 	ibmvnic_send_crq(adapter, &crq);
+	cap_reqs--;
 
 	crq.query_capability.capability =
 			cpu_to_be16(OPT_RX_BUFADD_Q_PER_RX_COMP_Q);
-	atomic_inc(&adapter->running_cap_crqs);
 	ibmvnic_send_crq(adapter, &crq);
+	cap_reqs--;
 
 	crq.query_capability.capability =
 			cpu_to_be16(OPT_TX_ENTRIES_PER_SUBCRQ);
-	atomic_inc(&adapter->running_cap_crqs);
 	ibmvnic_send_crq(adapter, &crq);
+	cap_reqs--;
 
 	crq.query_capability.capability =
 			cpu_to_be16(OPT_RXBA_ENTRIES_PER_SUBCRQ);
-	atomic_inc(&adapter->running_cap_crqs);
 	ibmvnic_send_crq(adapter, &crq);
+	cap_reqs--;
 
 	crq.query_capability.capability = cpu_to_be16(TX_RX_DESC_REQ);
-	atomic_inc(&adapter->running_cap_crqs);
+
 	ibmvnic_send_crq(adapter, &crq);
+	cap_reqs--;
+
+	/* Keep at end to catch any discrepancy between expected and actual
+	 * CRQs sent.
+	 */
+	WARN_ON(cap_reqs != 0);
 }
 
 static void send_query_ip_offload(struct ibmvnic_adapter *adapter)

@@ -4604,6 +4638,8 @@ static void handle_request_cap_rsp(union ibmvnic_crq *crq,
 	char *name;
 
 	atomic_dec(&adapter->running_cap_crqs);
+	netdev_dbg(adapter->netdev, "Outstanding request-caps: %d\n",
+		   atomic_read(&adapter->running_cap_crqs));
 	switch (be16_to_cpu(crq->request_capability_rsp.capability)) {
 	case REQ_TX_QUEUES:
 		req_value = &adapter->req_tx_queues;

Signature · 1 line

2.34.1

Greg Kroah-Hartman

author maintainer

2022-01-31 11:17 UTC #140 lore raw

PATCH 140/171 ibmvnic: dont spin in tasklet

From: Sukadev Bhattiprolu <[email protected]>

[ Upstream commit 48079e7fdd0269d66b1d7d66ae88bd03162464ad ]

ibmvnic_tasklet() continuously spins waiting for responses to all capability requests. It does this to avoid encountering an error during initialization of the vnic. However if there is a bug in the VIOS and we do not receive a response to one or more queries the tasklet ends up spinning continuously leading to hard lock ups.

If we fail to receive a message from the VIOS it is reasonable to timeout the login attempt rather than spin indefinitely in the tasklet.

Fixes 249168ad07cd ("ibmvnic: Make CRQ interrupt tasklet wait for all capabilities crqs")

Signed-off-by Sukadev Bhattiprolu <[email protected]>

Reviewed-by Dany Madden <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

---
 drivers/net/ethernet/ibm/ibmvnic.c | 6 ------
 1 file changed, 6 deletions(-)

drivers/net/ethernet/ibm/ibmvnic.c +0 -6

index a3dd5c648fecd..5c7371dc83848 100644
@@ -5317,12 +5317,6 @@ static void ibmvnic_tasklet(struct tasklet_struct *t)
 			ibmvnic_handle_crq(crq, adapter);
 			crq->generic.first = 0;
 		}
-
-		/* remain in tasklet until all
-		 * capabilities responses are received
-		 */
-		if (!adapter->wait_capability)
-			done = true;
 	}
 	/* if capabilities CRQ's were sent in this tasklet, the following
 	 * tasklet must wait until all responses are received

Signature · 1 line

2.34.1

Greg Kroah-Hartman

author maintainer

2022-01-31 11:17 UTC #141 lore raw

PATCH 141/171 net/smc: Transitional solution for clcsock race issue

Link https://lore.kernel.org/lkml/[email protected]/T/ open here

From: Wen Gu <[email protected]>

[ Upstream commit c0bf3d8a943b6f2e912b7c1de03e2ef28e76f760 ]

We encountered a crash in smc_setsockopt() and it is caused by accessing smc->clcsock after clcsock was released.

 BUG: kernel NULL pointer dereference, address: 0000000000000020
 #PF: supervisor read access in kernel mode
 #PF: error_code(0x0000) - not-present page
 PGD 0 P4D 0
 Oops: 0000 [#1] PREEMPT SMP PTI
 CPU: 1 PID: 50309 Comm: nginx Kdump: loaded Tainted: G E     5.16.0-rc4+ #53
 RIP: 0010:smc_setsockopt+0x59/0x280 [smc]
 Call Trace:
  <TASK>
  __sys_setsockopt+0xfc/0x190
  __x64_sys_setsockopt+0x20/0x30
  do_syscall_64+0x34/0x90
  entry_SYSCALL_64_after_hwframe+0x44/0xae
 RIP: 0033:0x7f16ba83918e
  </TASK>

This patch tries to fix it by holding clcsock_release_lock and checking whether clcsock has already been released before access.

In case that a crash of the same reason happens in smc_getsockopt() or smc_switch_to_fallback(), this patch also checkes smc->clcsock in them too. And the caller of smc_switch_to_fallback() will identify whether fallback succeeds according to the return value.

Fixes fd57770dd198 ("net/smc: wait for pending work before clcsock release_sock")

Signed-off-by Wen Gu <[email protected]>

Acked-by Karsten Graul <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

---
 net/smc/af_smc.c | 63 +++++++++++++++++++++++++++++++++++++++---------
 1 file changed, 51 insertions(+), 12 deletions(-)

net/smc/af_smc.c +51 ~~-12~~

index 07ff719f39077..34608369b426f 100644
@@ -548,12 +548,17 @@ static void smc_stat_fallback(struct smc_sock *smc)
 	mutex_unlock(&net->smc.mutex_fback_rsn);
 }
 
-static void smc_switch_to_fallback(struct smc_sock *smc, int reason_code)
+static int smc_switch_to_fallback(struct smc_sock *smc, int reason_code)
 {
 	wait_queue_head_t *smc_wait = sk_sleep(&smc->sk);
-	wait_queue_head_t *clc_wait = sk_sleep(smc->clcsock->sk);
+	wait_queue_head_t *clc_wait;
 	unsigned long flags;
 
+	mutex_lock(&smc->clcsock_release_lock);
+	if (!smc->clcsock) {
+		mutex_unlock(&smc->clcsock_release_lock);
+		return -EBADF;
+	}
 	smc->use_fallback = true;
 	smc->fallback_rsn = reason_code;
 	smc_stat_fallback(smc);

@@ -567,18 +572,30 @@ static void smc_switch_to_fallback(struct smc_sock *smc, int reason_code)
 		 * smc socket->wq, which should be removed
 		 * to clcsocket->wq during the fallback.
 		 */
+		clc_wait = sk_sleep(smc->clcsock->sk);
 		spin_lock_irqsave(&smc_wait->lock, flags);
 		spin_lock_nested(&clc_wait->lock, SINGLE_DEPTH_NESTING);
 		list_splice_init(&smc_wait->head, &clc_wait->head);
 		spin_unlock(&clc_wait->lock);
 		spin_unlock_irqrestore(&smc_wait->lock, flags);
 	}
+	mutex_unlock(&smc->clcsock_release_lock);
+	return 0;
 }
 
 /* fall back during connect */
 static int smc_connect_fallback(struct smc_sock *smc, int reason_code)
 {
-	smc_switch_to_fallback(smc, reason_code);
+	struct net *net = sock_net(&smc->sk);
+	int rc = 0;
+
+	rc = smc_switch_to_fallback(smc, reason_code);
+	if (rc) { /* fallback fails */
+		this_cpu_inc(net->smc.smc_stats->clnt_hshake_err_cnt);
+		if (smc->sk.sk_state == SMC_INIT)
+			sock_put(&smc->sk); /* passive closing */
+		return rc;
+	}
 	smc_copy_sock_settings_to_clc(smc);
 	smc->connect_nonblock = 0;
 	if (smc->sk.sk_state == SMC_INIT)

@@ -1384,11 +1401,12 @@ static void smc_listen_decline(struct smc_sock *new_smc, int reason_code,
 {
 	/* RDMA setup failed, switch back to TCP */
 	smc_conn_abort(new_smc, local_first);
-	if (reason_code < 0) { /* error, no fallback possible */
+	if (reason_code < 0 ||
+	    smc_switch_to_fallback(new_smc, reason_code)) {
+		/* error, no fallback possible */
 		smc_listen_out_err(new_smc);
 		return;
 	}
-	smc_switch_to_fallback(new_smc, reason_code);
 	if (reason_code && reason_code != SMC_CLC_DECL_PEERDECL) {
 		if (smc_clc_send_decline(new_smc, reason_code, version) < 0) {
 			smc_listen_out_err(new_smc);

@@ -1761,8 +1779,11 @@ static void smc_listen_work(struct work_struct *work)
 
 	/* check if peer is smc capable */
 	if (!tcp_sk(newclcsock->sk)->syn_smc) {
-		smc_switch_to_fallback(new_smc, SMC_CLC_DECL_PEERNOSMC);
-		smc_listen_out_connected(new_smc);
+		rc = smc_switch_to_fallback(new_smc, SMC_CLC_DECL_PEERNOSMC);
+		if (rc)
+			smc_listen_out_err(new_smc);
+		else
+			smc_listen_out_connected(new_smc);
 		return;
 	}

@@ -2048,7 +2069,9 @@ static int smc_sendmsg(struct socket *sock, struct msghdr *msg, size_t len)
 
 	if (msg->msg_flags & MSG_FASTOPEN) {
 		if (sk->sk_state == SMC_INIT && !smc->connect_nonblock) {
-			smc_switch_to_fallback(smc, SMC_CLC_DECL_OPTUNSUPP);
+			rc = smc_switch_to_fallback(smc, SMC_CLC_DECL_OPTUNSUPP);
+			if (rc)
+				goto out;
 		} else {
 			rc = -EINVAL;
 			goto out;

@@ -2241,6 +2264,11 @@ static int smc_setsockopt(struct socket *sock, int level, int optname,
 	/* generic setsockopts reaching us here always apply to the
 	 * CLC socket
 	 */
+	mutex_lock(&smc->clcsock_release_lock);
+	if (!smc->clcsock) {
+		mutex_unlock(&smc->clcsock_release_lock);
+		return -EBADF;
+	}
 	if (unlikely(!smc->clcsock->ops->setsockopt))
 		rc = -EOPNOTSUPP;
 	else

@@ -2250,6 +2278,7 @@ static int smc_setsockopt(struct socket *sock, int level, int optname,
 		sk->sk_err = smc->clcsock->sk->sk_err;
 		sk_error_report(sk);
 	}
+	mutex_unlock(&smc->clcsock_release_lock);
 
 	if (optlen < sizeof(int))
 		return -EINVAL;

@@ -2266,7 +2295,7 @@ static int smc_setsockopt(struct socket *sock, int level, int optname,
 	case TCP_FASTOPEN_NO_COOKIE:
 		/* option not supported by SMC */
 		if (sk->sk_state == SMC_INIT && !smc->connect_nonblock) {
-			smc_switch_to_fallback(smc, SMC_CLC_DECL_OPTUNSUPP);
+			rc = smc_switch_to_fallback(smc, SMC_CLC_DECL_OPTUNSUPP);
 		} else {
 			rc = -EINVAL;
 		}

@@ -2309,13 +2338,23 @@ static int smc_getsockopt(struct socket *sock, int level, int optname,
 			  char __user *optval, int __user *optlen)
 {
 	struct smc_sock *smc;
+	int rc;
 
 	smc = smc_sk(sock->sk);
+	mutex_lock(&smc->clcsock_release_lock);
+	if (!smc->clcsock) {
+		mutex_unlock(&smc->clcsock_release_lock);
+		return -EBADF;
+	}
 	/* socket options apply to the CLC socket */
-	if (unlikely(!smc->clcsock->ops->getsockopt))
+	if (unlikely(!smc->clcsock->ops->getsockopt)) {
+		mutex_unlock(&smc->clcsock_release_lock);
 		return -EOPNOTSUPP;
-	return smc->clcsock->ops->getsockopt(smc->clcsock, level, optname,
-					     optval, optlen);
+	}
+	rc = smc->clcsock->ops->getsockopt(smc->clcsock, level, optname,
+					   optval, optlen);
+	mutex_unlock(&smc->clcsock_release_lock);
+	return rc;
 }
 
 static int smc_ioctl(struct socket *sock, unsigned int cmd,

Signature · 1 line

2.34.1

Greg Kroah-Hartman

author maintainer

2022-01-31 11:24 UTC #142 lore raw

PATCH 142/171 video: hyperv_fb: Fix validation of screen resolution

From: Michael Kelley <[email protected]>

[ Upstream commit 9ff5549b1d1d3c3a9d71220d44bd246586160f1d ]

In the WIN10 version of the Synthetic Video protocol with Hyper-V, Hyper-V reports a list of supported resolutions as part of the protocol negotiation. The driver calculates the maximum width and height from the list of resolutions, and uses those maximums to validate any screen resolution specified in the video= option on the kernel boot line.

This method of validation is incorrect. For example, the list of supported resolutions could contain 1600x1200 and 1920x1080, both of which fit in an 8 Mbyte frame buffer. But calculating the max width and height yields 1920 and 1200, and 1920x1200 resolution does not fit in an 8 Mbyte frame buffer. Unfortunately, this resolution is accepted, causing a kernel fault when the driver accesses memory outside the frame buffer.

Instead, validate the specified screen resolution by calculating its size, and comparing against the frame buffer size. Delete the code for calculating the max width and height from the list of resolutions, since these max values have no use. Also add the frame buffer size to the info message to aid in understanding why a resolution might be rejected.

Fixes 67e7cdb4829d ("video: hyperv: hyperv_fb: Obtain screen resolution from Hyper-V host")

Signed-off-by Michael Kelley <[email protected]>

Reviewed-by Haiyang Zhang <[email protected]>

Acked-by Helge Deller <[email protected]>

Link https://lore.kernel.org/r/[email protected] open here

Signed-off-by Wei Liu <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

---
 drivers/video/fbdev/hyperv_fb.c | 16 +++-------------
 1 file changed, 3 insertions(+), 13 deletions(-)

drivers/video/fbdev/hyperv_fb.c +3 ~~-13~~

index 23999df527393..c8e0ea27caf1d 100644
@@ -287,8 +287,6 @@ struct hvfb_par {
 
 static uint screen_width = HVFB_WIDTH;
 static uint screen_height = HVFB_HEIGHT;
-static uint screen_width_max = HVFB_WIDTH;
-static uint screen_height_max = HVFB_HEIGHT;
 static uint screen_depth;
 static uint screen_fb_size;
 static uint dio_fb_size; /* FB size for deferred IO */

@@ -582,7 +580,6 @@ static int synthvid_get_supported_resolution(struct hv_device *hdev)
 	int ret = 0;
 	unsigned long t;
 	u8 index;
-	int i;
 
 	memset(msg, 0, sizeof(struct synthvid_msg));
 	msg->vid_hdr.type = SYNTHVID_RESOLUTION_REQUEST;

@@ -613,13 +610,6 @@ static int synthvid_get_supported_resolution(struct hv_device *hdev)
 		goto out;
 	}
 
-	for (i = 0; i < msg->resolution_resp.resolution_count; i++) {
-		screen_width_max = max_t(unsigned int, screen_width_max,
-		    msg->resolution_resp.supported_resolution[i].width);
-		screen_height_max = max_t(unsigned int, screen_height_max,
-		    msg->resolution_resp.supported_resolution[i].height);
-	}
-
 	screen_width =
 		msg->resolution_resp.supported_resolution[index].width;
 	screen_height =

@@ -941,7 +931,7 @@ static void hvfb_get_option(struct fb_info *info)
 
 	if (x < HVFB_WIDTH_MIN || y < HVFB_HEIGHT_MIN ||
 	    (synthvid_ver_ge(par->synthvid_version, SYNTHVID_VERSION_WIN10) &&
-	    (x > screen_width_max || y > screen_height_max)) ||
+	    (x * y * screen_depth / 8 > screen_fb_size)) ||
 	    (par->synthvid_version == SYNTHVID_VERSION_WIN8 &&
 	     x * y * screen_depth / 8 > SYNTHVID_FB_SIZE_WIN8) ||
 	    (par->synthvid_version == SYNTHVID_VERSION_WIN7 &&

@@ -1194,8 +1184,8 @@ static int hvfb_probe(struct hv_device *hdev,
 	}
 
 	hvfb_get_option(info);
-	pr_info("Screen resolution: %dx%d, Color depth: %d\n",
-		screen_width, screen_height, screen_depth);
+	pr_info("Screen resolution: %dx%d, Color depth: %d, Frame buffer size: %d\n",
+		screen_width, screen_height, screen_depth, screen_fb_size);
 
 	ret = hvfb_getmem(hdev, info);
 	if (ret) {

Signature · 1 line

2.34.1

Greg Kroah-Hartman

author maintainer

2022-01-31 11:24 UTC #143 lore raw

PATCH 143/171 can: tcan4x5x: regmap: fix max register value

Link https://lore.kernel.org/all/[email protected] open here

From: Marc Kleine-Budde <[email protected]>

[ Upstream commit e59986de5ff701494e14c722b78b6e6d513e0ab5 ]

The MRAM of the tcan4x5x has a size of 2K and starts at 0x8000. There are no further registers in the tcan4x5x making 0x87fc the biggest addressable register.

This patch fixes the max register value of the regmap config from 0x8ffc to 0x87fc.

Fixes 6e1caaf8ed22 ("can: tcan4x5x: fix max register value")

Signed-off-by Marc Kleine-Budde <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

---
 drivers/net/can/m_can/tcan4x5x-regmap.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

drivers/net/can/m_can/tcan4x5x-regmap.c +1 -1

index ca80dbaf7a3f5..26e212b8ca7a6 100644
@@ -12,7 +12,7 @@
 #define TCAN4X5X_SPI_INSTRUCTION_WRITE (0x61 << 24)
 #define TCAN4X5X_SPI_INSTRUCTION_READ (0x41 << 24)
 
-#define TCAN4X5X_MAX_REGISTER 0x8ffc
+#define TCAN4X5X_MAX_REGISTER 0x87fc
 
 static int tcan4x5x_regmap_gather_write(void *context,
 					const void *reg, size_t reg_len,

Signature · 1 line

2.34.1

Greg Kroah-Hartman

author maintainer

2022-01-31 11:24 UTC #144 lore raw

PATCH 144/171 drm/msm/hdmi: Fix missing put_device() call in msm_hdmi_get_phy

From: Miaoqian Lin <[email protected]>

[ Upstream commit 774fe0cd838d1b1419d41ab4ea0613c80d4ecbd7 ]

The reference taken by 'of_find_device_by_node()' must be released when not needed anymore.
Add the corresponding 'put_device()' in the error handling path.

Fixes e00012b256d4 ("drm/msm/hdmi: Make HDMI core get its PHY")

Signed-off-by Miaoqian Lin <[email protected]>

Link https://lore.kernel.org/r/[email protected] open here

Signed-off-by Sasha Levin <[email protected]>

---
 drivers/gpu/drm/msm/hdmi/hdmi.c | 7 ++++++-
 1 file changed, 6 insertions(+), 1 deletion(-)

drivers/gpu/drm/msm/hdmi/hdmi.c +6 -1

index 737453b6e5966..94f948ef279d1 100644
@@ -97,10 +97,15 @@ static int msm_hdmi_get_phy(struct hdmi *hdmi)
 
 	of_node_put(phy_node);
 
-	if (!phy_pdev || !hdmi->phy) {
+	if (!phy_pdev) {
 		DRM_DEV_ERROR(&pdev->dev, "phy driver is not ready\n");
 		return -EPROBE_DEFER;
 	}
+	if (!hdmi->phy) {
+		DRM_DEV_ERROR(&pdev->dev, "phy driver is not ready\n");
+		put_device(&phy_pdev->dev);
+		return -EPROBE_DEFER;
+	}
 
 	hdmi->phy_dev = get_device(&phy_pdev->dev);

Signature · 1 line

2.34.1

Greg Kroah-Hartman

author maintainer

2022-01-31 11:15 UTC #145 lore raw

PATCH 145/171 drm/msm/dpu: invalid parameter check in dpu_setup_dspp_pcc

From: José Expósito <[email protected]>

[ Upstream commit 170b22234d5495f5e0844246e23f004639ee89ba ]

The function performs a check on the "ctx" input parameter, however, it is used before the check.

Initialize the "base" variable after the sanity check to avoid a possible NULL pointer dereference.

Fixes 4259ff7ae509e ("drm/msm/dpu: add support for pcc color block in dpu driver")

Addresses-Coverity-ID: 1493866 ("Null pointer dereference")

Signed-off-by José Expósito <[email protected]>

Link https://lore.kernel.org/r/[email protected] open here

Signed-off-by Sasha Levin <[email protected]>

---
 drivers/gpu/drm/msm/disp/dpu1/dpu_hw_dspp.c | 11 +++++++++--
 1 file changed, 9 insertions(+), 2 deletions(-)

drivers/gpu/drm/msm/disp/dpu1/dpu_hw_dspp.c +9 -2

index a98e964c3b6fa..355894a3b48c3 100644
@@ -26,9 +26,16 @@ static void dpu_setup_dspp_pcc(struct dpu_hw_dspp *ctx,
 		struct dpu_hw_pcc_cfg *cfg)
 {
 
-	u32 base = ctx->cap->sblk->pcc.base;
+	u32 base;
 
-	if (!ctx || !base) {
+	if (!ctx) {
+		DRM_ERROR("invalid ctx %pK\n", ctx);
+		return;
+	}
+
+	base = ctx->cap->sblk->pcc.base;
+
+	if (!base) {
 		DRM_ERROR("invalid ctx %pK pcc base 0x%x\n", ctx, base);
 		return;
 	}

Signature · 1 line

2.34.1

Greg Kroah-Hartman

author maintainer

2022-01-31 11:15 UTC #146 lore raw

PATCH 146/171 drm/msm/a6xx: Add missing suspend_count increment

From: Rob Clark <[email protected]>

[ Upstream commit 860a7b2a87b7c743154824d0597b6c3eb3b53154 ]

Reported-by Danylo Piliaiev <[email protected]>

Fixes 3ab1c5cc3939 ("drm/msm: Add param for userspace to query suspend count")

Signed-off-by Rob Clark <[email protected]>

Link https://lore.kernel.org/r/[email protected] open here

Signed-off-by Sasha Levin <[email protected]>

---
 drivers/gpu/drm/msm/adreno/a6xx_gpu.c | 2 ++
 1 file changed, 2 insertions(+)

drivers/gpu/drm/msm/adreno/a6xx_gpu.c +2 -0

index 723074aae5b63..b681c45520bbd 100644
@@ -1557,6 +1557,8 @@ static int a6xx_pm_suspend(struct msm_gpu *gpu)
 		for (i = 0; i < gpu->nr_rings; i++)
 			a6xx_gpu->shadow[i] = 0;
 
+	gpu->suspend_count++;
+
 	return 0;
 }

Signature · 1 line

2.34.1

Greg Kroah-Hartman

author maintainer

2022-01-31 11:24 UTC #147 lore raw

PATCH 147/171 yam: fix a memory leak in yam_siocdevprivate()

From: Hangyu Hua <[email protected]>

[ Upstream commit 29eb31542787e1019208a2e1047bb7c76c069536 ]

ym needs to be free when ym->cmd != SIOCYAMSMCS.

Fixes 0781168e23a2 ("yam: fix a missing-check bug")

Signed-off-by Hangyu Hua <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

---
 drivers/net/hamradio/yam.c | 4 +---
 1 file changed, 1 insertion(+), 3 deletions(-)

drivers/net/hamradio/yam.c +1 -3

index 6ddacbdb224ba..528d57a435394 100644
@@ -950,9 +950,7 @@ static int yam_siocdevprivate(struct net_device *dev, struct ifreq *ifr, void __
 		ym = memdup_user(data, sizeof(struct yamdrv_ioctl_mcs));
 		if (IS_ERR(ym))
 			return PTR_ERR(ym);
-		if (ym->cmd != SIOCYAMSMCS)
-			return -EINVAL;
-		if (ym->bitrate > YAM_MAXBITRATE) {
+		if (ym->cmd != SIOCYAMSMCS || ym->bitrate > YAM_MAXBITRATE) {
 			kfree(ym);
 			return -EINVAL;
 		}

Signature · 1 line

2.34.1

Greg Kroah-Hartman

author maintainer

2022-01-31 11:15 UTC #148 lore raw

PATCH 148/171 net: cpsw: Properly initialise struct page_pool_params

From: Toke Høiland-Jørgensen <[email protected]>

[ Upstream commit c63003e3d99761afb280add3b30de1cf30fa522b ]

The cpsw driver didn't properly initialise the struct page_pool_params before calling page_pool_create(), which leads to crashes after the struct has been expanded with new parameters.

The second Fixes tag below is where the buggy code was introduced, but because the code was moved around this patch will only apply on top of the commit in the first Fixes tag.

Fixes c5013ac1dd0e ("net: ethernet: ti: cpsw: move set of common functions in cpsw_priv")

Fixes 9ed4050c0d75 ("net: ethernet: ti: cpsw: add XDP support")

Reported-by Colin Foster <[email protected]>

Signed-off-by Toke Høiland-Jørgensen <[email protected]>

Tested-by Colin Foster <[email protected]>

Acked-by Jesper Dangaard Brouer <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

---
 drivers/net/ethernet/ti/cpsw_priv.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

drivers/net/ethernet/ti/cpsw_priv.c +1 -1

index 6bb5ac51d23c3..f8e591d69d2cb 100644
@@ -1144,7 +1144,7 @@ int cpsw_fill_rx_channels(struct cpsw_priv *priv)
 static struct page_pool *cpsw_create_page_pool(struct cpsw_common *cpsw,
 					       int size)
 {
-	struct page_pool_params pp_params;
+	struct page_pool_params pp_params = {};
 	struct page_pool *pool;
 
 	pp_params.order = 0;

Signature · 1 line

2.34.1

Greg Kroah-Hartman

author maintainer

2022-01-31 11:15 UTC #149 lore raw

PATCH 149/171 net: hns3: handle empty unknown interrupt for VF

From: Yufeng Mo <[email protected]>

[ Upstream commit 2f61353cd2f789a4229b6f5c1c24a40a613357bb ]

Since some interrupt states may be cleared by hardware, the driver may receive an empty interrupt. Currently, the VF driver directly disables the vector0 interrupt in this case. As a result, the VF is unavailable. Therefore, the vector0 interrupt should be enabled in this case.

Fixes b90fcc5bd904 ("net: hns3: add reset handling for VF when doing Core/Global/IMP reset")

Signed-off-by Yufeng Mo <[email protected]>

Signed-off-by Guangbin Huang <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

---
 drivers/net/ethernet/hisilicon/hns3/hns3vf/hclgevf_main.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

drivers/net/ethernet/hisilicon/hns3/hns3vf/hclgevf_main.c +1 -2

index fee7d9e79f8c3..417a08d600b83 100644
@@ -2496,8 +2496,7 @@ static irqreturn_t hclgevf_misc_irq_handle(int irq, void *data)
 		break;
 	}
 
-	if (event_cause != HCLGEVF_VECTOR0_EVENT_OTHER)
-		hclgevf_enable_vector(&hdev->misc_vector, true);
+	hclgevf_enable_vector(&hdev->misc_vector, true);
 
 	return IRQ_HANDLED;
 }

Signature · 1 line

2.34.1

Greg Kroah-Hartman

author maintainer

2022-01-31 11:24 UTC #150 lore raw

PATCH 150/171 sch_htb: Fail on unsupported parameters when offload is requested

From: Maxim Mikityanskiy <[email protected]>

[ Upstream commit 429c3be8a5e2695b5b92a6a12361eb89eb185495 ]

The current implementation of HTB offload doesn't support some parameters. Instead of ignoring them, actively return the EINVAL error when they are set to non-defaults.

As this patch goes to stable, the driver API is not changed here. If future drivers support more offload parameters, the checks can be moved to the driver side.

Note that the buffer and cbuffer parameters are also not supported, but the tc userspace tool assigns some default values derived from rate and ceil, and identifying these defaults in sch_htb would be unreliable, so they are still ignored.

Fixes d03b195b5aa0 ("sch_htb: Hierarchical QoS hardware offload")

Reported-by Jakub Kicinski <[email protected]>

Signed-off-by Maxim Mikityanskiy <[email protected]>

Reviewed-by Tariq Toukan <[email protected]>

Link https://lore.kernel.org/r/[email protected] open here

Signed-off-by Sasha Levin <[email protected]>

---
 net/sched/sch_htb.c | 20 ++++++++++++++++++++
 1 file changed, 20 insertions(+)

net/sched/sch_htb.c +20 -0

index 5067a6e5d4fde..5cbc32fee8674 100644
@@ -1803,6 +1803,26 @@ static int htb_change_class(struct Qdisc *sch, u32 classid,
 	if (!hopt->rate.rate || !hopt->ceil.rate)
 		goto failure;
 
+	if (q->offload) {
+		/* Options not supported by the offload. */
+		if (hopt->rate.overhead || hopt->ceil.overhead) {
+			NL_SET_ERR_MSG(extack, "HTB offload doesn't support the overhead parameter");
+			goto failure;
+		}
+		if (hopt->rate.mpu || hopt->ceil.mpu) {
+			NL_SET_ERR_MSG(extack, "HTB offload doesn't support the mpu parameter");
+			goto failure;
+		}
+		if (hopt->quantum) {
+			NL_SET_ERR_MSG(extack, "HTB offload doesn't support the quantum parameter");
+			goto failure;
+		}
+		if (hopt->prio) {
+			NL_SET_ERR_MSG(extack, "HTB offload doesn't support the prio parameter");
+			goto failure;
+		}
+	}
+
 	/* Keeping backward compatible with rate_table based iproute2 tc */
 	if (hopt->rate.linklayer == TC_LINKLAYER_UNAWARE)
 		qdisc_put_rtab(qdisc_get_rtab(&hopt->rate, tb[TCA_HTB_RTAB],

Signature · 1 line

2.34.1

Greg Kroah-Hartman

author maintainer

2022-01-31 11:15 UTC #151 lore raw

PATCH 151/171 Revert "drm/ast: Support 1600x900 with 108MHz PCLK"

Link https://patchwork.freedesktop.org/patch/msgid/[email protected]

From: Dave Airlie <[email protected]>

[ Upstream commit 76cea3d95513fe40000d06a3719c4bb6b53275e2 ]

This reverts commit 9bb7b689274b67ecb3641e399e76f84adc627df1.

This caused a regression reported to Red Hat.

Fixes 9bb7b689274b ("drm/ast: Support 1600x900 with 108MHz PCLK")

Signed-off-by Dave Airlie <[email protected]>

Signed-off-by Thomas Zimmermann <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

---
 drivers/gpu/drm/ast/ast_tables.h | 2 --
 1 file changed, 2 deletions(-)

drivers/gpu/drm/ast/ast_tables.h +0 -2

index d9eb353a4bf09..dbe1cc620f6e6 100644
@@ -282,8 +282,6 @@ static const struct ast_vbios_enhtable res_1360x768[] = {
 };
 
 static const struct ast_vbios_enhtable res_1600x900[] = {
-	{1800, 1600, 24, 80, 1000,  900, 1, 3, VCLK108,		/* 60Hz */
-	 (SyncPP | Charx8Dot | LineCompareOff | WideScreenMode | NewModeInfo), 60, 3, 0x3A },
 	{1760, 1600, 48, 32, 926, 900, 3, 5, VCLK97_75,		/* 60Hz CVT RB */
 	 (SyncNP | Charx8Dot | LineCompareOff | WideScreenMode | NewModeInfo |
 	  AST2500PreCatchCRT), 60, 1, 0x3A },

Signature · 1 line

2.34.1

Greg Kroah-Hartman

author maintainer

2022-01-31 11:26 UTC #152 lore raw

PATCH 152/171 KVM: selftests: Dont skip L2s VMCALL in SMM test for SVM guest

From: Sean Christopherson <[email protected]>

[ Upstream commit 4cf3d3ebe8794c449af3e0e8c1d790c97e461d20 ]

Don't skip the vmcall() in l2_guest_code() prior to re-entering L2, doing so will result in L2 running to completion, popping '0' off the stack for RET, jumping to address '0', and ultimately dying with a triple fault shutdown.

It's not at all obvious why the test re-enters L2 and re-executes VMCALL, but presumably it serves a purpose. The VMX path doesn't skip vmcall(), and the test can't possibly have passed on SVM, so just do what VMX does.

Fixes d951b2210c1a ("KVM: selftests: smm_test: Test SMM enter from L2")

Cc Maxim Levitsky <[email protected]>

Signed-off-by Sean Christopherson <[email protected]>

Message-Id: <[email protected]>

Reviewed-by Vitaly Kuznetsov <[email protected]>

Tested-by Vitaly Kuznetsov <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

---
 tools/testing/selftests/kvm/x86_64/smm_test.c | 1 -
 1 file changed, 1 deletion(-)

tools/testing/selftests/kvm/x86_64/smm_test.c +0 -1

index d0fe2fdce58c4..db2a17559c3d5 100644
@@ -105,7 +105,6 @@ static void guest_code(void *arg)
 
 		if (cpu_has_svm()) {
 			run_guest(svm->vmcb, svm->vmcb_gpa);
-			svm->vmcb->save.rip += 3;
 			run_guest(svm->vmcb, svm->vmcb_gpa);
 		} else {
 			vmlaunch();

Signature · 1 line

2.34.1

Greg Kroah-Hartman

author maintainer

2022-01-31 11:15 UTC #153 lore raw

PATCH 153/171 ceph: put the requests/sessions when it fails to alloc memory

From: Xiubo Li <[email protected]>

[ Upstream commit 89d43d0551a848e70e63d9ba11534aaeabc82443 ]

When failing to allocate the sessions memory we should make sure the req1 and req2 and the sessions get put. And also in case the max_sessions decreased so when kreallocate the new memory some sessions maybe missed being put.

And if the max_sessions is 0 krealloc will return ZERO_SIZE_PTR, which will lead to a distinct access fault.

URL: https://tracker.ceph.com/issues/53819

Fixes e1a4541ec0b9 ("ceph: flush the mdlog before waiting on unsafe reqs")

Signed-off-by Xiubo Li <[email protected]>

Reviewed-by Venky Shankar <[email protected]>

Reviewed-by Jeff Layton <[email protected]>

Signed-off-by Ilya Dryomov <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

---
 fs/ceph/caps.c | 55 +++++++++++++++++++++++++++++++++-----------------
 1 file changed, 37 insertions(+), 18 deletions(-)

fs/ceph/caps.c +37 ~~-18~~

index 8be4da2e2b826..09900a9015ea6 100644
@@ -2217,6 +2217,7 @@ static int unsafe_request_wait(struct inode *inode)
 	struct ceph_mds_client *mdsc = ceph_sb_to_client(inode->i_sb)->mdsc;
 	struct ceph_inode_info *ci = ceph_inode(inode);
 	struct ceph_mds_request *req1 = NULL, *req2 = NULL;
+	unsigned int max_sessions;
 	int ret, err = 0;
 
 	spin_lock(&ci->i_unsafe_lock);

@@ -2234,37 +2235,45 @@ static int unsafe_request_wait(struct inode *inode)
 	}
 	spin_unlock(&ci->i_unsafe_lock);
 
+	/*
+	 * The mdsc->max_sessions is unlikely to be changed
+	 * mostly, here we will retry it by reallocating the
+	 * sessions array memory to get rid of the mdsc->mutex
+	 * lock.
+	 */
+retry:
+	max_sessions = mdsc->max_sessions;
+
 	/*
 	 * Trigger to flush the journal logs in all the relevant MDSes
 	 * manually, or in the worst case we must wait at most 5 seconds
 	 * to wait the journal logs to be flushed by the MDSes periodically.
 	 */
-	if (req1 || req2) {
+	if ((req1 || req2) && likely(max_sessions)) {
 		struct ceph_mds_session **sessions = NULL;
 		struct ceph_mds_session *s;
 		struct ceph_mds_request *req;
-		unsigned int max;
 		int i;
 
-		/*
-		 * The mdsc->max_sessions is unlikely to be changed
-		 * mostly, here we will retry it by reallocating the
-		 * sessions arrary memory to get rid of the mdsc->mutex
-		 * lock.
-		 */
-retry:
-		max = mdsc->max_sessions;
-		sessions = krealloc(sessions, max * sizeof(s), __GFP_ZERO);
-		if (!sessions)
-			return -ENOMEM;
+		sessions = kzalloc(max_sessions * sizeof(s), GFP_KERNEL);
+		if (!sessions) {
+			err = -ENOMEM;
+			goto out;
+		}
 
 		spin_lock(&ci->i_unsafe_lock);
 		if (req1) {
 			list_for_each_entry(req, &ci->i_unsafe_dirops,
 					    r_unsafe_dir_item) {
 				s = req->r_session;
-				if (unlikely(s->s_mds >= max)) {
+				if (unlikely(s->s_mds >= max_sessions)) {
 					spin_unlock(&ci->i_unsafe_lock);
+					for (i = 0; i < max_sessions; i++) {
+						s = sessions[i];
+						if (s)
+							ceph_put_mds_session(s);
+					}
+					kfree(sessions);
 					goto retry;
 				}
 				if (!sessions[s->s_mds]) {

@@ -2277,8 +2286,14 @@ retry:
 			list_for_each_entry(req, &ci->i_unsafe_iops,
 					    r_unsafe_target_item) {
 				s = req->r_session;
-				if (unlikely(s->s_mds >= max)) {
+				if (unlikely(s->s_mds >= max_sessions)) {
 					spin_unlock(&ci->i_unsafe_lock);
+					for (i = 0; i < max_sessions; i++) {
+						s = sessions[i];
+						if (s)
+							ceph_put_mds_session(s);
+					}
+					kfree(sessions);
 					goto retry;
 				}
 				if (!sessions[s->s_mds]) {

@@ -2299,7 +2314,7 @@ retry:
 		spin_unlock(&ci->i_ceph_lock);
 
 		/* send flush mdlog request to MDSes */
-		for (i = 0; i < max; i++) {
+		for (i = 0; i < max_sessions; i++) {
 			s = sessions[i];
 			if (s) {
 				send_flush_mdlog(s);

@@ -2316,15 +2331,19 @@ retry:
 					ceph_timeout_jiffies(req1->r_timeout));
 		if (ret)
 			err = -EIO;
-		ceph_mdsc_put_request(req1);
 	}
 	if (req2) {
 		ret = !wait_for_completion_timeout(&req2->r_safe_completion,
 					ceph_timeout_jiffies(req2->r_timeout));
 		if (ret)
 			err = -EIO;
-		ceph_mdsc_put_request(req2);
 	}
+
+out:
+	if (req1)
+		ceph_mdsc_put_request(req1);
+	if (req2)
+		ceph_mdsc_put_request(req2);
 	return err;
 }

Signature · 1 line

2.34.1

Greg Kroah-Hartman

author maintainer

2022-01-31 11:24 UTC #154 lore raw

PATCH 154/171 gve: Fix GFP flags when allocing pages

From: Catherine Sullivan <[email protected]>

[ Upstream commit a92f7a6feeb3884c69c1c7c1f13bccecb2228ad0 ]

Use GFP_ATOMIC when allocating pages out of the hotpath, continue to use GFP_KERNEL when allocating pages during setup.

GFP_KERNEL will allow blocking which allows it to succeed more often in a low memory enviornment but in the hotpath we do not want to allow the allocation to block.

Fixes f5cedc84a30d2 ("gve: Add transmit and receive support")

Signed-off-by Catherine Sullivan <[email protected]>

Signed-off-by David Awogbemila <[email protected]>

Link https://lore.kernel.org/r/[email protected] open here

Signed-off-by Sasha Levin <[email protected]>

---
 drivers/net/ethernet/google/gve/gve.h        | 2 +-
 drivers/net/ethernet/google/gve/gve_main.c   | 6 +++---
 drivers/net/ethernet/google/gve/gve_rx.c     | 3 ++-
 drivers/net/ethernet/google/gve/gve_rx_dqo.c | 2 +-
 4 files changed, 7 insertions(+), 6 deletions(-)

drivers/net/ethernet/google/gve/gve.h +1 -1

index c1d4042671f9f..b1273dce4795b 100644
@@ -815,7 +815,7 @@ static inline bool gve_is_gqi(struct gve_priv *priv)
 /* buffers */
 int gve_alloc_page(struct gve_priv *priv, struct device *dev,
 		   struct page **page, dma_addr_t *dma,
-		   enum dma_data_direction);
+		   enum dma_data_direction, gfp_t gfp_flags);
 void gve_free_page(struct device *dev, struct page *page, dma_addr_t dma,
 		   enum dma_data_direction);
 /* tx handling */

drivers/net/ethernet/google/gve/gve_main.c +3 -3

index 959352fceead7..68552848d3888 100644
@@ -746,9 +746,9 @@ static void gve_free_rings(struct gve_priv *priv)
 
 int gve_alloc_page(struct gve_priv *priv, struct device *dev,
 		   struct page **page, dma_addr_t *dma,
-		   enum dma_data_direction dir)
+		   enum dma_data_direction dir, gfp_t gfp_flags)
 {
-	*page = alloc_page(GFP_KERNEL);
+	*page = alloc_page(gfp_flags);
 	if (!*page) {
 		priv->page_alloc_fail++;
 		return -ENOMEM;

@@ -792,7 +792,7 @@ static int gve_alloc_queue_page_list(struct gve_priv *priv, u32 id,
 	for (i = 0; i < pages; i++) {
 		err = gve_alloc_page(priv, &priv->pdev->dev, &qpl->pages[i],
 				     &qpl->page_buses[i],
-				     gve_qpl_dma_dir(priv, id));
+				     gve_qpl_dma_dir(priv, id), GFP_KERNEL);
 		/* caller handles clean up */
 		if (err)
 			return -ENOMEM;

drivers/net/ethernet/google/gve/gve_rx.c +2 -1

index 16169f291ad9f..629d8ed08fc61 100644
@@ -79,7 +79,8 @@ static int gve_rx_alloc_buffer(struct gve_priv *priv, struct device *dev,
 	dma_addr_t dma;
 	int err;
 
-	err = gve_alloc_page(priv, dev, &page, &dma, DMA_FROM_DEVICE);
+	err = gve_alloc_page(priv, dev, &page, &dma, DMA_FROM_DEVICE,
+			     GFP_ATOMIC);
 	if (err)
 		return err;

drivers/net/ethernet/google/gve/gve_rx_dqo.c +1 -1

index 8500621b2cd41..7b18b4fd9e548 100644
@@ -157,7 +157,7 @@ static int gve_alloc_page_dqo(struct gve_priv *priv,
 	int err;
 
 	err = gve_alloc_page(priv, &priv->pdev->dev, &buf_state->page_info.page,
-			     &buf_state->addr, DMA_FROM_DEVICE);
+			     &buf_state->addr, DMA_FROM_DEVICE, GFP_KERNEL);
 	if (err)
 		return err;

Signature · 1 line

2.34.1

Greg Kroah-Hartman

author maintainer

2022-01-31 11:25 UTC #155 lore raw

PATCH 155/171 Revert "ipv6: Honor all IPv6 PIO Valid Lifetime values"

From: Guillaume Nault <[email protected]>

[ Upstream commit 36268983e90316b37000a005642af42234dabb36 ]

This reverts commit b75326c201242de9495ff98e5d5cff41d7fc0d9d.

This commit breaks Linux compatibility with USGv6 tests. The RFC this commit was based on is actually an expired draft: no published RFC currently allows the new behaviour it introduced.

Without full IETF endorsement, the flash renumbering scenario this patch was supposed to enable is never going to work, as other IPv6 equipements on the same LAN will keep the 2 hours limit.

Fixes b75326c20124 ("ipv6: Honor all IPv6 PIO Valid Lifetime values")

Signed-off-by Guillaume Nault <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

---
 include/net/addrconf.h |  2 ++
 net/ipv6/addrconf.c    | 27 ++++++++++++++++++++-------
 2 files changed, 22 insertions(+), 7 deletions(-)

include/net/addrconf.h +2 -0

index 78ea3e332688f..e7ce719838b5e 100644
@@ -6,6 +6,8 @@
 #define RTR_SOLICITATION_INTERVAL	(4*HZ)
 #define RTR_SOLICITATION_MAX_INTERVAL	(3600*HZ)	/* 1 hour */
 
+#define MIN_VALID_LIFETIME		(2*3600)	/* 2 hours */
+
 #define TEMP_VALID_LIFETIME		(7*86400)
 #define TEMP_PREFERRED_LIFETIME		(86400)
 #define REGEN_MAX_RETRY			(3)

net/ipv6/addrconf.c +20 -7

index 846037e73723f..bf13865426340 100644
@@ -2587,7 +2587,7 @@ int addrconf_prefix_rcv_add_addr(struct net *net, struct net_device *dev,
 				 __u32 valid_lft, u32 prefered_lft)
 {
 	struct inet6_ifaddr *ifp = ipv6_get_ifaddr(net, addr, dev, 1);
-	int create = 0;
+	int create = 0, update_lft = 0;
 
 	if (!ifp && valid_lft) {
 		int max_addresses = in6_dev->cnf.max_addresses;

@@ -2631,19 +2631,32 @@ int addrconf_prefix_rcv_add_addr(struct net *net, struct net_device *dev,
 		unsigned long now;
 		u32 stored_lft;
 
-		/* Update lifetime (RFC4862 5.5.3 e)
-		 * We deviate from RFC4862 by honoring all Valid Lifetimes to
-		 * improve the reaction of SLAAC to renumbering events
-		 * (draft-gont-6man-slaac-renum-06, Section 4.2)
-		 */
+		/* update lifetime (RFC2462 5.5.3 e) */
 		spin_lock_bh(&ifp->lock);
 		now = jiffies;
 		if (ifp->valid_lft > (now - ifp->tstamp) / HZ)
 			stored_lft = ifp->valid_lft - (now - ifp->tstamp) / HZ;
 		else
 			stored_lft = 0;
-
 		if (!create && stored_lft) {
+			const u32 minimum_lft = min_t(u32,
+				stored_lft, MIN_VALID_LIFETIME);
+			valid_lft = max(valid_lft, minimum_lft);
+
+			/* RFC4862 Section 5.5.3e:
+			 * "Note that the preferred lifetime of the
+			 *  corresponding address is always reset to
+			 *  the Preferred Lifetime in the received
+			 *  Prefix Information option, regardless of
+			 *  whether the valid lifetime is also reset or
+			 *  ignored."
+			 *
+			 * So we should always update prefered_lft here.
+			 */
+			update_lft = 1;
+		}
+
+		if (update_lft) {
 			ifp->valid_lft = valid_lft;
 			ifp->prefered_lft = prefered_lft;
 			ifp->tstamp = now;

Signature · 1 line

2.34.1

Greg Kroah-Hartman

author maintainer

2022-01-31 11:24 UTC #156 lore raw

PATCH 156/171 net: bridge: vlan: fix single net device option dumping

From: Nikolay Aleksandrov <[email protected]>

[ Upstream commit dcb2c5c6ca9b9177f04abaf76e5a983d177c9414 ]

When dumping vlan options for a single net device we send the same entries infinitely because user-space expects a 0 return at the end but we keep returning skb->len and restarting the dump on retry. Fix it by returning the value from br_vlan_dump_dev() if it completed or there was an error. The only case that must return skb->len is when the dump was incomplete and needs to continue (-EMSGSIZE).

Reported-by Benjamin Poirier <[email protected]>

Fixes 8dcea187088b ("net: bridge: vlan: add rtm definitions and dump support")

Signed-off-by Nikolay Aleksandrov <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

---
 net/bridge/br_vlan.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

net/bridge/br_vlan.c +2 -1

index 19f65ab91a027..06f5caee495aa 100644
@@ -2105,7 +2105,8 @@ static int br_vlan_rtm_dump(struct sk_buff *skb, struct netlink_callback *cb)
 			goto out_err;
 		}
 		err = br_vlan_dump_dev(dev, skb, cb, dump_flags);
-		if (err && err != -EMSGSIZE)
+		/* if the dump completed without an error we return 0 here */
+		if (err != -EMSGSIZE)
 			goto out_err;
 	} else {
 		for_each_netdev_rcu(net, dev) {

Signature · 1 line

2.34.1

Greg Kroah-Hartman

author maintainer

2022-01-31 11:16 UTC #157 lore raw

PATCH 157/171 ipv4: raw: lock the socket in raw_bind()

From: Eric Dumazet <[email protected]>

[ Upstream commit 153a0d187e767c68733b8e9f46218eb1f41ab902 ]

For some reason, raw_bind() forgot to lock the socket.

BUG: KCSAN: data-race in __ip4_datagram_connect / raw_bind

write to 0xffff8881170d4308 of 4 bytes by task 5466 on cpu 0:

 raw_bind+0x1b0/0x250 net/ipv4/raw.c:739
 inet_bind+0x56/0xa0 net/ipv4/af_inet.c:443
 __sys_bind+0x14b/0x1b0 net/socket.c:1697
 __do_sys_bind net/socket.c:1708 [inline]
 __se_sys_bind net/socket.c:1706 [inline]
 __x64_sys_bind+0x3d/0x50 net/socket.c:1706
 do_syscall_x64 arch/x86/entry/common.c:50 [inline]
 do_syscall_64+0x44/0xd0 arch/x86/entry/common.c:80
 entry_SYSCALL_64_after_hwframe+0x44/0xae

read to 0xffff8881170d4308 of 4 bytes by task 5468 on cpu 1:

 __ip4_datagram_connect+0xb7/0x7b0 net/ipv4/datagram.c:39
 ip4_datagram_connect+0x2a/0x40 net/ipv4/datagram.c:89
 inet_dgram_connect+0x107/0x190 net/ipv4/af_inet.c:576
 __sys_connect_file net/socket.c:1900 [inline]
 __sys_connect+0x197/0x1b0 net/socket.c:1917
 __do_sys_connect net/socket.c:1927 [inline]
 __se_sys_connect net/socket.c:1924 [inline]
 __x64_sys_connect+0x3d/0x50 net/socket.c:1924
 do_syscall_x64 arch/x86/entry/common.c:50 [inline]
 do_syscall_64+0x44/0xd0 arch/x86/entry/common.c:80
 entry_SYSCALL_64_after_hwframe+0x44/0xae

value changed: 0x00000000 -> 0x0003007f

Reported by Kernel Concurrency Sanitizer on:

CPU: 1 PID: 5468 Comm: syz-executor.5 Not tainted 5.17.0-rc1-syzkaller #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011

Fixes 1da177e4c3f4 ("Linux-2.6.12-rc2")

Reported-by syzbot <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

---
 net/ipv4/raw.c | 5 ++++-
 1 file changed, 4 insertions(+), 1 deletion(-)

net/ipv4/raw.c +4 -1

index bb446e60cf580..b8689052079cd 100644
@@ -721,6 +721,7 @@ static int raw_bind(struct sock *sk, struct sockaddr *uaddr, int addr_len)
 	int ret = -EINVAL;
 	int chk_addr_ret;
 
+	lock_sock(sk);
 	if (sk->sk_state != TCP_CLOSE || addr_len < sizeof(struct sockaddr_in))
 		goto out;

@@ -740,7 +741,9 @@ static int raw_bind(struct sock *sk, struct sockaddr *uaddr, int addr_len)
 		inet->inet_saddr = 0;  /* Use device */
 	sk_dst_reset(sk);
 	ret = 0;
-out:	return ret;
+out:
+	release_sock(sk);
+	return ret;
 }
 
 /*

Signature · 1 line

2.34.1

Greg Kroah-Hartman

author maintainer

2022-01-31 11:15 UTC #158 lore raw

PATCH 158/171 ipv4: tcp: send zero IPID in SYNACK messages

From: Eric Dumazet <[email protected]>

[ Upstream commit 970a5a3ea86da637471d3cd04d513a0755aba4bf ]

In commit 431280eebed9 ("ipv4: tcp: send zero IPID for RST and ACK sent in SYN-RECV and TIME-WAIT state") we took care of some ctl packets sent by TCP.

It turns out we need to use a similar strategy for SYNACK packets.

By default, they carry IP_DF and IPID==0, but there are ways to ask them to use the hashed IP ident generator and thus be used to build off-path attacks.
(Ref: Off-Path TCP Exploits of the Mixed IPID Assignment)

One of this way is to force (before listener is started) echo 1 >/proc/sys/net/ipv4/ip_no_pmtu_disc

Another way is using forged ICMP ICMP_FRAG_NEEDED with a very small MTU (like 68) to force a false return from ip_dont_fragment()

In this patch, ip_build_and_send_pkt() uses the following heuristics.

1) Most SYNACK packets are smaller than IPV4_MIN_MTU and therefore can use IP_DF regardless of the listener or route pmtu setting.

2) In case the SYNACK packet is bigger than IPV4_MIN_MTU, we use prandom_u32() generator instead of the IPv4 hashed ident one.

Fixes 1da177e4c3f4 ("Linux-2.6.12-rc2")

Reported-by Ray Che <[email protected]>

Reviewed-by David Ahern <[email protected]>

Cc Geoff Alexander <[email protected]>

Cc Willy Tarreau <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

---
 net/ipv4/ip_output.c | 11 +++++++++--
 1 file changed, 9 insertions(+), 2 deletions(-)

net/ipv4/ip_output.c +9 -2

index ff38b46bd4b0f..a4d2eb691cbc1 100644
@@ -162,12 +162,19 @@ int ip_build_and_send_pkt(struct sk_buff *skb, const struct sock *sk,
 	iph->daddr    = (opt && opt->opt.srr ? opt->opt.faddr : daddr);
 	iph->saddr    = saddr;
 	iph->protocol = sk->sk_protocol;
-	if (ip_dont_fragment(sk, &rt->dst)) {
+	/* Do not bother generating IPID for small packets (eg SYNACK) */
+	if (skb->len <= IPV4_MIN_MTU || ip_dont_fragment(sk, &rt->dst)) {
 		iph->frag_off = htons(IP_DF);
 		iph->id = 0;
 	} else {
 		iph->frag_off = 0;
-		__ip_select_ident(net, iph, 1);
+		/* TCP packets here are SYNACK with fat IPv4/TCP options.
+		 * Avoid using the hashed IP ident generator.
+		 */
+		if (sk->sk_protocol == IPPROTO_TCP)
+			iph->id = (__force __be16)prandom_u32();
+		else
+			__ip_select_ident(net, iph, 1);
 	}
 
 	if (opt && opt->opt.optlen) {

Signature · 1 line

2.34.1

Greg Kroah-Hartman

author maintainer

2022-01-31 11:25 UTC #159 lore raw

PATCH 159/171 ipv4: remove sparse error in ip_neigh_gw4()

From: Eric Dumazet <[email protected]>

[ Upstream commit 3c42b2019863b327caa233072c50739d4144dd16 ]

./include/net/route.h:373:48: warning: incorrect type in argument 2 (different base types)
./include/net/route.h:373:48: expected unsigned int [usertype] key
./include/net/route.h:373:48: got restricted __be32 [usertype] daddr

Fixes 5c9f7c1dfc2e ("ipv4: Add helpers for neigh lookup for nexthop")

Reviewed-by David Ahern <[email protected]>

Link https://lore.kernel.org/r/[email protected] open here

Signed-off-by Sasha Levin <[email protected]>

---
 include/net/route.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

include/net/route.h +1 -1

index 2e6c0e153e3a5..2551f3f03b37e 100644
@@ -369,7 +369,7 @@ static inline struct neighbour *ip_neigh_gw4(struct net_device *dev,
 {
 	struct neighbour *neigh;
 
-	neigh = __ipv4_neigh_lookup_noref(dev, daddr);
+	neigh = __ipv4_neigh_lookup_noref(dev, (__force u32)daddr);
 	if (unlikely(!neigh))
 		neigh = __neigh_create(&arp_tbl, &daddr, dev, false);

Signature · 1 line

2.34.1

Greg Kroah-Hartman

author maintainer

2022-01-31 11:16 UTC #160 lore raw

PATCH 160/171 net: bridge: vlan: fix memory leak in __allowed_ingress

From: Tim Yi <[email protected]>

[ Upstream commit fd20d9738395cf8e27d0a17eba34169699fccdff ]

When using per-vlan state, if vlan snooping and stats are disabled, untagged or priority-tagged ingress frame will go to check pvid state. If the port state is forwarding and the pvid state is not learning/forwarding, untagged or priority-tagged frame will be dropped but skb memory is not freed.
Should free skb when __allowed_ingress returns false.

Fixes a580c76d534c ("net: bridge: vlan: add per-vlan state")

Signed-off-by Tim Yi <[email protected]>

Acked-by Nikolay Aleksandrov <[email protected]>

Link https://lore.kernel.org/r/[email protected] open here

Signed-off-by Sasha Levin <[email protected]>

---
 net/bridge/br_vlan.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

net/bridge/br_vlan.c +3 -3

index 06f5caee495aa..10e63ea6a13e1 100644
@@ -560,10 +560,10 @@ static bool __allowed_ingress(const struct net_bridge *br,
 		    !br_opt_get(br, BROPT_VLAN_STATS_ENABLED)) {
 			if (*state == BR_STATE_FORWARDING) {
 				*state = br_vlan_get_pvid_state(vg);
-				return br_vlan_state_allowed(*state, true);
-			} else {
-				return true;
+				if (!br_vlan_state_allowed(*state, true))
+					goto drop;
 			}
+			return true;
 		}
 	}
 	v = br_vlan_find(vg, *vid);

Signature · 1 line

2.34.1

Greg Kroah-Hartman

author maintainer

2022-01-31 11:16 UTC #161 lore raw

PATCH 161/171 Bluetooth: refactor malicious adv data check

From: Brian Gix <[email protected]>

commit 899663be5e75dc0174dc8bda0b5e6826edf0b29a upstream.

Check for out-of-bound read was being performed at the end of while num_reports loop, and would fill journal with false positives. Added check to beginning of loop processing so that it doesn't get checked after ptr has been advanced.

Signed-off-by Brian Gix <[email protected]>

Signed-off-by Marcel Holtmann <[email protected]>

Cc syphyr <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 net/bluetooth/hci_event.c |   10 +++++-----
 1 file changed, 5 insertions(+), 5 deletions(-)

net/bluetooth/hci_event.c +5 -5

@@ -5782,6 +5782,11 @@ static void hci_le_adv_report_evt(struct
 		struct hci_ev_le_advertising_info *ev = ptr;
 		s8 rssi;
 
+		if (ptr > (void *)skb_tail_pointer(skb) - sizeof(*ev)) {
+			bt_dev_err(hdev, "Malicious advertising data.");
+			break;
+		}
+
 		if (ev->length <= HCI_MAX_AD_LENGTH &&
 		    ev->data + ev->length <= skb_tail_pointer(skb)) {
 			rssi = ev->data[ev->length];

@@ -5793,11 +5798,6 @@ static void hci_le_adv_report_evt(struct
 		}
 
 		ptr += sizeof(*ev) + ev->length + 1;
-
-		if (ptr > (void *) skb_tail_pointer(skb) - sizeof(*ev)) {
-			bt_dev_err(hdev, "Malicious advertising data. Stopping processing");
-			break;
-		}
 	}
 
 	hci_dev_unlock(hdev);

Greg Kroah-Hartman

author maintainer

2022-01-31 11:20 UTC #162 lore raw

PATCH 162/171 irqchip/realtek-rtl: Map control data to virq

From: Sander Vanheule <[email protected]>

commit 291e79c7e2eb6fdc016453597b78482e06199d0f upstream.

The driver assigned the irqchip and irq handler to the hardware irq, instead of the virq. This is incorrect, and only worked because these irq numbers happened to be the same on the devices used for testing the original driver.

Fixes 9f3a0f34b84a ("irqchip: Add support for Realtek RTL838x/RTL839x interrupt controller")

Signed-off-by Sander Vanheule <[email protected]>

Link https://lore.kernel.org/r/4b4936606480265db47df152f00bc2ed46340599.1641739718.git.sander@svanheule.net open here

Signed-off-by Greg Kroah-Hartman <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

---
 drivers/irqchip/irq-realtek-rtl.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

drivers/irqchip/irq-realtek-rtl.c +1 -1

@@ -62,7 +62,7 @@ static struct irq_chip realtek_ictl_irq
 
 static int intc_map(struct irq_domain *d, unsigned int irq, irq_hw_number_t hw)
 {
-	irq_set_chip_and_handler(hw, &realtek_ictl_irq, handle_level_irq);
+	irq_set_chip_and_handler(irq, &realtek_ictl_irq, handle_level_irq);
 
 	return 0;
 }

Greg Kroah-Hartman

author maintainer

2022-01-31 11:25 UTC #163 lore raw

PATCH 163/171 irqchip/realtek-rtl: Fix off-by-one in routing

From: Sander Vanheule <[email protected]>

commit 91351b5dd0fd494eb2d85e1bb6aca77b067447e0 upstream.

There is an offset between routing values (1..6) and the connected MIPS CPU interrupts (2..7), but no distinction was made between these two values.

This issue was previously hidden during testing, because an interrupt mapping was used where for each required interrupt another (unused) routing was configured, with an offset of +1.

Offset the CPU IRQ numbers by -1 to retrieve the correct routing value.

Fixes 9f3a0f34b84a ("irqchip: Add support for Realtek RTL838x/RTL839x interrupt controller")

Signed-off-by Sander Vanheule <[email protected]>

Link https://lore.kernel.org/r/177b920aa8d8610615692d0e657e509f363c85ca.1641739718.git.sander@svanheule.net open here

Signed-off-by Greg Kroah-Hartman <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

---
 drivers/irqchip/irq-realtek-rtl.c |    8 +++++---
 1 file changed, 5 insertions(+), 3 deletions(-)

drivers/irqchip/irq-realtek-rtl.c +5 -3

@@ -95,7 +95,8 @@ out:
  * SoC interrupts are cascaded to MIPS CPU interrupts according to the
  * interrupt-map in the device tree. Each SoC interrupt gets 4 bits for
  * the CPU interrupt in an Interrupt Routing Register. Max 32 SoC interrupts
- * thus go into 4 IRRs.
+ * thus go into 4 IRRs. A routing value of '0' means the interrupt is left
+ * disconnected. Routing values {1..15} connect to output lines {0..14}.
  */
 static int __init map_interrupts(struct device_node *node, struct irq_domain *domain)
 {

@@ -134,7 +135,7 @@ static int __init map_interrupts(struct
 		of_node_put(cpu_ictl);
 
 		cpu_int = be32_to_cpup(imap + 2);
-		if (cpu_int > 7)
+		if (cpu_int > 7 || cpu_int < 2)
 			return -EINVAL;
 
 		if (!(mips_irqs_set & BIT(cpu_int))) {

@@ -143,7 +144,8 @@ static int __init map_interrupts(struct
 			mips_irqs_set |= BIT(cpu_int);
 		}
 
-		regs[(soc_int * 4) / 32] |= cpu_int << (soc_int * 4) % 32;
+		/* Use routing values (1..6) for CPU interrupts (2..7) */
+		regs[(soc_int * 4) / 32] |= (cpu_int - 1) << (soc_int * 4) % 32;
 		imap += 3;
 	}

Greg Kroah-Hartman

author maintainer

2022-01-31 11:16 UTC #164 lore raw

PATCH 164/171 dt-bindings: can: tcan4x5x: fix mram-cfg RX FIFO config

Link https://lore.kernel.org/all/[email protected] open here

From: Marc Kleine-Budde <[email protected]>

commit 17a30422621c0e04cb6060d20d7edcefd7463347 upstream.

This tcan4x5x only comes with 2K of MRAM, a RX FIFO with a dept of 32 doesn't fit into the MRAM. Use a depth of 16 instead.

Fixes 4edd396a1911 ("dt-bindings: can: tcan4x5x: Add DT bindings for TCAN4x5X driver")

Signed-off-by Marc Kleine-Budde <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 Documentation/devicetree/bindings/net/can/tcan4x5x.txt |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

Documentation/devicetree/bindings/net/can/tcan4x5x.txt +1 -1

@@ -31,7 +31,7 @@ tcan4x5x: tcan4x5x@0 {
 		#address-cells = <1>;
 		#size-cells = <1>;
 		spi-max-frequency = <10000000>;
-		bosch,mram-cfg = <0x0 0 0 32 0 0 1 1>;
+		bosch,mram-cfg = <0x0 0 0 16 0 0 1 1>;
 		interrupt-parent = <&gpio1>;
 		interrupts = <14 IRQ_TYPE_LEVEL_LOW>;
 		device-state-gpios = <&gpio3 21 GPIO_ACTIVE_HIGH>;

Greg Kroah-Hartman

author maintainer

2022-01-31 11:25 UTC #165 lore raw

PATCH 165/171 perf/core: Fix cgroup event list management