From: Sasha Levin Date: Mon, 31 Oct 2022 10:23:23 +0000 (-0400) Subject: Fixes for 5.4 X-Git-Tag: v4.19.263~12 X-Git-Url: http://git.ipfire.org/?a=commitdiff_plain;h=8e57f8e0311cab1613bb7096306928e6398e9417;p=thirdparty%2Fkernel%2Fstable-queue.git Fixes for 5.4 Signed-off-by: Sasha Levin --- diff --git a/queue-5.4/alsa-ac97-fix-possible-memory-leak-in-snd_ac97_dev_r.patch b/queue-5.4/alsa-ac97-fix-possible-memory-leak-in-snd_ac97_dev_r.patch new file mode 100644 index 00000000000..edc4a680fad --- /dev/null +++ b/queue-5.4/alsa-ac97-fix-possible-memory-leak-in-snd_ac97_dev_r.patch @@ -0,0 +1,37 @@ +From 187abd43ed332b09882db537611378f9d25c721f Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Wed, 19 Oct 2022 17:30:25 +0800 +Subject: ALSA: ac97: fix possible memory leak in snd_ac97_dev_register() + +From: Yang Yingliang + +[ Upstream commit 4881bda5ea05c8c240fc8afeaa928e2bc43f61fa ] + +If device_register() fails in snd_ac97_dev_register(), it should +call put_device() to give up reference, or the name allocated in +dev_set_name() is leaked. + +Fixes: 0ca06a00e206 ("[ALSA] AC97 bus interface for ad-hoc drivers") +Signed-off-by: Yang Yingliang +Link: https://lore.kernel.org/r/20221019093025.1179475-1-yangyingliang@huawei.com +Signed-off-by: Takashi Iwai +Signed-off-by: Sasha Levin +--- + sound/pci/ac97/ac97_codec.c | 1 + + 1 file changed, 1 insertion(+) + +diff --git a/sound/pci/ac97/ac97_codec.c b/sound/pci/ac97/ac97_codec.c +index 6fb192a94762..83bb086bf975 100644 +--- a/sound/pci/ac97/ac97_codec.c ++++ b/sound/pci/ac97/ac97_codec.c +@@ -1945,6 +1945,7 @@ static int snd_ac97_dev_register(struct snd_device *device) + snd_ac97_get_short_name(ac97)); + if ((err = device_register(&ac97->dev)) < 0) { + ac97_err(ac97, "Can't register ac97 bus\n"); ++ put_device(&ac97->dev); + ac97->dev.bus = NULL; + return err; + } +-- +2.35.1 + diff --git a/queue-5.4/alsa-aoa-fix-i2s-device-accounting.patch b/queue-5.4/alsa-aoa-fix-i2s-device-accounting.patch new file mode 100644 index 00000000000..f2a974823f6 --- /dev/null +++ b/queue-5.4/alsa-aoa-fix-i2s-device-accounting.patch @@ -0,0 +1,49 @@ +From 74c74966fcfe6ef45947abf839b0eb1afa1c0dc1 Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Thu, 27 Oct 2022 08:52:33 +0200 +Subject: ALSA: aoa: Fix I2S device accounting + +From: Takashi Iwai + +[ Upstream commit f1fae475f10a26b7e34da4ff2e2f19b7feb3548e ] + +i2sbus_add_dev() is supposed to return the number of probed devices, +i.e. either 1 or 0. However, i2sbus_add_dev() has one error handling +that returns -ENODEV; this will screw up the accumulation number +counted in the caller, i2sbus_probe(). + +Fix the return value to 0 and add the comment for better understanding +for readers. + +Fixes: f3d9478b2ce4 ("[ALSA] snd-aoa: add snd-aoa") +Link: https://lore.kernel.org/r/20221027065233.13292-1-tiwai@suse.de +Signed-off-by: Takashi Iwai +Signed-off-by: Sasha Levin +--- + sound/aoa/soundbus/i2sbus/core.c | 3 ++- + 1 file changed, 2 insertions(+), 1 deletion(-) + +diff --git a/sound/aoa/soundbus/i2sbus/core.c b/sound/aoa/soundbus/i2sbus/core.c +index 4b01c51fbd33..3f5ee9f96ef1 100644 +--- a/sound/aoa/soundbus/i2sbus/core.c ++++ b/sound/aoa/soundbus/i2sbus/core.c +@@ -147,6 +147,7 @@ static int i2sbus_get_and_fixup_rsrc(struct device_node *np, int index, + return rc; + } + ++/* Returns 1 if added, 0 for otherwise; don't return a negative value! */ + /* FIXME: look at device node refcounting */ + static int i2sbus_add_dev(struct macio_dev *macio, + struct i2sbus_control *control, +@@ -213,7 +214,7 @@ static int i2sbus_add_dev(struct macio_dev *macio, + * either as the second one in that case is just a modem. */ + if (!ok) { + kfree(dev); +- return -ENODEV; ++ return 0; + } + + mutex_init(&dev->lock); +-- +2.35.1 + diff --git a/queue-5.4/alsa-aoa-i2sbus-fix-possible-memory-leak-in-i2sbus_a.patch b/queue-5.4/alsa-aoa-i2sbus-fix-possible-memory-leak-in-i2sbus_a.patch new file mode 100644 index 00000000000..0d737fe2aa8 --- /dev/null +++ b/queue-5.4/alsa-aoa-i2sbus-fix-possible-memory-leak-in-i2sbus_a.patch @@ -0,0 +1,42 @@ +From b9ce5cfc81349607145abb003e590a206f0b6332 Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Thu, 27 Oct 2022 09:34:38 +0800 +Subject: ALSA: aoa: i2sbus: fix possible memory leak in i2sbus_add_dev() + +From: Yang Yingliang + +[ Upstream commit 4a4c8482e370d697738a78dcd7bf2780832cb712 ] + +dev_set_name() in soundbus_add_one() allocates memory for name, it need be +freed when of_device_register() fails, call soundbus_dev_put() to give up +the reference that hold in device_initialize(), so that it can be freed in +kobject_cleanup() when the refcount hit to 0. And other resources are also +freed in i2sbus_release_dev(), so it can return 0 directly. + +Fixes: f3d9478b2ce4 ("[ALSA] snd-aoa: add snd-aoa") +Signed-off-by: Yang Yingliang +Link: https://lore.kernel.org/r/20221027013438.991920-1-yangyingliang@huawei.com +Signed-off-by: Takashi Iwai +Signed-off-by: Sasha Levin +--- + sound/aoa/soundbus/i2sbus/core.c | 4 ++++ + 1 file changed, 4 insertions(+) + +diff --git a/sound/aoa/soundbus/i2sbus/core.c b/sound/aoa/soundbus/i2sbus/core.c +index 17df288fbe98..4b01c51fbd33 100644 +--- a/sound/aoa/soundbus/i2sbus/core.c ++++ b/sound/aoa/soundbus/i2sbus/core.c +@@ -302,6 +302,10 @@ static int i2sbus_add_dev(struct macio_dev *macio, + + if (soundbus_add_one(&dev->sound)) { + printk(KERN_DEBUG "i2sbus: device registration error!\n"); ++ if (dev->sound.ofdev.dev.kobj.state_initialized) { ++ soundbus_dev_put(&dev->sound); ++ return 0; ++ } + goto err; + } + +-- +2.35.1 + diff --git a/queue-5.4/amd-xgbe-add-the-bit-rate-quirk-for-molex-cables.patch b/queue-5.4/amd-xgbe-add-the-bit-rate-quirk-for-molex-cables.patch new file mode 100644 index 00000000000..2f6fac2710e --- /dev/null +++ b/queue-5.4/amd-xgbe-add-the-bit-rate-quirk-for-molex-cables.patch @@ -0,0 +1,61 @@ +From 79a1153cae907361fde016451558fc8d36143097 Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Thu, 20 Oct 2022 12:12:15 +0530 +Subject: amd-xgbe: add the bit rate quirk for Molex cables + +From: Raju Rangoju + +[ Upstream commit 170a9e341a3b02c0b2ea0df16ef14a33a4f41de8 ] + +The offset 12 (bit-rate) of EEPROM SFP DAC (passive) cables is expected +to be in the range 0x64 to 0x68. However, the 5 meter and 7 meter Molex +passive cables have the rate ceiling 0x78 at offset 12. + +Add a quirk for Molex passive cables to extend the rate ceiling to 0x78. + +Fixes: abf0a1c2b26a ("amd-xgbe: Add support for SFP+ modules") +Signed-off-by: Raju Rangoju +Acked-by: Tom Lendacky +Signed-off-by: Jakub Kicinski +Signed-off-by: Sasha Levin +--- + drivers/net/ethernet/amd/xgbe/xgbe-phy-v2.c | 9 ++++++++- + 1 file changed, 8 insertions(+), 1 deletion(-) + +diff --git a/drivers/net/ethernet/amd/xgbe/xgbe-phy-v2.c b/drivers/net/ethernet/amd/xgbe/xgbe-phy-v2.c +index 5069ae164ecf..b76138cd0935 100644 +--- a/drivers/net/ethernet/amd/xgbe/xgbe-phy-v2.c ++++ b/drivers/net/ethernet/amd/xgbe/xgbe-phy-v2.c +@@ -238,6 +238,7 @@ enum xgbe_sfp_speed { + #define XGBE_SFP_BASE_BR_1GBE_MAX 0x0d + #define XGBE_SFP_BASE_BR_10GBE_MIN 0x64 + #define XGBE_SFP_BASE_BR_10GBE_MAX 0x68 ++#define XGBE_MOLEX_SFP_BASE_BR_10GBE_MAX 0x78 + + #define XGBE_SFP_BASE_CU_CABLE_LEN 18 + +@@ -283,6 +284,8 @@ struct xgbe_sfp_eeprom { + #define XGBE_BEL_FUSE_VENDOR "BEL-FUSE " + #define XGBE_BEL_FUSE_PARTNO "1GBT-SFP06 " + ++#define XGBE_MOLEX_VENDOR "Molex Inc. " ++ + struct xgbe_sfp_ascii { + union { + char vendor[XGBE_SFP_BASE_VENDOR_NAME_LEN + 1]; +@@ -833,7 +836,11 @@ static bool xgbe_phy_sfp_bit_rate(struct xgbe_sfp_eeprom *sfp_eeprom, + break; + case XGBE_SFP_SPEED_10000: + min = XGBE_SFP_BASE_BR_10GBE_MIN; +- max = XGBE_SFP_BASE_BR_10GBE_MAX; ++ if (memcmp(&sfp_eeprom->base[XGBE_SFP_BASE_VENDOR_NAME], ++ XGBE_MOLEX_VENDOR, XGBE_SFP_BASE_VENDOR_NAME_LEN) == 0) ++ max = XGBE_MOLEX_SFP_BASE_BR_10GBE_MAX; ++ else ++ max = XGBE_SFP_BASE_BR_10GBE_MAX; + break; + default: + return false; +-- +2.35.1 + diff --git a/queue-5.4/amd-xgbe-fix-the-sfp-compliance-codes-check-for-dac-.patch b/queue-5.4/amd-xgbe-fix-the-sfp-compliance-codes-check-for-dac-.patch new file mode 100644 index 00000000000..faf54aa7ff4 --- /dev/null +++ b/queue-5.4/amd-xgbe-fix-the-sfp-compliance-codes-check-for-dac-.patch @@ -0,0 +1,54 @@ +From 448ee95a39bd19c1fb64c04a7bfdb0324ca84650 Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Thu, 20 Oct 2022 12:12:14 +0530 +Subject: amd-xgbe: fix the SFP compliance codes check for DAC cables + +From: Raju Rangoju + +[ Upstream commit 09c5f6bf11ac98874339e55f4f5f79a9dbc9b375 ] + +The current XGBE code assumes that offset 6 of EEPROM SFP DAC (passive) +cables is NULL. However, some cables (the 5 meter and 7 meter Molex +passive cables) have non-zero data at offset 6. Fix the logic by moving +the passive cable check above the active checks, so as not to be +improperly identified as an active cable. This will fix the issue for +any passive cable that advertises 1000Base-CX in offset 6. + +Fixes: abf0a1c2b26a ("amd-xgbe: Add support for SFP+ modules") +Signed-off-by: Raju Rangoju +Acked-by: Tom Lendacky +Signed-off-by: Jakub Kicinski +Signed-off-by: Sasha Levin +--- + drivers/net/ethernet/amd/xgbe/xgbe-phy-v2.c | 8 ++++---- + 1 file changed, 4 insertions(+), 4 deletions(-) + +diff --git a/drivers/net/ethernet/amd/xgbe/xgbe-phy-v2.c b/drivers/net/ethernet/amd/xgbe/xgbe-phy-v2.c +index 0b325ae875b5..5069ae164ecf 100644 +--- a/drivers/net/ethernet/amd/xgbe/xgbe-phy-v2.c ++++ b/drivers/net/ethernet/amd/xgbe/xgbe-phy-v2.c +@@ -1150,7 +1150,10 @@ static void xgbe_phy_sfp_parse_eeprom(struct xgbe_prv_data *pdata) + } + + /* Determine the type of SFP */ +- if (sfp_base[XGBE_SFP_BASE_10GBE_CC] & XGBE_SFP_BASE_10GBE_CC_SR) ++ if (phy_data->sfp_cable == XGBE_SFP_CABLE_PASSIVE && ++ xgbe_phy_sfp_bit_rate(sfp_eeprom, XGBE_SFP_SPEED_10000)) ++ phy_data->sfp_base = XGBE_SFP_BASE_10000_CR; ++ else if (sfp_base[XGBE_SFP_BASE_10GBE_CC] & XGBE_SFP_BASE_10GBE_CC_SR) + phy_data->sfp_base = XGBE_SFP_BASE_10000_SR; + else if (sfp_base[XGBE_SFP_BASE_10GBE_CC] & XGBE_SFP_BASE_10GBE_CC_LR) + phy_data->sfp_base = XGBE_SFP_BASE_10000_LR; +@@ -1166,9 +1169,6 @@ static void xgbe_phy_sfp_parse_eeprom(struct xgbe_prv_data *pdata) + phy_data->sfp_base = XGBE_SFP_BASE_1000_CX; + else if (sfp_base[XGBE_SFP_BASE_1GBE_CC] & XGBE_SFP_BASE_1GBE_CC_T) + phy_data->sfp_base = XGBE_SFP_BASE_1000_T; +- else if ((phy_data->sfp_cable == XGBE_SFP_CABLE_PASSIVE) && +- xgbe_phy_sfp_bit_rate(sfp_eeprom, XGBE_SFP_SPEED_10000)) +- phy_data->sfp_base = XGBE_SFP_BASE_10000_CR; + + switch (phy_data->sfp_base) { + case XGBE_SFP_BASE_1000_T: +-- +2.35.1 + diff --git a/queue-5.4/arc-iounmap-arg-is-volatile.patch b/queue-5.4/arc-iounmap-arg-is-volatile.patch new file mode 100644 index 00000000000..4d97cdb5feb --- /dev/null +++ b/queue-5.4/arc-iounmap-arg-is-volatile.patch @@ -0,0 +1,59 @@ +From 06553a70cf367b3b69ac84a4bf135f01b6bb1846 Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Sun, 9 Oct 2022 19:28:46 -0700 +Subject: arc: iounmap() arg is volatile + +From: Randy Dunlap + +[ Upstream commit c44f15c1c09481d50fd33478ebb5b8284f8f5edb ] + +Add 'volatile' to iounmap()'s argument to prevent build warnings. +This make it the same as other major architectures. + +Placates these warnings: (12 such warnings) + +../drivers/video/fbdev/riva/fbdev.c: In function 'rivafb_probe': +../drivers/video/fbdev/riva/fbdev.c:2067:42: error: passing argument 1 of 'iounmap' discards 'volatile' qualifier from pointer target type [-Werror=discarded-qualifiers] + 2067 | iounmap(default_par->riva.PRAMIN); + +Fixes: 1162b0701b14b ("ARC: I/O and DMA Mappings") +Signed-off-by: Randy Dunlap +Cc: Vineet Gupta +Cc: linux-snps-arc@lists.infradead.org +Cc: Arnd Bergmann +Signed-off-by: Vineet Gupta +Signed-off-by: Sasha Levin +--- + arch/arc/include/asm/io.h | 2 +- + arch/arc/mm/ioremap.c | 2 +- + 2 files changed, 2 insertions(+), 2 deletions(-) + +diff --git a/arch/arc/include/asm/io.h b/arch/arc/include/asm/io.h +index 72f7929736f8..94ef71b38b69 100644 +--- a/arch/arc/include/asm/io.h ++++ b/arch/arc/include/asm/io.h +@@ -32,7 +32,7 @@ static inline void ioport_unmap(void __iomem *addr) + { + } + +-extern void iounmap(const void __iomem *addr); ++extern void iounmap(const volatile void __iomem *addr); + + #define ioremap_nocache(phy, sz) ioremap(phy, sz) + #define ioremap_wc(phy, sz) ioremap(phy, sz) +diff --git a/arch/arc/mm/ioremap.c b/arch/arc/mm/ioremap.c +index 95c649fbc95a..d3b1ea16e9cd 100644 +--- a/arch/arc/mm/ioremap.c ++++ b/arch/arc/mm/ioremap.c +@@ -93,7 +93,7 @@ void __iomem *ioremap_prot(phys_addr_t paddr, unsigned long size, + EXPORT_SYMBOL(ioremap_prot); + + +-void iounmap(const void __iomem *addr) ++void iounmap(const volatile void __iomem *addr) + { + /* weird double cast to handle phys_addr_t > 32 bits */ + if (arc_uncached_addr_space((phys_addr_t)(u32)addr)) +-- +2.35.1 + diff --git a/queue-5.4/can-mscan-mpc5xxx-mpc5xxx_can_probe-add-missing-put_.patch b/queue-5.4/can-mscan-mpc5xxx-mpc5xxx_can_probe-add-missing-put_.patch new file mode 100644 index 00000000000..66908b727ac --- /dev/null +++ b/queue-5.4/can-mscan-mpc5xxx-mpc5xxx_can_probe-add-missing-put_.patch @@ -0,0 +1,60 @@ +From 5b176e9fac6179f69816e5a76963a20bd2225c24 Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Mon, 24 Oct 2022 19:48:07 +0800 +Subject: can: mscan: mpc5xxx: mpc5xxx_can_probe(): add missing put_clock() in + error path + +From: Dongliang Mu + +[ Upstream commit 3e5b3418827cefb5e1cc658806f02965791b8f07 ] + +The commit 1149108e2fbf ("can: mscan: improve clock API use") only +adds put_clock() in mpc5xxx_can_remove() function, forgetting to add +put_clock() in the error handling code. + +Fix this bug by adding put_clock() in the error handling code. + +Fixes: 1149108e2fbf ("can: mscan: improve clock API use") +Signed-off-by: Dongliang Mu +Link: https://lore.kernel.org/all/20221024133828.35881-1-mkl@pengutronix.de +Signed-off-by: Marc Kleine-Budde +Signed-off-by: Sasha Levin +--- + drivers/net/can/mscan/mpc5xxx_can.c | 8 +++++--- + 1 file changed, 5 insertions(+), 3 deletions(-) + +diff --git a/drivers/net/can/mscan/mpc5xxx_can.c b/drivers/net/can/mscan/mpc5xxx_can.c +index e4f4b5c9ebd6..3305d9d6c466 100644 +--- a/drivers/net/can/mscan/mpc5xxx_can.c ++++ b/drivers/net/can/mscan/mpc5xxx_can.c +@@ -325,14 +325,14 @@ static int mpc5xxx_can_probe(struct platform_device *ofdev) + &mscan_clksrc); + if (!priv->can.clock.freq) { + dev_err(&ofdev->dev, "couldn't get MSCAN clock properties\n"); +- goto exit_free_mscan; ++ goto exit_put_clock; + } + + err = register_mscandev(dev, mscan_clksrc); + if (err) { + dev_err(&ofdev->dev, "registering %s failed (err=%d)\n", + DRV_NAME, err); +- goto exit_free_mscan; ++ goto exit_put_clock; + } + + dev_info(&ofdev->dev, "MSCAN at 0x%p, irq %d, clock %d Hz\n", +@@ -340,7 +340,9 @@ static int mpc5xxx_can_probe(struct platform_device *ofdev) + + return 0; + +-exit_free_mscan: ++exit_put_clock: ++ if (data->put_clock) ++ data->put_clock(ofdev); + free_candev(dev); + exit_dispose_irq: + irq_dispose_mapping(irq); +-- +2.35.1 + diff --git a/queue-5.4/drm-msm-fix-return-type-of-mdp4_lvds_connector_mode_.patch b/queue-5.4/drm-msm-fix-return-type-of-mdp4_lvds_connector_mode_.patch new file mode 100644 index 00000000000..dd75f97d049 --- /dev/null +++ b/queue-5.4/drm-msm-fix-return-type-of-mdp4_lvds_connector_mode_.patch @@ -0,0 +1,54 @@ +From b581a2435541288cff214f8d6f8b8407568f7009 Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Tue, 13 Sep 2022 13:55:48 -0700 +Subject: drm/msm: Fix return type of mdp4_lvds_connector_mode_valid + +From: Nathan Huckleberry + +[ Upstream commit 0b33a33bd15d5bab73b87152b220a8d0153a4587 ] + +The mode_valid field in drm_connector_helper_funcs is expected to be of +type: +enum drm_mode_status (* mode_valid) (struct drm_connector *connector, + struct drm_display_mode *mode); + +The mismatched return type breaks forward edge kCFI since the underlying +function definition does not match the function hook definition. + +The return type of mdp4_lvds_connector_mode_valid should be changed from +int to enum drm_mode_status. + +Reported-by: Dan Carpenter +Link: https://github.com/ClangBuiltLinux/linux/issues/1703 +Cc: llvm@lists.linux.dev +Signed-off-by: Nathan Huckleberry +Fixes: 3e87599b68e7 ("drm/msm/mdp4: add LVDS panel support") +Reviewed-by: Abhinav Kumar +Reviewed-by: Nathan Chancellor +Patchwork: https://patchwork.freedesktop.org/patch/502878/ +Link: https://lore.kernel.org/r/20220913205551.155128-1-nhuck@google.com +Signed-off-by: Abhinav Kumar +Signed-off-by: Sasha Levin +--- + drivers/gpu/drm/msm/disp/mdp4/mdp4_lvds_connector.c | 5 +++-- + 1 file changed, 3 insertions(+), 2 deletions(-) + +diff --git a/drivers/gpu/drm/msm/disp/mdp4/mdp4_lvds_connector.c b/drivers/gpu/drm/msm/disp/mdp4/mdp4_lvds_connector.c +index 9262ed2dc8c3..bdcc3e91bf88 100644 +--- a/drivers/gpu/drm/msm/disp/mdp4/mdp4_lvds_connector.c ++++ b/drivers/gpu/drm/msm/disp/mdp4/mdp4_lvds_connector.c +@@ -61,8 +61,9 @@ static int mdp4_lvds_connector_get_modes(struct drm_connector *connector) + return ret; + } + +-static int mdp4_lvds_connector_mode_valid(struct drm_connector *connector, +- struct drm_display_mode *mode) ++static enum drm_mode_status ++mdp4_lvds_connector_mode_valid(struct drm_connector *connector, ++ struct drm_display_mode *mode) + { + struct mdp4_lvds_connector *mdp4_lvds_connector = + to_mdp4_lvds_connector(connector); +-- +2.35.1 + diff --git a/queue-5.4/i40e-fix-ethtool-rx-flow-hash-setting-for-x722.patch b/queue-5.4/i40e-fix-ethtool-rx-flow-hash-setting-for-x722.patch new file mode 100644 index 00000000000..2cecd7a7a33 --- /dev/null +++ b/queue-5.4/i40e-fix-ethtool-rx-flow-hash-setting-for-x722.patch @@ -0,0 +1,129 @@ +From c1f8ce00409c6c201f02a940d44763a34a320618 Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Mon, 24 Oct 2022 03:05:24 -0700 +Subject: i40e: Fix ethtool rx-flow-hash setting for X722 + +From: Slawomir Laba + +[ Upstream commit 54b5af5a438076082d482cab105b1bd484ab5074 ] + +When enabling flow type for RSS hash via ethtool: + +ethtool -N $pf rx-flow-hash tcp4|tcp6|udp4|udp6 s|d + +the driver would fail to setup this setting on X722 +device since it was using the mask on the register +dedicated for X710 devices. + +Apply a different mask on the register when setting the +RSS hash for the X722 device. + +When displaying the flow types enabled via ethtool: + +ethtool -n $pf rx-flow-hash tcp4|tcp6|udp4|udp6 + +the driver would print wrong values for X722 device. + +Fix this issue by testing masks for X722 device in +i40e_get_rss_hash_opts function. + +Fixes: eb0dd6e4a3b3 ("i40e: Allow RSS Hash set with less than four parameters") +Signed-off-by: Slawomir Laba +Signed-off-by: Michal Jaron +Signed-off-by: Mateusz Palczewski +Tested-by: Gurucharan (A Contingent worker at Intel) +Signed-off-by: Jacob Keller +Link: https://lore.kernel.org/r/20221024100526.1874914-1-jacob.e.keller@intel.com +Signed-off-by: Jakub Kicinski +Signed-off-by: Sasha Levin +--- + .../net/ethernet/intel/i40e/i40e_ethtool.c | 31 ++++++++++++++----- + drivers/net/ethernet/intel/i40e/i40e_type.h | 4 +++ + 2 files changed, 27 insertions(+), 8 deletions(-) + +diff --git a/drivers/net/ethernet/intel/i40e/i40e_ethtool.c b/drivers/net/ethernet/intel/i40e/i40e_ethtool.c +index 689deecb4e1a..b9efd379a447 100644 +--- a/drivers/net/ethernet/intel/i40e/i40e_ethtool.c ++++ b/drivers/net/ethernet/intel/i40e/i40e_ethtool.c +@@ -3082,10 +3082,17 @@ static int i40e_get_rss_hash_opts(struct i40e_pf *pf, struct ethtool_rxnfc *cmd) + + if (cmd->flow_type == TCP_V4_FLOW || + cmd->flow_type == UDP_V4_FLOW) { +- if (i_set & I40E_L3_SRC_MASK) +- cmd->data |= RXH_IP_SRC; +- if (i_set & I40E_L3_DST_MASK) +- cmd->data |= RXH_IP_DST; ++ if (hw->mac.type == I40E_MAC_X722) { ++ if (i_set & I40E_X722_L3_SRC_MASK) ++ cmd->data |= RXH_IP_SRC; ++ if (i_set & I40E_X722_L3_DST_MASK) ++ cmd->data |= RXH_IP_DST; ++ } else { ++ if (i_set & I40E_L3_SRC_MASK) ++ cmd->data |= RXH_IP_SRC; ++ if (i_set & I40E_L3_DST_MASK) ++ cmd->data |= RXH_IP_DST; ++ } + } else if (cmd->flow_type == TCP_V6_FLOW || + cmd->flow_type == UDP_V6_FLOW) { + if (i_set & I40E_L3_V6_SRC_MASK) +@@ -3392,12 +3399,15 @@ static int i40e_get_rxnfc(struct net_device *netdev, struct ethtool_rxnfc *cmd, + + /** + * i40e_get_rss_hash_bits - Read RSS Hash bits from register ++ * @hw: hw structure + * @nfc: pointer to user request + * @i_setc: bits currently set + * + * Returns value of bits to be set per user request + **/ +-static u64 i40e_get_rss_hash_bits(struct ethtool_rxnfc *nfc, u64 i_setc) ++static u64 i40e_get_rss_hash_bits(struct i40e_hw *hw, ++ struct ethtool_rxnfc *nfc, ++ u64 i_setc) + { + u64 i_set = i_setc; + u64 src_l3 = 0, dst_l3 = 0; +@@ -3416,8 +3426,13 @@ static u64 i40e_get_rss_hash_bits(struct ethtool_rxnfc *nfc, u64 i_setc) + dst_l3 = I40E_L3_V6_DST_MASK; + } else if (nfc->flow_type == TCP_V4_FLOW || + nfc->flow_type == UDP_V4_FLOW) { +- src_l3 = I40E_L3_SRC_MASK; +- dst_l3 = I40E_L3_DST_MASK; ++ if (hw->mac.type == I40E_MAC_X722) { ++ src_l3 = I40E_X722_L3_SRC_MASK; ++ dst_l3 = I40E_X722_L3_DST_MASK; ++ } else { ++ src_l3 = I40E_L3_SRC_MASK; ++ dst_l3 = I40E_L3_DST_MASK; ++ } + } else { + /* Any other flow type are not supported here */ + return i_set; +@@ -3532,7 +3547,7 @@ static int i40e_set_rss_hash_opt(struct i40e_pf *pf, struct ethtool_rxnfc *nfc) + flow_pctype)) | + ((u64)i40e_read_rx_ctl(hw, I40E_GLQF_HASH_INSET(1, + flow_pctype)) << 32); +- i_set = i40e_get_rss_hash_bits(nfc, i_setc); ++ i_set = i40e_get_rss_hash_bits(&pf->hw, nfc, i_setc); + i40e_write_rx_ctl(hw, I40E_GLQF_HASH_INSET(0, flow_pctype), + (u32)i_set); + i40e_write_rx_ctl(hw, I40E_GLQF_HASH_INSET(1, flow_pctype), +diff --git a/drivers/net/ethernet/intel/i40e/i40e_type.h b/drivers/net/ethernet/intel/i40e/i40e_type.h +index 666a251e8c72..047068120ba7 100644 +--- a/drivers/net/ethernet/intel/i40e/i40e_type.h ++++ b/drivers/net/ethernet/intel/i40e/i40e_type.h +@@ -1470,6 +1470,10 @@ struct i40e_lldp_variables { + #define I40E_PFQF_CTL_0_HASHLUTSIZE_512 0x00010000 + + /* INPUT SET MASK for RSS, flow director, and flexible payload */ ++#define I40E_X722_L3_SRC_SHIFT 49 ++#define I40E_X722_L3_SRC_MASK (0x3ULL << I40E_X722_L3_SRC_SHIFT) ++#define I40E_X722_L3_DST_SHIFT 41 ++#define I40E_X722_L3_DST_MASK (0x3ULL << I40E_X722_L3_DST_SHIFT) + #define I40E_L3_SRC_SHIFT 47 + #define I40E_L3_SRC_MASK (0x3ULL << I40E_L3_SRC_SHIFT) + #define I40E_L3_V6_SRC_SHIFT 43 +-- +2.35.1 + diff --git a/queue-5.4/i40e-fix-flow-type-by-setting-gl_hash_inset-register.patch b/queue-5.4/i40e-fix-flow-type-by-setting-gl_hash_inset-register.patch new file mode 100644 index 00000000000..f6f83d416f8 --- /dev/null +++ b/queue-5.4/i40e-fix-flow-type-by-setting-gl_hash_inset-register.patch @@ -0,0 +1,144 @@ +From 8cbeadcdea5cf1cea896fd15ad3170f1c7e41dbf Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Mon, 24 Oct 2022 03:05:26 -0700 +Subject: i40e: Fix flow-type by setting GL_HASH_INSET registers + +From: Slawomir Laba + +[ Upstream commit 3b32c9932853e11d71f9db012d69e92e4669ba23 ] + +Fix setting bits for specific flow_type for GLQF_HASH_INSET register. +In previous version all of the bits were set only in hena register, while +in inset only one bit was set. In order for this working correctly on all +types of cards these bits needs to be set correctly for both hena and inset +registers. + +Fixes: eb0dd6e4a3b3 ("i40e: Allow RSS Hash set with less than four parameters") +Signed-off-by: Slawomir Laba +Signed-off-by: Michal Jaron +Signed-off-by: Mateusz Palczewski +Signed-off-by: Jacob Keller +Link: https://lore.kernel.org/r/20221024100526.1874914-3-jacob.e.keller@intel.com +Signed-off-by: Jakub Kicinski +Signed-off-by: Sasha Levin +--- + .../net/ethernet/intel/i40e/i40e_ethtool.c | 71 ++++++++++--------- + 1 file changed, 38 insertions(+), 33 deletions(-) + +diff --git a/drivers/net/ethernet/intel/i40e/i40e_ethtool.c b/drivers/net/ethernet/intel/i40e/i40e_ethtool.c +index b9efd379a447..7059ced24739 100644 +--- a/drivers/net/ethernet/intel/i40e/i40e_ethtool.c ++++ b/drivers/net/ethernet/intel/i40e/i40e_ethtool.c +@@ -3450,6 +3450,7 @@ static u64 i40e_get_rss_hash_bits(struct i40e_hw *hw, + return i_set; + } + ++#define FLOW_PCTYPES_SIZE 64 + /** + * i40e_set_rss_hash_opt - Enable/Disable flow types for RSS hash + * @pf: pointer to the physical function struct +@@ -3462,9 +3463,11 @@ static int i40e_set_rss_hash_opt(struct i40e_pf *pf, struct ethtool_rxnfc *nfc) + struct i40e_hw *hw = &pf->hw; + u64 hena = (u64)i40e_read_rx_ctl(hw, I40E_PFQF_HENA(0)) | + ((u64)i40e_read_rx_ctl(hw, I40E_PFQF_HENA(1)) << 32); +- u8 flow_pctype = 0; ++ DECLARE_BITMAP(flow_pctypes, FLOW_PCTYPES_SIZE); + u64 i_set, i_setc; + ++ bitmap_zero(flow_pctypes, FLOW_PCTYPES_SIZE); ++ + if (pf->flags & I40E_FLAG_MFP_ENABLED) { + dev_err(&pf->pdev->dev, + "Change of RSS hash input set is not supported when MFP mode is enabled\n"); +@@ -3480,36 +3483,35 @@ static int i40e_set_rss_hash_opt(struct i40e_pf *pf, struct ethtool_rxnfc *nfc) + + switch (nfc->flow_type) { + case TCP_V4_FLOW: +- flow_pctype = I40E_FILTER_PCTYPE_NONF_IPV4_TCP; ++ set_bit(I40E_FILTER_PCTYPE_NONF_IPV4_TCP, flow_pctypes); + if (pf->hw_features & I40E_HW_MULTIPLE_TCP_UDP_RSS_PCTYPE) +- hena |= +- BIT_ULL(I40E_FILTER_PCTYPE_NONF_IPV4_TCP_SYN_NO_ACK); ++ set_bit(I40E_FILTER_PCTYPE_NONF_IPV4_TCP_SYN_NO_ACK, ++ flow_pctypes); + break; + case TCP_V6_FLOW: +- flow_pctype = I40E_FILTER_PCTYPE_NONF_IPV6_TCP; +- if (pf->hw_features & I40E_HW_MULTIPLE_TCP_UDP_RSS_PCTYPE) +- hena |= +- BIT_ULL(I40E_FILTER_PCTYPE_NONF_IPV4_TCP_SYN_NO_ACK); ++ set_bit(I40E_FILTER_PCTYPE_NONF_IPV6_TCP, flow_pctypes); + if (pf->hw_features & I40E_HW_MULTIPLE_TCP_UDP_RSS_PCTYPE) +- hena |= +- BIT_ULL(I40E_FILTER_PCTYPE_NONF_IPV6_TCP_SYN_NO_ACK); ++ set_bit(I40E_FILTER_PCTYPE_NONF_IPV6_TCP_SYN_NO_ACK, ++ flow_pctypes); + break; + case UDP_V4_FLOW: +- flow_pctype = I40E_FILTER_PCTYPE_NONF_IPV4_UDP; +- if (pf->hw_features & I40E_HW_MULTIPLE_TCP_UDP_RSS_PCTYPE) +- hena |= +- BIT_ULL(I40E_FILTER_PCTYPE_NONF_UNICAST_IPV4_UDP) | +- BIT_ULL(I40E_FILTER_PCTYPE_NONF_MULTICAST_IPV4_UDP); +- ++ set_bit(I40E_FILTER_PCTYPE_NONF_IPV4_UDP, flow_pctypes); ++ if (pf->hw_features & I40E_HW_MULTIPLE_TCP_UDP_RSS_PCTYPE) { ++ set_bit(I40E_FILTER_PCTYPE_NONF_UNICAST_IPV4_UDP, ++ flow_pctypes); ++ set_bit(I40E_FILTER_PCTYPE_NONF_MULTICAST_IPV4_UDP, ++ flow_pctypes); ++ } + hena |= BIT_ULL(I40E_FILTER_PCTYPE_FRAG_IPV4); + break; + case UDP_V6_FLOW: +- flow_pctype = I40E_FILTER_PCTYPE_NONF_IPV6_UDP; +- if (pf->hw_features & I40E_HW_MULTIPLE_TCP_UDP_RSS_PCTYPE) +- hena |= +- BIT_ULL(I40E_FILTER_PCTYPE_NONF_UNICAST_IPV6_UDP) | +- BIT_ULL(I40E_FILTER_PCTYPE_NONF_MULTICAST_IPV6_UDP); +- ++ set_bit(I40E_FILTER_PCTYPE_NONF_IPV6_UDP, flow_pctypes); ++ if (pf->hw_features & I40E_HW_MULTIPLE_TCP_UDP_RSS_PCTYPE) { ++ set_bit(I40E_FILTER_PCTYPE_NONF_UNICAST_IPV6_UDP, ++ flow_pctypes); ++ set_bit(I40E_FILTER_PCTYPE_NONF_MULTICAST_IPV6_UDP, ++ flow_pctypes); ++ } + hena |= BIT_ULL(I40E_FILTER_PCTYPE_FRAG_IPV6); + break; + case AH_ESP_V4_FLOW: +@@ -3542,17 +3544,20 @@ static int i40e_set_rss_hash_opt(struct i40e_pf *pf, struct ethtool_rxnfc *nfc) + return -EINVAL; + } + +- if (flow_pctype) { +- i_setc = (u64)i40e_read_rx_ctl(hw, I40E_GLQF_HASH_INSET(0, +- flow_pctype)) | +- ((u64)i40e_read_rx_ctl(hw, I40E_GLQF_HASH_INSET(1, +- flow_pctype)) << 32); +- i_set = i40e_get_rss_hash_bits(&pf->hw, nfc, i_setc); +- i40e_write_rx_ctl(hw, I40E_GLQF_HASH_INSET(0, flow_pctype), +- (u32)i_set); +- i40e_write_rx_ctl(hw, I40E_GLQF_HASH_INSET(1, flow_pctype), +- (u32)(i_set >> 32)); +- hena |= BIT_ULL(flow_pctype); ++ if (bitmap_weight(flow_pctypes, FLOW_PCTYPES_SIZE)) { ++ u8 flow_id; ++ ++ for_each_set_bit(flow_id, flow_pctypes, FLOW_PCTYPES_SIZE) { ++ i_setc = (u64)i40e_read_rx_ctl(hw, I40E_GLQF_HASH_INSET(0, flow_id)) | ++ ((u64)i40e_read_rx_ctl(hw, I40E_GLQF_HASH_INSET(1, flow_id)) << 32); ++ i_set = i40e_get_rss_hash_bits(&pf->hw, nfc, i_setc); ++ ++ i40e_write_rx_ctl(hw, I40E_GLQF_HASH_INSET(0, flow_id), ++ (u32)i_set); ++ i40e_write_rx_ctl(hw, I40E_GLQF_HASH_INSET(1, flow_id), ++ (u32)(i_set >> 32)); ++ hena |= BIT_ULL(flow_id); ++ } + } + + i40e_write_rx_ctl(hw, I40E_PFQF_HENA(0), (u32)hena); +-- +2.35.1 + diff --git a/queue-5.4/i40e-fix-vf-hang-when-reset-is-triggered-on-another-.patch b/queue-5.4/i40e-fix-vf-hang-when-reset-is-triggered-on-another-.patch new file mode 100644 index 00000000000..44183decdba --- /dev/null +++ b/queue-5.4/i40e-fix-vf-hang-when-reset-is-triggered-on-another-.patch @@ -0,0 +1,150 @@ +From caa2935dbf1de6b9dd3846ee7b07d24026ff2638 Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Mon, 24 Oct 2022 03:05:25 -0700 +Subject: i40e: Fix VF hang when reset is triggered on another VF + +From: Sylwester Dziedziuch + +[ Upstream commit 52424f974bc53c26ba3f00300a00e9de9afcd972 ] + +When a reset was triggered on one VF with i40e_reset_vf +global PF state __I40E_VF_DISABLE was set on a PF until +the reset finished. If immediately after triggering reset +on one VF there is a request to reset on another +it will cause a hang on VF side because VF will be notified +of incoming reset but the reset will never happen because +of this global state, we will get such error message: + +[ +4.890195] iavf 0000:86:02.1: Never saw reset + +and VF will hang waiting for the reset to be triggered. + +Fix this by introducing new VF state I40E_VF_STATE_RESETTING +that will be set on a VF if it is currently resetting instead of +the global __I40E_VF_DISABLE PF state. + +Fixes: 3ba9bcb4b68f ("i40e: add locking around VF reset") +Signed-off-by: Sylwester Dziedziuch +Signed-off-by: Mateusz Palczewski +Tested-by: Konrad Jankowski +Signed-off-by: Jacob Keller +Link: https://lore.kernel.org/r/20221024100526.1874914-2-jacob.e.keller@intel.com +Signed-off-by: Jakub Kicinski +Signed-off-by: Sasha Levin +--- + .../ethernet/intel/i40e/i40e_virtchnl_pf.c | 43 ++++++++++++++----- + .../ethernet/intel/i40e/i40e_virtchnl_pf.h | 1 + + 2 files changed, 33 insertions(+), 11 deletions(-) + +diff --git a/drivers/net/ethernet/intel/i40e/i40e_virtchnl_pf.c b/drivers/net/ethernet/intel/i40e/i40e_virtchnl_pf.c +index 16f5baafbbd5..fb060e3253d9 100644 +--- a/drivers/net/ethernet/intel/i40e/i40e_virtchnl_pf.c ++++ b/drivers/net/ethernet/intel/i40e/i40e_virtchnl_pf.c +@@ -1352,10 +1352,12 @@ bool i40e_reset_vf(struct i40e_vf *vf, bool flr) + if (test_bit(__I40E_VF_RESETS_DISABLED, pf->state)) + return true; + +- /* If the VFs have been disabled, this means something else is +- * resetting the VF, so we shouldn't continue. +- */ +- if (test_and_set_bit(__I40E_VF_DISABLE, pf->state)) ++ /* Bail out if VFs are disabled. */ ++ if (test_bit(__I40E_VF_DISABLE, pf->state)) ++ return true; ++ ++ /* If VF is being reset already we don't need to continue. */ ++ if (test_and_set_bit(I40E_VF_STATE_RESETTING, &vf->vf_states)) + return true; + + i40e_trigger_vf_reset(vf, flr); +@@ -1392,7 +1394,7 @@ bool i40e_reset_vf(struct i40e_vf *vf, bool flr) + i40e_cleanup_reset_vf(vf); + + i40e_flush(hw); +- clear_bit(__I40E_VF_DISABLE, pf->state); ++ clear_bit(I40E_VF_STATE_RESETTING, &vf->vf_states); + + return true; + } +@@ -1425,8 +1427,12 @@ bool i40e_reset_all_vfs(struct i40e_pf *pf, bool flr) + return false; + + /* Begin reset on all VFs at once */ +- for (v = 0; v < pf->num_alloc_vfs; v++) +- i40e_trigger_vf_reset(&pf->vf[v], flr); ++ for (v = 0; v < pf->num_alloc_vfs; v++) { ++ vf = &pf->vf[v]; ++ /* If VF is being reset no need to trigger reset again */ ++ if (!test_bit(I40E_VF_STATE_RESETTING, &vf->vf_states)) ++ i40e_trigger_vf_reset(&pf->vf[v], flr); ++ } + + /* HW requires some time to make sure it can flush the FIFO for a VF + * when it resets it. Poll the VPGEN_VFRSTAT register for each VF in +@@ -1442,9 +1448,11 @@ bool i40e_reset_all_vfs(struct i40e_pf *pf, bool flr) + */ + while (v < pf->num_alloc_vfs) { + vf = &pf->vf[v]; +- reg = rd32(hw, I40E_VPGEN_VFRSTAT(vf->vf_id)); +- if (!(reg & I40E_VPGEN_VFRSTAT_VFRD_MASK)) +- break; ++ if (!test_bit(I40E_VF_STATE_RESETTING, &vf->vf_states)) { ++ reg = rd32(hw, I40E_VPGEN_VFRSTAT(vf->vf_id)); ++ if (!(reg & I40E_VPGEN_VFRSTAT_VFRD_MASK)) ++ break; ++ } + + /* If the current VF has finished resetting, move on + * to the next VF in sequence. +@@ -1472,6 +1480,10 @@ bool i40e_reset_all_vfs(struct i40e_pf *pf, bool flr) + if (pf->vf[v].lan_vsi_idx == 0) + continue; + ++ /* If VF is reset in another thread just continue */ ++ if (test_bit(I40E_VF_STATE_RESETTING, &vf->vf_states)) ++ continue; ++ + i40e_vsi_stop_rings_no_wait(pf->vsi[pf->vf[v].lan_vsi_idx]); + } + +@@ -1483,6 +1495,10 @@ bool i40e_reset_all_vfs(struct i40e_pf *pf, bool flr) + if (pf->vf[v].lan_vsi_idx == 0) + continue; + ++ /* If VF is reset in another thread just continue */ ++ if (test_bit(I40E_VF_STATE_RESETTING, &vf->vf_states)) ++ continue; ++ + i40e_vsi_wait_queues_disabled(pf->vsi[pf->vf[v].lan_vsi_idx]); + } + +@@ -1492,8 +1508,13 @@ bool i40e_reset_all_vfs(struct i40e_pf *pf, bool flr) + mdelay(50); + + /* Finish the reset on each VF */ +- for (v = 0; v < pf->num_alloc_vfs; v++) ++ for (v = 0; v < pf->num_alloc_vfs; v++) { ++ /* If VF is reset in another thread just continue */ ++ if (test_bit(I40E_VF_STATE_RESETTING, &vf->vf_states)) ++ continue; ++ + i40e_cleanup_reset_vf(&pf->vf[v]); ++ } + + i40e_flush(hw); + clear_bit(__I40E_VF_DISABLE, pf->state); +diff --git a/drivers/net/ethernet/intel/i40e/i40e_virtchnl_pf.h b/drivers/net/ethernet/intel/i40e/i40e_virtchnl_pf.h +index 7df3e5833c5d..23182731a73d 100644 +--- a/drivers/net/ethernet/intel/i40e/i40e_virtchnl_pf.h ++++ b/drivers/net/ethernet/intel/i40e/i40e_virtchnl_pf.h +@@ -41,6 +41,7 @@ enum i40e_vf_states { + I40E_VF_STATE_MC_PROMISC, + I40E_VF_STATE_UC_PROMISC, + I40E_VF_STATE_PRE_ENABLE, ++ I40E_VF_STATE_RESETTING + }; + + /* VF capabilities */ +-- +2.35.1 + diff --git a/queue-5.4/kcm-annotate-data-races-around-kcm-rx_psock.patch b/queue-5.4/kcm-annotate-data-races-around-kcm-rx_psock.patch new file mode 100644 index 00000000000..58a8a8df3c8 --- /dev/null +++ b/queue-5.4/kcm-annotate-data-races-around-kcm-rx_psock.patch @@ -0,0 +1,101 @@ +From 5d7dc1aadd6b5c09e43e4908c340fe386c36d991 Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Thu, 20 Oct 2022 22:45:11 +0000 +Subject: kcm: annotate data-races around kcm->rx_psock + +From: Eric Dumazet + +[ Upstream commit 15e4dabda11b0fa31d510a915d1a580f47dfc92e ] + +kcm->rx_psock can be read locklessly in kcm_rfree(). +Annotate the read and writes accordingly. + +We do the same for kcm->rx_wait in the following patch. + +syzbot reported: +BUG: KCSAN: data-race in kcm_rfree / unreserve_rx_kcm + +write to 0xffff888123d827b8 of 8 bytes by task 2758 on cpu 1: +unreserve_rx_kcm+0x72/0x1f0 net/kcm/kcmsock.c:313 +kcm_rcv_strparser+0x2b5/0x3a0 net/kcm/kcmsock.c:373 +__strp_recv+0x64c/0xd20 net/strparser/strparser.c:301 +strp_recv+0x6d/0x80 net/strparser/strparser.c:335 +tcp_read_sock+0x13e/0x5a0 net/ipv4/tcp.c:1703 +strp_read_sock net/strparser/strparser.c:358 [inline] +do_strp_work net/strparser/strparser.c:406 [inline] +strp_work+0xe8/0x180 net/strparser/strparser.c:415 +process_one_work+0x3d3/0x720 kernel/workqueue.c:2289 +worker_thread+0x618/0xa70 kernel/workqueue.c:2436 +kthread+0x1a9/0x1e0 kernel/kthread.c:376 +ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:306 + +read to 0xffff888123d827b8 of 8 bytes by task 5859 on cpu 0: +kcm_rfree+0x14c/0x220 net/kcm/kcmsock.c:181 +skb_release_head_state+0x8e/0x160 net/core/skbuff.c:841 +skb_release_all net/core/skbuff.c:852 [inline] +__kfree_skb net/core/skbuff.c:868 [inline] +kfree_skb_reason+0x5c/0x260 net/core/skbuff.c:891 +kfree_skb include/linux/skbuff.h:1216 [inline] +kcm_recvmsg+0x226/0x2b0 net/kcm/kcmsock.c:1161 +____sys_recvmsg+0x16c/0x2e0 +___sys_recvmsg net/socket.c:2743 [inline] +do_recvmmsg+0x2f1/0x710 net/socket.c:2837 +__sys_recvmmsg net/socket.c:2916 [inline] +__do_sys_recvmmsg net/socket.c:2939 [inline] +__se_sys_recvmmsg net/socket.c:2932 [inline] +__x64_sys_recvmmsg+0xde/0x160 net/socket.c:2932 +do_syscall_x64 arch/x86/entry/common.c:50 [inline] +do_syscall_64+0x2b/0x70 arch/x86/entry/common.c:80 +entry_SYSCALL_64_after_hwframe+0x63/0xcd + +value changed: 0xffff88812971ce00 -> 0x0000000000000000 + +Reported by Kernel Concurrency Sanitizer on: +CPU: 0 PID: 5859 Comm: syz-executor.3 Not tainted 6.0.0-syzkaller-12189-g19d17ab7c68b-dirty #0 +Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/22/2022 + +Fixes: ab7ac4eb9832 ("kcm: Kernel Connection Multiplexor module") +Reported-by: syzbot +Signed-off-by: Eric Dumazet +Signed-off-by: David S. Miller +Signed-off-by: Sasha Levin +--- + net/kcm/kcmsock.c | 8 +++++--- + 1 file changed, 5 insertions(+), 3 deletions(-) + +diff --git a/net/kcm/kcmsock.c b/net/kcm/kcmsock.c +index 659a589b1fad..c51898ea1b38 100644 +--- a/net/kcm/kcmsock.c ++++ b/net/kcm/kcmsock.c +@@ -177,7 +177,7 @@ static void kcm_rfree(struct sk_buff *skb) + /* For reading rx_wait and rx_psock without holding lock */ + smp_mb__after_atomic(); + +- if (!kcm->rx_wait && !kcm->rx_psock && ++ if (!kcm->rx_wait && !READ_ONCE(kcm->rx_psock) && + sk_rmem_alloc_get(sk) < sk->sk_rcvlowat) { + spin_lock_bh(&mux->rx_lock); + kcm_rcv_ready(kcm); +@@ -282,7 +282,8 @@ static struct kcm_sock *reserve_rx_kcm(struct kcm_psock *psock, + kcm->rx_wait = false; + + psock->rx_kcm = kcm; +- kcm->rx_psock = psock; ++ /* paired with lockless reads in kcm_rfree() */ ++ WRITE_ONCE(kcm->rx_psock, psock); + + spin_unlock_bh(&mux->rx_lock); + +@@ -309,7 +310,8 @@ static void unreserve_rx_kcm(struct kcm_psock *psock, + spin_lock_bh(&mux->rx_lock); + + psock->rx_kcm = NULL; +- kcm->rx_psock = NULL; ++ /* paired with lockless reads in kcm_rfree() */ ++ WRITE_ONCE(kcm->rx_psock, NULL); + + /* Commit kcm->rx_psock before sk_rmem_alloc_get to sync with + * kcm_rfree +-- +2.35.1 + diff --git a/queue-5.4/kcm-annotate-data-races-around-kcm-rx_wait.patch b/queue-5.4/kcm-annotate-data-races-around-kcm-rx_wait.patch new file mode 100644 index 00000000000..13c9c492ebf --- /dev/null +++ b/queue-5.4/kcm-annotate-data-races-around-kcm-rx_wait.patch @@ -0,0 +1,130 @@ +From 684a0732c80282ab9649851b8a34c9fd62bc2245 Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Thu, 20 Oct 2022 22:45:12 +0000 +Subject: kcm: annotate data-races around kcm->rx_wait + +From: Eric Dumazet + +[ Upstream commit 0c745b5141a45a076f1cb9772a399f7ebcb0948a ] + +kcm->rx_psock can be read locklessly in kcm_rfree(). +Annotate the read and writes accordingly. + +syzbot reported: + +BUG: KCSAN: data-race in kcm_rcv_strparser / kcm_rfree + +write to 0xffff88810784e3d0 of 1 bytes by task 1823 on cpu 1: +reserve_rx_kcm net/kcm/kcmsock.c:283 [inline] +kcm_rcv_strparser+0x250/0x3a0 net/kcm/kcmsock.c:363 +__strp_recv+0x64c/0xd20 net/strparser/strparser.c:301 +strp_recv+0x6d/0x80 net/strparser/strparser.c:335 +tcp_read_sock+0x13e/0x5a0 net/ipv4/tcp.c:1703 +strp_read_sock net/strparser/strparser.c:358 [inline] +do_strp_work net/strparser/strparser.c:406 [inline] +strp_work+0xe8/0x180 net/strparser/strparser.c:415 +process_one_work+0x3d3/0x720 kernel/workqueue.c:2289 +worker_thread+0x618/0xa70 kernel/workqueue.c:2436 +kthread+0x1a9/0x1e0 kernel/kthread.c:376 +ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:306 + +read to 0xffff88810784e3d0 of 1 bytes by task 17869 on cpu 0: +kcm_rfree+0x121/0x220 net/kcm/kcmsock.c:181 +skb_release_head_state+0x8e/0x160 net/core/skbuff.c:841 +skb_release_all net/core/skbuff.c:852 [inline] +__kfree_skb net/core/skbuff.c:868 [inline] +kfree_skb_reason+0x5c/0x260 net/core/skbuff.c:891 +kfree_skb include/linux/skbuff.h:1216 [inline] +kcm_recvmsg+0x226/0x2b0 net/kcm/kcmsock.c:1161 +____sys_recvmsg+0x16c/0x2e0 +___sys_recvmsg net/socket.c:2743 [inline] +do_recvmmsg+0x2f1/0x710 net/socket.c:2837 +__sys_recvmmsg net/socket.c:2916 [inline] +__do_sys_recvmmsg net/socket.c:2939 [inline] +__se_sys_recvmmsg net/socket.c:2932 [inline] +__x64_sys_recvmmsg+0xde/0x160 net/socket.c:2932 +do_syscall_x64 arch/x86/entry/common.c:50 [inline] +do_syscall_64+0x2b/0x70 arch/x86/entry/common.c:80 +entry_SYSCALL_64_after_hwframe+0x63/0xcd + +value changed: 0x01 -> 0x00 + +Reported by Kernel Concurrency Sanitizer on: +CPU: 0 PID: 17869 Comm: syz-executor.2 Not tainted 6.1.0-rc1-syzkaller-00010-gbb1a1146467a-dirty #0 +Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/22/2022 + +Fixes: ab7ac4eb9832 ("kcm: Kernel Connection Multiplexor module") +Reported-by: syzbot +Signed-off-by: Eric Dumazet +Signed-off-by: David S. Miller +Signed-off-by: Sasha Levin +--- + net/kcm/kcmsock.c | 17 +++++++++++------ + 1 file changed, 11 insertions(+), 6 deletions(-) + +diff --git a/net/kcm/kcmsock.c b/net/kcm/kcmsock.c +index c51898ea1b38..d76c98fe9949 100644 +--- a/net/kcm/kcmsock.c ++++ b/net/kcm/kcmsock.c +@@ -161,7 +161,8 @@ static void kcm_rcv_ready(struct kcm_sock *kcm) + /* Buffer limit is okay now, add to ready list */ + list_add_tail(&kcm->wait_rx_list, + &kcm->mux->kcm_rx_waiters); +- kcm->rx_wait = true; ++ /* paired with lockless reads in kcm_rfree() */ ++ WRITE_ONCE(kcm->rx_wait, true); + } + + static void kcm_rfree(struct sk_buff *skb) +@@ -177,7 +178,7 @@ static void kcm_rfree(struct sk_buff *skb) + /* For reading rx_wait and rx_psock without holding lock */ + smp_mb__after_atomic(); + +- if (!kcm->rx_wait && !READ_ONCE(kcm->rx_psock) && ++ if (!READ_ONCE(kcm->rx_wait) && !READ_ONCE(kcm->rx_psock) && + sk_rmem_alloc_get(sk) < sk->sk_rcvlowat) { + spin_lock_bh(&mux->rx_lock); + kcm_rcv_ready(kcm); +@@ -236,7 +237,8 @@ static void requeue_rx_msgs(struct kcm_mux *mux, struct sk_buff_head *head) + if (kcm_queue_rcv_skb(&kcm->sk, skb)) { + /* Should mean socket buffer full */ + list_del(&kcm->wait_rx_list); +- kcm->rx_wait = false; ++ /* paired with lockless reads in kcm_rfree() */ ++ WRITE_ONCE(kcm->rx_wait, false); + + /* Commit rx_wait to read in kcm_free */ + smp_wmb(); +@@ -279,7 +281,8 @@ static struct kcm_sock *reserve_rx_kcm(struct kcm_psock *psock, + kcm = list_first_entry(&mux->kcm_rx_waiters, + struct kcm_sock, wait_rx_list); + list_del(&kcm->wait_rx_list); +- kcm->rx_wait = false; ++ /* paired with lockless reads in kcm_rfree() */ ++ WRITE_ONCE(kcm->rx_wait, false); + + psock->rx_kcm = kcm; + /* paired with lockless reads in kcm_rfree() */ +@@ -1243,7 +1246,8 @@ static void kcm_recv_disable(struct kcm_sock *kcm) + if (!kcm->rx_psock) { + if (kcm->rx_wait) { + list_del(&kcm->wait_rx_list); +- kcm->rx_wait = false; ++ /* paired with lockless reads in kcm_rfree() */ ++ WRITE_ONCE(kcm->rx_wait, false); + } + + requeue_rx_msgs(mux, &kcm->sk.sk_receive_queue); +@@ -1796,7 +1800,8 @@ static void kcm_done(struct kcm_sock *kcm) + + if (kcm->rx_wait) { + list_del(&kcm->wait_rx_list); +- kcm->rx_wait = false; ++ /* paired with lockless reads in kcm_rfree() */ ++ WRITE_ONCE(kcm->rx_wait, false); + } + /* Move any pending receive messages to other kcm sockets */ + requeue_rx_msgs(mux, &sk->sk_receive_queue); +-- +2.35.1 + diff --git a/queue-5.4/media-v4l2-dv-timings-add-sanity-checks-for-blanking.patch b/queue-5.4/media-v4l2-dv-timings-add-sanity-checks-for-blanking.patch new file mode 100644 index 00000000000..b971b346eb5 --- /dev/null +++ b/queue-5.4/media-v4l2-dv-timings-add-sanity-checks-for-blanking.patch @@ -0,0 +1,48 @@ +From 236f07b067e395d3987e3e8a68483ff0c6911e42 Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Thu, 13 Oct 2022 09:00:34 +0100 +Subject: media: v4l2-dv-timings: add sanity checks for blanking values + +From: Hans Verkuil + +[ Upstream commit 4b6d66a45ed34a15721cb9e11492fa1a24bc83df ] + +Add sanity checks to v4l2_valid_dv_timings() to ensure that the provided +blanking values are reasonable. + +Signed-off-by: Hans Verkuil +Fixes: b18787ed1ce3 ([media] v4l2-dv-timings: add new helper module) +Signed-off-by: Mauro Carvalho Chehab +Signed-off-by: Sasha Levin +--- + drivers/media/v4l2-core/v4l2-dv-timings.c | 14 ++++++++++++++ + 1 file changed, 14 insertions(+) + +diff --git a/drivers/media/v4l2-core/v4l2-dv-timings.c b/drivers/media/v4l2-core/v4l2-dv-timings.c +index 60454e1b727e..6d0775678f43 100644 +--- a/drivers/media/v4l2-core/v4l2-dv-timings.c ++++ b/drivers/media/v4l2-core/v4l2-dv-timings.c +@@ -161,6 +161,20 @@ bool v4l2_valid_dv_timings(const struct v4l2_dv_timings *t, + (bt->interlaced && !(caps & V4L2_DV_BT_CAP_INTERLACED)) || + (!bt->interlaced && !(caps & V4L2_DV_BT_CAP_PROGRESSIVE))) + return false; ++ ++ /* sanity checks for the blanking timings */ ++ if (!bt->interlaced && ++ (bt->il_vbackporch || bt->il_vsync || bt->il_vfrontporch)) ++ return false; ++ if (bt->hfrontporch > 2 * bt->width || ++ bt->hsync > 1024 || bt->hbackporch > 1024) ++ return false; ++ if (bt->vfrontporch > 4096 || ++ bt->vsync > 128 || bt->vbackporch > 4096) ++ return false; ++ if (bt->interlaced && (bt->il_vfrontporch > 4096 || ++ bt->il_vsync > 128 || bt->il_vbackporch > 4096)) ++ return false; + return fnc == NULL || fnc(t, fnc_handle); + } + EXPORT_SYMBOL_GPL(v4l2_valid_dv_timings); +-- +2.35.1 + diff --git a/queue-5.4/media-v4l2-fix-v4l2_i2c_subdev_set_name-function-doc.patch b/queue-5.4/media-v4l2-fix-v4l2_i2c_subdev_set_name-function-doc.patch new file mode 100644 index 00000000000..e9107ebec1b --- /dev/null +++ b/queue-5.4/media-v4l2-fix-v4l2_i2c_subdev_set_name-function-doc.patch @@ -0,0 +1,41 @@ +From c9053be446c57d37ae74101da1dc9746894823f7 Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Fri, 22 Jul 2022 09:11:31 +0200 +Subject: media: v4l2: Fix v4l2_i2c_subdev_set_name function documentation +MIME-Version: 1.0 +Content-Type: text/plain; charset=UTF-8 +Content-Transfer-Encoding: 8bit + +From: Alexander Stein + +[ Upstream commit bb9ea2c31fa11b789ade4c3abcdda3c5370a76ab ] + +The doc says the I²C device's name is used if devname is NULL, but +actually the I²C device driver's name is used. + +Fixes: 0658293012af ("media: v4l: subdev: Add a function to set an I²C sub-device's name") +Signed-off-by: Alexander Stein +Signed-off-by: Sakari Ailus +Signed-off-by: Mauro Carvalho Chehab +Signed-off-by: Sasha Levin +--- + include/media/v4l2-common.h | 3 ++- + 1 file changed, 2 insertions(+), 1 deletion(-) + +diff --git a/include/media/v4l2-common.h b/include/media/v4l2-common.h +index c070d8ae11e5..c2e9660c4d75 100644 +--- a/include/media/v4l2-common.h ++++ b/include/media/v4l2-common.h +@@ -174,7 +174,8 @@ struct v4l2_subdev *v4l2_i2c_new_subdev_board(struct v4l2_device *v4l2_dev, + * + * @sd: pointer to &struct v4l2_subdev + * @client: pointer to struct i2c_client +- * @devname: the name of the device; if NULL, the I²C device's name will be used ++ * @devname: the name of the device; if NULL, the I²C device drivers's name ++ * will be used + * @postfix: sub-device specific string to put right after the I²C device name; + * may be NULL + */ +-- +2.35.1 + diff --git a/queue-5.4/media-videodev2.h-v4l2_dv_bt_blanking_height-should-.patch b/queue-5.4/media-videodev2.h-v4l2_dv_bt_blanking_height-should-.patch new file mode 100644 index 00000000000..d558596a6bd --- /dev/null +++ b/queue-5.4/media-videodev2.h-v4l2_dv_bt_blanking_height-should-.patch @@ -0,0 +1,38 @@ +From 1156838c67e6ebc607a5d11ca73ef2896182d3e0 Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Wed, 12 Oct 2022 16:46:17 +0100 +Subject: media: videodev2.h: V4L2_DV_BT_BLANKING_HEIGHT should check + 'interlaced' + +From: Hans Verkuil + +[ Upstream commit 8da7f0976b9071b528c545008de9d10cc81883b1 ] + +If it is a progressive (non-interlaced) format, then ignore the +interlaced timing values. + +Signed-off-by: Hans Verkuil +Fixes: 7f68127fa11f ([media] videodev2.h: defines to calculate blanking and frame sizes) +Signed-off-by: Mauro Carvalho Chehab +Signed-off-by: Sasha Levin +--- + include/uapi/linux/videodev2.h | 3 ++- + 1 file changed, 2 insertions(+), 1 deletion(-) + +diff --git a/include/uapi/linux/videodev2.h b/include/uapi/linux/videodev2.h +index 3210b3c82a4a..9c89429f3113 100644 +--- a/include/uapi/linux/videodev2.h ++++ b/include/uapi/linux/videodev2.h +@@ -1496,7 +1496,8 @@ struct v4l2_bt_timings { + ((bt)->width + V4L2_DV_BT_BLANKING_WIDTH(bt)) + #define V4L2_DV_BT_BLANKING_HEIGHT(bt) \ + ((bt)->vfrontporch + (bt)->vsync + (bt)->vbackporch + \ +- (bt)->il_vfrontporch + (bt)->il_vsync + (bt)->il_vbackporch) ++ ((bt)->interlaced ? \ ++ ((bt)->il_vfrontporch + (bt)->il_vsync + (bt)->il_vbackporch) : 0)) + #define V4L2_DV_BT_FRAME_HEIGHT(bt) \ + ((bt)->height + V4L2_DV_BT_BLANKING_HEIGHT(bt)) + +-- +2.35.1 + diff --git a/queue-5.4/media-vivid-dev-bitmap_cap-wasn-t-freed-in-all-cases.patch b/queue-5.4/media-vivid-dev-bitmap_cap-wasn-t-freed-in-all-cases.patch new file mode 100644 index 00000000000..dcde6c5d82f --- /dev/null +++ b/queue-5.4/media-vivid-dev-bitmap_cap-wasn-t-freed-in-all-cases.patch @@ -0,0 +1,75 @@ +From cfecb55f35205b0ef01185d2ec098ed7aa9c10ee Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Thu, 13 Oct 2022 15:18:46 +0100 +Subject: media: vivid: dev->bitmap_cap wasn't freed in all cases + +From: Hans Verkuil + +[ Upstream commit 1f65ea411cc7b6ff128d82a3493d7b5648054e6f ] + +Whenever the compose width/height values change, the dev->bitmap_cap +vmalloc'ed array must be freed and dev->bitmap_cap set to NULL. + +This was done in some places, but not all. This is only an issue if +overlay support is enabled and the bitmap clipping is used. + +Signed-off-by: Hans Verkuil +Fixes: ef834f7836ec ([media] vivid: add the video capture and output parts) +Signed-off-by: Mauro Carvalho Chehab +Signed-off-by: Sasha Levin +--- + drivers/media/platform/vivid/vivid-vid-cap.c | 18 +++++++++++++----- + 1 file changed, 13 insertions(+), 5 deletions(-) + +diff --git a/drivers/media/platform/vivid/vivid-vid-cap.c b/drivers/media/platform/vivid/vivid-vid-cap.c +index fe7b8591f113..208807d3733f 100644 +--- a/drivers/media/platform/vivid/vivid-vid-cap.c ++++ b/drivers/media/platform/vivid/vivid-vid-cap.c +@@ -452,6 +452,12 @@ void vivid_update_format_cap(struct vivid_dev *dev, bool keep_controls) + tpg_reset_source(&dev->tpg, dev->src_rect.width, dev->src_rect.height, dev->field_cap); + dev->crop_cap = dev->src_rect; + dev->crop_bounds_cap = dev->src_rect; ++ if (dev->bitmap_cap && ++ (dev->compose_cap.width != dev->crop_cap.width || ++ dev->compose_cap.height != dev->crop_cap.height)) { ++ vfree(dev->bitmap_cap); ++ dev->bitmap_cap = NULL; ++ } + dev->compose_cap = dev->crop_cap; + if (V4L2_FIELD_HAS_T_OR_B(dev->field_cap)) + dev->compose_cap.height /= 2; +@@ -883,6 +889,8 @@ int vivid_vid_cap_s_selection(struct file *file, void *fh, struct v4l2_selection + struct vivid_dev *dev = video_drvdata(file); + struct v4l2_rect *crop = &dev->crop_cap; + struct v4l2_rect *compose = &dev->compose_cap; ++ unsigned orig_compose_w = compose->width; ++ unsigned orig_compose_h = compose->height; + unsigned factor = V4L2_FIELD_HAS_T_OR_B(dev->field_cap) ? 2 : 1; + int ret; + +@@ -999,17 +1007,17 @@ int vivid_vid_cap_s_selection(struct file *file, void *fh, struct v4l2_selection + s->r.height /= factor; + } + v4l2_rect_map_inside(&s->r, &dev->fmt_cap_rect); +- if (dev->bitmap_cap && (compose->width != s->r.width || +- compose->height != s->r.height)) { +- vfree(dev->bitmap_cap); +- dev->bitmap_cap = NULL; +- } + *compose = s->r; + break; + default: + return -EINVAL; + } + ++ if (dev->bitmap_cap && (compose->width != orig_compose_w || ++ compose->height != orig_compose_h)) { ++ vfree(dev->bitmap_cap); ++ dev->bitmap_cap = NULL; ++ } + tpg_s_crop_compose(&dev->tpg, crop, compose); + return 0; + } +-- +2.35.1 + diff --git a/queue-5.4/media-vivid-s_fbuf-add-more-sanity-checks.patch b/queue-5.4/media-vivid-s_fbuf-add-more-sanity-checks.patch new file mode 100644 index 00000000000..cdf2a5a4a04 --- /dev/null +++ b/queue-5.4/media-vivid-s_fbuf-add-more-sanity-checks.patch @@ -0,0 +1,90 @@ +From 5210d04c06010ae19458a09380a6626afbf06bd4 Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Wed, 12 Oct 2022 15:32:28 +0100 +Subject: media: vivid: s_fbuf: add more sanity checks + +From: Hans Verkuil + +[ Upstream commit f8bcaf714abfc94818dff8c0db84d750433984f4 ] + +VIDIOC_S_FBUF is by definition a scary ioctl, which is why only root +can use it. But at least check if the framebuffer parameters match that +of one of the framebuffer created by vivid, and reject anything else. + +Signed-off-by: Hans Verkuil +Fixes: ef834f7836ec ([media] vivid: add the video capture and output parts) +Signed-off-by: Mauro Carvalho Chehab +Signed-off-by: Sasha Levin +--- + drivers/media/platform/vivid/vivid-core.c | 22 ++++++++++++++++++++ + drivers/media/platform/vivid/vivid-core.h | 2 ++ + drivers/media/platform/vivid/vivid-vid-cap.c | 9 +++++++- + 3 files changed, 32 insertions(+), 1 deletion(-) + +diff --git a/drivers/media/platform/vivid/vivid-core.c b/drivers/media/platform/vivid/vivid-core.c +index cc71aa425597..f6dc2b69b62e 100644 +--- a/drivers/media/platform/vivid/vivid-core.c ++++ b/drivers/media/platform/vivid/vivid-core.c +@@ -297,6 +297,28 @@ static int vidioc_g_fbuf(struct file *file, void *fh, struct v4l2_framebuffer *a + return vivid_vid_out_g_fbuf(file, fh, a); + } + ++/* ++ * Only support the framebuffer of one of the vivid instances. ++ * Anything else is rejected. ++ */ ++bool vivid_validate_fb(const struct v4l2_framebuffer *a) ++{ ++ struct vivid_dev *dev; ++ int i; ++ ++ for (i = 0; i < n_devs; i++) { ++ dev = vivid_devs[i]; ++ if (!dev || !dev->video_pbase) ++ continue; ++ if ((unsigned long)a->base == dev->video_pbase && ++ a->fmt.width <= dev->display_width && ++ a->fmt.height <= dev->display_height && ++ a->fmt.bytesperline <= dev->display_byte_stride) ++ return true; ++ } ++ return false; ++} ++ + static int vidioc_s_fbuf(struct file *file, void *fh, const struct v4l2_framebuffer *a) + { + struct video_device *vdev = video_devdata(file); +diff --git a/drivers/media/platform/vivid/vivid-core.h b/drivers/media/platform/vivid/vivid-core.h +index 7ebb14673c75..0ab4051327d6 100644 +--- a/drivers/media/platform/vivid/vivid-core.h ++++ b/drivers/media/platform/vivid/vivid-core.h +@@ -564,4 +564,6 @@ static inline bool vivid_is_hdmi_out(const struct vivid_dev *dev) + return dev->output_type[dev->output] == HDMI; + } + ++bool vivid_validate_fb(const struct v4l2_framebuffer *a); ++ + #endif +diff --git a/drivers/media/platform/vivid/vivid-vid-cap.c b/drivers/media/platform/vivid/vivid-vid-cap.c +index 2d030732feac..fe7b8591f113 100644 +--- a/drivers/media/platform/vivid/vivid-vid-cap.c ++++ b/drivers/media/platform/vivid/vivid-vid-cap.c +@@ -1250,7 +1250,14 @@ int vivid_vid_cap_s_fbuf(struct file *file, void *fh, + return -EINVAL; + if (a->fmt.bytesperline < (a->fmt.width * fmt->bit_depth[0]) / 8) + return -EINVAL; +- if (a->fmt.height * a->fmt.bytesperline < a->fmt.sizeimage) ++ if (a->fmt.bytesperline > a->fmt.sizeimage / a->fmt.height) ++ return -EINVAL; ++ ++ /* ++ * Only support the framebuffer of one of the vivid instances. ++ * Anything else is rejected. ++ */ ++ if (!vivid_validate_fb(a)) + return -EINVAL; + + dev->fb_vbase_cap = phys_to_virt((unsigned long)a->base); +-- +2.35.1 + diff --git a/queue-5.4/net-ehea-fix-possible-memory-leak-in-ehea_register_p.patch b/queue-5.4/net-ehea-fix-possible-memory-leak-in-ehea_register_p.patch new file mode 100644 index 00000000000..f076e837519 --- /dev/null +++ b/queue-5.4/net-ehea-fix-possible-memory-leak-in-ehea_register_p.patch @@ -0,0 +1,39 @@ +From 81d302f7192a8305f8f8bdb06f8644bdc1b333a3 Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Tue, 25 Oct 2022 21:00:11 +0800 +Subject: net: ehea: fix possible memory leak in ehea_register_port() + +From: Yang Yingliang + +[ Upstream commit 0e7ce23a917a9cc83ca3c779fbba836bca3bcf1e ] + +If of_device_register() returns error, the of node and the +name allocated in dev_set_name() is leaked, call put_device() +to give up the reference that was set in device_initialize(), +so that of node is put in logical_port_release() and the name +is freed in kobject_cleanup(). + +Fixes: 1acf2318dd13 ("ehea: dynamic add / remove port") +Signed-off-by: Yang Yingliang +Link: https://lore.kernel.org/r/20221025130011.1071357-1-yangyingliang@huawei.com +Signed-off-by: Paolo Abeni +Signed-off-by: Sasha Levin +--- + drivers/net/ethernet/ibm/ehea/ehea_main.c | 1 + + 1 file changed, 1 insertion(+) + +diff --git a/drivers/net/ethernet/ibm/ehea/ehea_main.c b/drivers/net/ethernet/ibm/ehea/ehea_main.c +index 1fd2b84e2e91..1d8b84eb4aa8 100644 +--- a/drivers/net/ethernet/ibm/ehea/ehea_main.c ++++ b/drivers/net/ethernet/ibm/ehea/ehea_main.c +@@ -2897,6 +2897,7 @@ static struct device *ehea_register_port(struct ehea_port *port, + ret = of_device_register(&port->ofdev); + if (ret) { + pr_err("failed to register device. ret=%d\n", ret); ++ put_device(&port->ofdev.dev); + goto out; + } + +-- +2.35.1 + diff --git a/queue-5.4/net-enetc-survive-memory-pressure-without-crashing.patch b/queue-5.4/net-enetc-survive-memory-pressure-without-crashing.patch new file mode 100644 index 00000000000..abadd7eeab4 --- /dev/null +++ b/queue-5.4/net-enetc-survive-memory-pressure-without-crashing.patch @@ -0,0 +1,101 @@ +From ae8291442d99950bcb72abf969d1c058a67001b9 Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Thu, 27 Oct 2022 21:29:25 +0300 +Subject: net: enetc: survive memory pressure without crashing + +From: Vladimir Oltean + +[ Upstream commit 84ce1ca3fe9e1249bf21176ff162200f1c4e5ed1 ] + +Under memory pressure, enetc_refill_rx_ring() may fail, and when called +during the enetc_open() -> enetc_setup_rxbdr() procedure, this is not +checked for. + +An extreme case of memory pressure will result in exactly zero buffers +being allocated for the RX ring, and in such a case it is expected that +hardware drops all RX packets due to lack of buffers. + +This does not happen, because the reset-default value of the consumer +and produces index is 0, and this makes the ENETC think that all buffers +have been initialized and that it owns them (when in reality none were). + +The hardware guide explains this best: + +| Configure the receive ring producer index register RBaPIR with a value +| of 0. The producer index is initially configured by software but owned +| by hardware after the ring has been enabled. Hardware increments the +| index when a frame is received which may consume one or more BDs. +| Hardware is not allowed to increment the producer index to match the +| consumer index since it is used to indicate an empty condition. The ring +| can hold at most RBLENR[LENGTH]-1 received BDs. +| +| Configure the receive ring consumer index register RBaCIR. The +| consumer index is owned by software and updated during operation of the +| of the BD ring by software, to indicate that any receive data occupied +| in the BD has been processed and it has been prepared for new data. +| - If consumer index and producer index are initialized to the same +| value, it indicates that all BDs in the ring have been prepared and +| hardware owns all of the entries. +| - If consumer index is initialized to producer index plus N, it would +| indicate N BDs have been prepared. Note that hardware cannot start if +| only a single buffer is prepared due to the restrictions described in +| (2). +| - Software may write consumer index to match producer index anytime +| while the ring is operational to indicate all received BDs prior have +| been processed and new BDs prepared for hardware. + +Normally, the value of rx_ring->rcir (consumer index) is brought in sync +with the rx_ring->next_to_use software index, but this only happens if +page allocation ever succeeded. + +When PI==CI==0, the hardware appears to receive frames and write them to +DMA address 0x0 (?!), then set the READY bit in the BD. + +The enetc_clean_rx_ring() function (and its XDP derivative) is naturally +not prepared to handle such a condition. It will attempt to process +those frames using the rx_swbd structure associated with index i of the +RX ring, but that structure is not fully initialized (enetc_new_page() +does all of that). So what happens next is undefined behavior. + +To operate using no buffer, we must initialize the CI to PI + 1, which +will block the hardware from advancing the CI any further, and drop +everything. + +The issue was seen while adding support for zero-copy AF_XDP sockets, +where buffer memory comes from user space, which can even decide to +supply no buffers at all (example: "xdpsock --txonly"). However, the bug +is present also with the network stack code, even though it would take a +very determined person to trigger a page allocation failure at the +perfect time (a series of ifup/ifdown under memory pressure should +eventually reproduce it given enough retries). + +Fixes: d4fd0404c1c9 ("enetc: Introduce basic PF and VF ENETC ethernet drivers") +Signed-off-by: Vladimir Oltean +Reviewed-by: Claudiu Manoil +Link: https://lore.kernel.org/r/20221027182925.3256653-1-vladimir.oltean@nxp.com +Signed-off-by: Jakub Kicinski +Signed-off-by: Sasha Levin +--- + drivers/net/ethernet/freescale/enetc/enetc.c | 5 +++++ + 1 file changed, 5 insertions(+) + +diff --git a/drivers/net/ethernet/freescale/enetc/enetc.c b/drivers/net/ethernet/freescale/enetc/enetc.c +index cee77326e7e8..d6df2dd885c5 100644 +--- a/drivers/net/ethernet/freescale/enetc/enetc.c ++++ b/drivers/net/ethernet/freescale/enetc/enetc.c +@@ -1146,7 +1146,12 @@ static void enetc_setup_rxbdr(struct enetc_hw *hw, struct enetc_bdr *rx_ring) + + enetc_rxbdr_wr(hw, idx, ENETC_RBBSR, ENETC_RXB_DMA_SIZE); + ++ /* Also prepare the consumer index in case page allocation never ++ * succeeds. In that case, hardware will never advance producer index ++ * to match consumer index, and will drop all frames. ++ */ + enetc_rxbdr_wr(hw, idx, ENETC_RBPIR, 0); ++ enetc_rxbdr_wr(hw, idx, ENETC_RBCIR, 1); + + /* enable Rx ints by setting pkt thr to 1 */ + enetc_rxbdr_wr(hw, idx, ENETC_RBICIR0, ENETC_RBICIR0_ICEN | 0x1); +-- +2.35.1 + diff --git a/queue-5.4/net-fix-uaf-issue-in-nfqnl_nf_hook_drop-when-ops_ini.patch b/queue-5.4/net-fix-uaf-issue-in-nfqnl_nf_hook_drop-when-ops_ini.patch new file mode 100644 index 00000000000..45bc497d4f7 --- /dev/null +++ b/queue-5.4/net-fix-uaf-issue-in-nfqnl_nf_hook_drop-when-ops_ini.patch @@ -0,0 +1,121 @@ +From 3b587e7ff4edaa3db5bb576f6754d8303446c589 Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Thu, 20 Oct 2022 10:42:13 +0800 +Subject: net: fix UAF issue in nfqnl_nf_hook_drop() when ops_init() failed + +From: Zhengchao Shao + +[ Upstream commit d266935ac43d57586e311a087510fe6a084af742 ] + +When the ops_init() interface is invoked to initialize the net, but +ops->init() fails, data is released. However, the ptr pointer in +net->gen is invalid. In this case, when nfqnl_nf_hook_drop() is invoked +to release the net, invalid address access occurs. + +The process is as follows: +setup_net() + ops_init() + data = kzalloc(...) ---> alloc "data" + net_assign_generic() ---> assign "date" to ptr in net->gen + ... + ops->init() ---> failed + ... + kfree(data); ---> ptr in net->gen is invalid + ... + ops_exit_list() + ... + nfqnl_nf_hook_drop() + *q = nfnl_queue_pernet(net) ---> q is invalid + +The following is the Call Trace information: +BUG: KASAN: use-after-free in nfqnl_nf_hook_drop+0x264/0x280 +Read of size 8 at addr ffff88810396b240 by task ip/15855 +Call Trace: + +dump_stack_lvl+0x8e/0xd1 +print_report+0x155/0x454 +kasan_report+0xba/0x1f0 +nfqnl_nf_hook_drop+0x264/0x280 +nf_queue_nf_hook_drop+0x8b/0x1b0 +__nf_unregister_net_hook+0x1ae/0x5a0 +nf_unregister_net_hooks+0xde/0x130 +ops_exit_list+0xb0/0x170 +setup_net+0x7ac/0xbd0 +copy_net_ns+0x2e6/0x6b0 +create_new_namespaces+0x382/0xa50 +unshare_nsproxy_namespaces+0xa6/0x1c0 +ksys_unshare+0x3a4/0x7e0 +__x64_sys_unshare+0x2d/0x40 +do_syscall_64+0x35/0x80 +entry_SYSCALL_64_after_hwframe+0x46/0xb0 + + +Allocated by task 15855: +kasan_save_stack+0x1e/0x40 +kasan_set_track+0x21/0x30 +__kasan_kmalloc+0xa1/0xb0 +__kmalloc+0x49/0xb0 +ops_init+0xe7/0x410 +setup_net+0x5aa/0xbd0 +copy_net_ns+0x2e6/0x6b0 +create_new_namespaces+0x382/0xa50 +unshare_nsproxy_namespaces+0xa6/0x1c0 +ksys_unshare+0x3a4/0x7e0 +__x64_sys_unshare+0x2d/0x40 +do_syscall_64+0x35/0x80 +entry_SYSCALL_64_after_hwframe+0x46/0xb0 + +Freed by task 15855: +kasan_save_stack+0x1e/0x40 +kasan_set_track+0x21/0x30 +kasan_save_free_info+0x2a/0x40 +____kasan_slab_free+0x155/0x1b0 +slab_free_freelist_hook+0x11b/0x220 +__kmem_cache_free+0xa4/0x360 +ops_init+0xb9/0x410 +setup_net+0x5aa/0xbd0 +copy_net_ns+0x2e6/0x6b0 +create_new_namespaces+0x382/0xa50 +unshare_nsproxy_namespaces+0xa6/0x1c0 +ksys_unshare+0x3a4/0x7e0 +__x64_sys_unshare+0x2d/0x40 +do_syscall_64+0x35/0x80 +entry_SYSCALL_64_after_hwframe+0x46/0xb0 + +Fixes: f875bae06533 ("net: Automatically allocate per namespace data.") +Signed-off-by: Zhengchao Shao +Signed-off-by: David S. Miller +Signed-off-by: Sasha Levin +--- + net/core/net_namespace.c | 7 +++++++ + 1 file changed, 7 insertions(+) + +diff --git a/net/core/net_namespace.c b/net/core/net_namespace.c +index 62a972f04cef..b96df54d0036 100644 +--- a/net/core/net_namespace.c ++++ b/net/core/net_namespace.c +@@ -120,6 +120,7 @@ static int net_assign_generic(struct net *net, unsigned int id, void *data) + + static int ops_init(const struct pernet_operations *ops, struct net *net) + { ++ struct net_generic *ng; + int err = -ENOMEM; + void *data = NULL; + +@@ -138,7 +139,13 @@ static int ops_init(const struct pernet_operations *ops, struct net *net) + if (!err) + return 0; + ++ if (ops->id && ops->size) { + cleanup: ++ ng = rcu_dereference_protected(net->gen, ++ lockdep_is_held(&pernet_ops_rwsem)); ++ ng->ptr[*ops->id] = NULL; ++ } ++ + kfree(data); + + out: +-- +2.35.1 + diff --git a/queue-5.4/net-ksz884x-fix-missing-pci_disable_device-on-error-.patch b/queue-5.4/net-ksz884x-fix-missing-pci_disable_device-on-error-.patch new file mode 100644 index 00000000000..61b8d36368c --- /dev/null +++ b/queue-5.4/net-ksz884x-fix-missing-pci_disable_device-on-error-.patch @@ -0,0 +1,39 @@ +From 8a09e09c194eafa8f1f735cd084649ed9412fe62 Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Mon, 24 Oct 2022 21:13:38 +0800 +Subject: net: ksz884x: fix missing pci_disable_device() on error in + pcidev_init() + +From: Yang Yingliang + +[ Upstream commit 5da6d65590a0698199df44d095e54b0ed1708178 ] + +pci_disable_device() need be called while module exiting, switch to use +pcim_enable(), pci_disable_device() will be called in pcim_release() +while unbinding device. + +Fixes: 8ca86fd83eae ("net: Micrel KSZ8841/2 PCI Ethernet driver") +Signed-off-by: Yang Yingliang +Link: https://lore.kernel.org/r/20221024131338.2848959-1-yangyingliang@huawei.com +Signed-off-by: Jakub Kicinski +Signed-off-by: Sasha Levin +--- + drivers/net/ethernet/micrel/ksz884x.c | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +diff --git a/drivers/net/ethernet/micrel/ksz884x.c b/drivers/net/ethernet/micrel/ksz884x.c +index 2431723bc2fb..9ffb8880105f 100644 +--- a/drivers/net/ethernet/micrel/ksz884x.c ++++ b/drivers/net/ethernet/micrel/ksz884x.c +@@ -6928,7 +6928,7 @@ static int pcidev_init(struct pci_dev *pdev, const struct pci_device_id *id) + char banner[sizeof(version)]; + struct ksz_switch *sw = NULL; + +- result = pci_enable_device(pdev); ++ result = pcim_enable_device(pdev); + if (result) + return result; + +-- +2.35.1 + diff --git a/queue-5.4/net-lantiq_etop-don-t-free-skb-when-returning-netdev.patch b/queue-5.4/net-lantiq_etop-don-t-free-skb-when-returning-netdev.patch new file mode 100644 index 00000000000..9eabac7ea26 --- /dev/null +++ b/queue-5.4/net-lantiq_etop-don-t-free-skb-when-returning-netdev.patch @@ -0,0 +1,35 @@ +From cf7c9cd2fca6c06ba8e7ad88e1b4b7c05e00aec4 Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Fri, 21 Oct 2022 09:32:24 +0800 +Subject: net: lantiq_etop: don't free skb when returning NETDEV_TX_BUSY + +From: Zhang Changzhong + +[ Upstream commit 9c1eaa27ec599fcc25ed4970c0b73c247d147a2b ] + +The ndo_start_xmit() method must not free skb when returning +NETDEV_TX_BUSY, since caller is going to requeue freed skb. + +Fixes: 504d4721ee8e ("MIPS: Lantiq: Add ethernet driver") +Signed-off-by: Zhang Changzhong +Signed-off-by: David S. Miller +Signed-off-by: Sasha Levin +--- + drivers/net/ethernet/lantiq_etop.c | 1 - + 1 file changed, 1 deletion(-) + +diff --git a/drivers/net/ethernet/lantiq_etop.c b/drivers/net/ethernet/lantiq_etop.c +index 6e73ffe6f928..12e8b0f957d3 100644 +--- a/drivers/net/ethernet/lantiq_etop.c ++++ b/drivers/net/ethernet/lantiq_etop.c +@@ -466,7 +466,6 @@ ltq_etop_tx(struct sk_buff *skb, struct net_device *dev) + len = skb->len < ETH_ZLEN ? ETH_ZLEN : skb->len; + + if ((desc->ctl & (LTQ_DMA_OWN | LTQ_DMA_C)) || ch->skb[ch->dma.desc]) { +- dev_kfree_skb_any(skb); + netdev_err(dev, "tx ring full\n"); + netif_tx_stop_queue(txq); + return NETDEV_TX_BUSY; +-- +2.35.1 + diff --git a/queue-5.4/net-mlx5-fix-possible-use-after-free-in-async-comman.patch b/queue-5.4/net-mlx5-fix-possible-use-after-free-in-async-comman.patch new file mode 100644 index 00000000000..9d7c423101c --- /dev/null +++ b/queue-5.4/net-mlx5-fix-possible-use-after-free-in-async-comman.patch @@ -0,0 +1,212 @@ +From 1bcb109682fd3f4eaf6163f29868fe9aa82aa1bc Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Wed, 26 Oct 2022 14:51:45 +0100 +Subject: net/mlx5: Fix possible use-after-free in async command interface + +From: Tariq Toukan + +[ Upstream commit bacd22df95147ed673bec4692ab2d4d585935241 ] + +mlx5_cmd_cleanup_async_ctx should return only after all its callback +handlers were completed. Before this patch, the below race between +mlx5_cmd_cleanup_async_ctx and mlx5_cmd_exec_cb_handler was possible and +lead to a use-after-free: + +1. mlx5_cmd_cleanup_async_ctx is called while num_inflight is 2 (i.e. + elevated by 1, a single inflight callback). +2. mlx5_cmd_cleanup_async_ctx decreases num_inflight to 1. +3. mlx5_cmd_exec_cb_handler is called, decreases num_inflight to 0 and + is about to call wake_up(). +4. mlx5_cmd_cleanup_async_ctx calls wait_event, which returns + immediately as the condition (num_inflight == 0) holds. +5. mlx5_cmd_cleanup_async_ctx returns. +6. The caller of mlx5_cmd_cleanup_async_ctx frees the mlx5_async_ctx + object. +7. mlx5_cmd_exec_cb_handler goes on and calls wake_up() on the freed + object. + +Fix it by syncing using a completion object. Mark it completed when +num_inflight reaches 0. + +Trace: + +BUG: KASAN: use-after-free in do_raw_spin_lock+0x23d/0x270 +Read of size 4 at addr ffff888139cd12f4 by task swapper/5/0 + +CPU: 5 PID: 0 Comm: swapper/5 Not tainted 6.0.0-rc3_for_upstream_debug_2022_08_30_13_10 #1 +Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014 +Call Trace: + + dump_stack_lvl+0x57/0x7d + print_report.cold+0x2d5/0x684 + ? do_raw_spin_lock+0x23d/0x270 + kasan_report+0xb1/0x1a0 + ? do_raw_spin_lock+0x23d/0x270 + do_raw_spin_lock+0x23d/0x270 + ? rwlock_bug.part.0+0x90/0x90 + ? __delete_object+0xb8/0x100 + ? lock_downgrade+0x6e0/0x6e0 + _raw_spin_lock_irqsave+0x43/0x60 + ? __wake_up_common_lock+0xb9/0x140 + __wake_up_common_lock+0xb9/0x140 + ? __wake_up_common+0x650/0x650 + ? destroy_tis_callback+0x53/0x70 [mlx5_core] + ? kasan_set_track+0x21/0x30 + ? destroy_tis_callback+0x53/0x70 [mlx5_core] + ? kfree+0x1ba/0x520 + ? do_raw_spin_unlock+0x54/0x220 + mlx5_cmd_exec_cb_handler+0x136/0x1a0 [mlx5_core] + ? mlx5_cmd_cleanup_async_ctx+0x220/0x220 [mlx5_core] + ? mlx5_cmd_cleanup_async_ctx+0x220/0x220 [mlx5_core] + mlx5_cmd_comp_handler+0x65a/0x12b0 [mlx5_core] + ? dump_command+0xcc0/0xcc0 [mlx5_core] + ? lockdep_hardirqs_on_prepare+0x400/0x400 + ? cmd_comp_notifier+0x7e/0xb0 [mlx5_core] + cmd_comp_notifier+0x7e/0xb0 [mlx5_core] + atomic_notifier_call_chain+0xd7/0x1d0 + mlx5_eq_async_int+0x3ce/0xa20 [mlx5_core] + atomic_notifier_call_chain+0xd7/0x1d0 + ? irq_release+0x140/0x140 [mlx5_core] + irq_int_handler+0x19/0x30 [mlx5_core] + __handle_irq_event_percpu+0x1f2/0x620 + handle_irq_event+0xb2/0x1d0 + handle_edge_irq+0x21e/0xb00 + __common_interrupt+0x79/0x1a0 + common_interrupt+0x78/0xa0 + + + asm_common_interrupt+0x22/0x40 +RIP: 0010:default_idle+0x42/0x60 +Code: c1 83 e0 07 48 c1 e9 03 83 c0 03 0f b6 14 11 38 d0 7c 04 84 d2 75 14 8b 05 eb 47 22 02 85 c0 7e 07 0f 00 2d e0 9f 48 00 fb f4 48 c7 c7 80 08 7f 85 e8 d1 d3 3e fe eb de 66 66 2e 0f 1f 84 00 +RSP: 0018:ffff888100dbfdf0 EFLAGS: 00000242 +RAX: 0000000000000001 RBX: ffffffff84ecbd48 RCX: 1ffffffff0afe110 +RDX: 0000000000000004 RSI: 0000000000000000 RDI: ffffffff835cc9bc +RBP: 0000000000000005 R08: 0000000000000001 R09: ffff88881dec4ac3 +R10: ffffed1103bd8958 R11: 0000017d0ca571c9 R12: 0000000000000005 +R13: ffffffff84f024e0 R14: 0000000000000000 R15: dffffc0000000000 + ? default_idle_call+0xcc/0x450 + default_idle_call+0xec/0x450 + do_idle+0x394/0x450 + ? arch_cpu_idle_exit+0x40/0x40 + ? do_idle+0x17/0x450 + cpu_startup_entry+0x19/0x20 + start_secondary+0x221/0x2b0 + ? set_cpu_sibling_map+0x2070/0x2070 + secondary_startup_64_no_verify+0xcd/0xdb + + +Allocated by task 49502: + kasan_save_stack+0x1e/0x40 + __kasan_kmalloc+0x81/0xa0 + kvmalloc_node+0x48/0xe0 + mlx5e_bulk_async_init+0x35/0x110 [mlx5_core] + mlx5e_tls_priv_tx_list_cleanup+0x84/0x3e0 [mlx5_core] + mlx5e_ktls_cleanup_tx+0x38f/0x760 [mlx5_core] + mlx5e_cleanup_nic_tx+0xa7/0x100 [mlx5_core] + mlx5e_detach_netdev+0x1ca/0x2b0 [mlx5_core] + mlx5e_suspend+0xdb/0x140 [mlx5_core] + mlx5e_remove+0x89/0x190 [mlx5_core] + auxiliary_bus_remove+0x52/0x70 + device_release_driver_internal+0x40f/0x650 + driver_detach+0xc1/0x180 + bus_remove_driver+0x125/0x2f0 + auxiliary_driver_unregister+0x16/0x50 + mlx5e_cleanup+0x26/0x30 [mlx5_core] + cleanup+0xc/0x4e [mlx5_core] + __x64_sys_delete_module+0x2b5/0x450 + do_syscall_64+0x3d/0x90 + entry_SYSCALL_64_after_hwframe+0x46/0xb0 + +Freed by task 49502: + kasan_save_stack+0x1e/0x40 + kasan_set_track+0x21/0x30 + kasan_set_free_info+0x20/0x30 + ____kasan_slab_free+0x11d/0x1b0 + kfree+0x1ba/0x520 + mlx5e_tls_priv_tx_list_cleanup+0x2e7/0x3e0 [mlx5_core] + mlx5e_ktls_cleanup_tx+0x38f/0x760 [mlx5_core] + mlx5e_cleanup_nic_tx+0xa7/0x100 [mlx5_core] + mlx5e_detach_netdev+0x1ca/0x2b0 [mlx5_core] + mlx5e_suspend+0xdb/0x140 [mlx5_core] + mlx5e_remove+0x89/0x190 [mlx5_core] + auxiliary_bus_remove+0x52/0x70 + device_release_driver_internal+0x40f/0x650 + driver_detach+0xc1/0x180 + bus_remove_driver+0x125/0x2f0 + auxiliary_driver_unregister+0x16/0x50 + mlx5e_cleanup+0x26/0x30 [mlx5_core] + cleanup+0xc/0x4e [mlx5_core] + __x64_sys_delete_module+0x2b5/0x450 + do_syscall_64+0x3d/0x90 + entry_SYSCALL_64_after_hwframe+0x46/0xb0 + +Fixes: e355477ed9e4 ("net/mlx5: Make mlx5_cmd_exec_cb() a safe API") +Signed-off-by: Tariq Toukan +Reviewed-by: Moshe Shemesh +Signed-off-by: Saeed Mahameed +Link: https://lore.kernel.org/r/20221026135153.154807-8-saeed@kernel.org +Signed-off-by: Jakub Kicinski +Signed-off-by: Sasha Levin +--- + drivers/net/ethernet/mellanox/mlx5/core/cmd.c | 10 +++++----- + include/linux/mlx5/driver.h | 2 +- + 2 files changed, 6 insertions(+), 6 deletions(-) + +diff --git a/drivers/net/ethernet/mellanox/mlx5/core/cmd.c b/drivers/net/ethernet/mellanox/mlx5/core/cmd.c +index 6c7b364d0bf0..4fdc97304f69 100644 +--- a/drivers/net/ethernet/mellanox/mlx5/core/cmd.c ++++ b/drivers/net/ethernet/mellanox/mlx5/core/cmd.c +@@ -1850,7 +1850,7 @@ void mlx5_cmd_init_async_ctx(struct mlx5_core_dev *dev, + ctx->dev = dev; + /* Starts at 1 to avoid doing wake_up if we are not cleaning up */ + atomic_set(&ctx->num_inflight, 1); +- init_waitqueue_head(&ctx->wait); ++ init_completion(&ctx->inflight_done); + } + EXPORT_SYMBOL(mlx5_cmd_init_async_ctx); + +@@ -1864,8 +1864,8 @@ EXPORT_SYMBOL(mlx5_cmd_init_async_ctx); + */ + void mlx5_cmd_cleanup_async_ctx(struct mlx5_async_ctx *ctx) + { +- atomic_dec(&ctx->num_inflight); +- wait_event(ctx->wait, atomic_read(&ctx->num_inflight) == 0); ++ if (!atomic_dec_and_test(&ctx->num_inflight)) ++ wait_for_completion(&ctx->inflight_done); + } + EXPORT_SYMBOL(mlx5_cmd_cleanup_async_ctx); + +@@ -1876,7 +1876,7 @@ static void mlx5_cmd_exec_cb_handler(int status, void *_work) + + work->user_callback(status, work); + if (atomic_dec_and_test(&ctx->num_inflight)) +- wake_up(&ctx->wait); ++ complete(&ctx->inflight_done); + } + + int mlx5_cmd_exec_cb(struct mlx5_async_ctx *ctx, void *in, int in_size, +@@ -1892,7 +1892,7 @@ int mlx5_cmd_exec_cb(struct mlx5_async_ctx *ctx, void *in, int in_size, + ret = cmd_exec(ctx->dev, in, in_size, out, out_size, + mlx5_cmd_exec_cb_handler, work, false); + if (ret && atomic_dec_and_test(&ctx->num_inflight)) +- wake_up(&ctx->wait); ++ complete(&ctx->inflight_done); + + return ret; + } +diff --git a/include/linux/mlx5/driver.h b/include/linux/mlx5/driver.h +index 2b65ffb3bd76..3a19b9202a12 100644 +--- a/include/linux/mlx5/driver.h ++++ b/include/linux/mlx5/driver.h +@@ -904,7 +904,7 @@ void mlx5_cmd_allowed_opcode(struct mlx5_core_dev *dev, u16 opcode); + struct mlx5_async_ctx { + struct mlx5_core_dev *dev; + atomic_t num_inflight; +- struct wait_queue_head wait; ++ struct completion inflight_done; + }; + + struct mlx5_async_work; +-- +2.35.1 + diff --git a/queue-5.4/net-mlx5e-do-not-increment-esn-when-updating-ipsec-e.patch b/queue-5.4/net-mlx5e-do-not-increment-esn-when-updating-ipsec-e.patch new file mode 100644 index 00000000000..e5e3040e55d --- /dev/null +++ b/queue-5.4/net-mlx5e-do-not-increment-esn-when-updating-ipsec-e.patch @@ -0,0 +1,75 @@ +From 392d1a55305c1e933ded49d40846cd16a4bb9f63 Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Wed, 26 Oct 2022 14:51:39 +0100 +Subject: net/mlx5e: Do not increment ESN when updating IPsec ESN state + +From: Hyong Youb Kim + +[ Upstream commit 888be6b279b7257b5f6e4c9527675bff0a335596 ] + +An offloaded SA stops receiving after about 2^32 + replay_window +packets. For example, when SA reaches , all +subsequent packets get dropped with SA-icv-failure (integrity_failed). + +To reproduce the bug: +- ConnectX-6 Dx with crypto enabled (FW 22.30.1004) +- ipsec.conf: + nic-offload = yes + replay-window = 32 + esn = yes + salifetime=24h +- Run netperf for a long time to send more than 2^32 packets + netperf -H -t TCP_STREAM -l 20000 + +When 2^32 + replay_window packets are received, the replay window +moves from the 2nd half of subspace (overlap=1) to the 1st half +(overlap=0). The driver then updates the 'esn' value in NIC +(i.e. seq_hi) as follows. + + seq_hi = xfrm_replay_seqhi(seq_bottom) + new esn in NIC = seq_hi + 1 + +The +1 increment is wrong, as seq_hi already contains the correct +seq_hi. For example, when seq_hi=1, the driver actually tells NIC to +use seq_hi=2 (esn). This incorrect esn value causes all subsequent +packets to fail integrity checks (SA-icv-failure). So, do not +increment. + +Fixes: cb01008390bb ("net/mlx5: IPSec, Add support for ESN") +Signed-off-by: Hyong Youb Kim +Acked-by: Leon Romanovsky +Signed-off-by: Saeed Mahameed +Link: https://lore.kernel.org/r/20221026135153.154807-2-saeed@kernel.org +Signed-off-by: Jakub Kicinski +Signed-off-by: Sasha Levin +--- + drivers/net/ethernet/mellanox/mlx5/core/en_accel/ipsec.c | 3 --- + 1 file changed, 3 deletions(-) + +diff --git a/drivers/net/ethernet/mellanox/mlx5/core/en_accel/ipsec.c b/drivers/net/ethernet/mellanox/mlx5/core/en_accel/ipsec.c +index c467f5e981f6..70087f2542b2 100644 +--- a/drivers/net/ethernet/mellanox/mlx5/core/en_accel/ipsec.c ++++ b/drivers/net/ethernet/mellanox/mlx5/core/en_accel/ipsec.c +@@ -117,7 +117,6 @@ static bool mlx5e_ipsec_update_esn_state(struct mlx5e_ipsec_sa_entry *sa_entry) + struct xfrm_replay_state_esn *replay_esn; + u32 seq_bottom; + u8 overlap; +- u32 *esn; + + if (!(sa_entry->x->props.flags & XFRM_STATE_ESN)) { + sa_entry->esn_state.trigger = 0; +@@ -130,11 +129,9 @@ static bool mlx5e_ipsec_update_esn_state(struct mlx5e_ipsec_sa_entry *sa_entry) + + sa_entry->esn_state.esn = xfrm_replay_seqhi(sa_entry->x, + htonl(seq_bottom)); +- esn = &sa_entry->esn_state.esn; + + sa_entry->esn_state.trigger = 1; + if (unlikely(overlap && seq_bottom < MLX5E_IPSEC_ESN_SCOPE_MID)) { +- ++(*esn); + sa_entry->esn_state.overlap = 0; + return true; + } else if (unlikely(!overlap && +-- +2.35.1 + diff --git a/queue-5.4/net-netsec-fix-error-handling-in-netsec_register_mdi.patch b/queue-5.4/net-netsec-fix-error-handling-in-netsec_register_mdi.patch new file mode 100644 index 00000000000..2babc290c39 --- /dev/null +++ b/queue-5.4/net-netsec-fix-error-handling-in-netsec_register_mdi.patch @@ -0,0 +1,46 @@ +From 692911822ab0397663359bfd16ee50cfe67d1977 Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Wed, 19 Oct 2022 14:41:04 +0800 +Subject: net: netsec: fix error handling in netsec_register_mdio() + +From: Yang Yingliang + +[ Upstream commit 94423589689124e8cd145b38a1034be7f25835b2 ] + +If phy_device_register() fails, phy_device_free() need be called to +put refcount, so memory of phy device and device name can be freed +in callback function. + +If get_phy_device() fails, mdiobus_unregister() need be called, +or it will cause warning in mdiobus_free() and kobject is leaked. + +Fixes: 533dd11a12f6 ("net: socionext: Add Synquacer NetSec driver") +Signed-off-by: Yang Yingliang +Link: https://lore.kernel.org/r/20221019064104.3228892-1-yangyingliang@huawei.com +Signed-off-by: Jakub Kicinski +Signed-off-by: Sasha Levin +--- + drivers/net/ethernet/socionext/netsec.c | 2 ++ + 1 file changed, 2 insertions(+) + +diff --git a/drivers/net/ethernet/socionext/netsec.c b/drivers/net/ethernet/socionext/netsec.c +index 33d7c2940ba9..5a672658da80 100644 +--- a/drivers/net/ethernet/socionext/netsec.c ++++ b/drivers/net/ethernet/socionext/netsec.c +@@ -1936,11 +1936,13 @@ static int netsec_register_mdio(struct netsec_priv *priv, u32 phy_addr) + ret = PTR_ERR(priv->phydev); + dev_err(priv->dev, "get_phy_device err(%d)\n", ret); + priv->phydev = NULL; ++ mdiobus_unregister(bus); + return -ENODEV; + } + + ret = phy_device_register(priv->phydev); + if (ret) { ++ phy_device_free(priv->phydev); + mdiobus_unregister(bus); + dev_err(priv->dev, + "phy_device_register err(%d)\n", ret); +-- +2.35.1 + diff --git a/queue-5.4/nh-fix-scope-used-to-find-saddr-when-adding-non-gw-n.patch b/queue-5.4/nh-fix-scope-used-to-find-saddr-when-adding-non-gw-n.patch new file mode 100644 index 00000000000..733e59c4c37 --- /dev/null +++ b/queue-5.4/nh-fix-scope-used-to-find-saddr-when-adding-non-gw-n.patch @@ -0,0 +1,42 @@ +From 69af5bdaace94f7829c311d40ffbf9e41415f36a Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Thu, 20 Oct 2022 12:09:52 +0200 +Subject: nh: fix scope used to find saddr when adding non gw nh + +From: Nicolas Dichtel + +[ Upstream commit bac0f937c343d651874f83b265ca8f5070ed4f06 ] + +As explained by Julian, fib_nh_scope is related to fib_nh_gw4, but +fib_info_update_nhc_saddr() needs the scope of the route, which is +the scope "before" fib_nh_scope, ie fib_nh_scope - 1. + +This patch fixes the problem described in commit 747c14307214 ("ip: fix +dflt addr selection for connected nexthop"). + +Fixes: 597cfe4fc339 ("nexthop: Add support for IPv4 nexthops") +Link: https://lore.kernel.org/netdev/6c8a44ba-c2d5-cdf-c5c7-5baf97cba38@ssi.bg/ +Signed-off-by: Nicolas Dichtel +Reviewed-by: Julian Anastasov +Signed-off-by: Jakub Kicinski +Signed-off-by: Sasha Levin +--- + net/ipv4/nexthop.c | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +diff --git a/net/ipv4/nexthop.c b/net/ipv4/nexthop.c +index 4d69b3de980a..0137854a7faa 100644 +--- a/net/ipv4/nexthop.c ++++ b/net/ipv4/nexthop.c +@@ -1222,7 +1222,7 @@ static int nh_create_ipv4(struct net *net, struct nexthop *nh, + if (!err) { + nh->nh_flags = fib_nh->fib_nh_flags; + fib_info_update_nhc_saddr(net, &fib_nh->nh_common, +- fib_nh->fib_nh_scope); ++ !fib_nh->fib_nh_scope ? 0 : fib_nh->fib_nh_scope - 1); + } else { + fib_nh_release(net, fib_nh); + } +-- +2.35.1 + diff --git a/queue-5.4/openvswitch-switch-from-warn-to-pr_warn.patch b/queue-5.4/openvswitch-switch-from-warn-to-pr_warn.patch new file mode 100644 index 00000000000..d689f2f3096 --- /dev/null +++ b/queue-5.4/openvswitch-switch-from-warn-to-pr_warn.patch @@ -0,0 +1,42 @@ +From a420ff86e5025c322bf3afde65eb9482a1143bed Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Tue, 25 Oct 2022 06:50:17 -0400 +Subject: openvswitch: switch from WARN to pr_warn + +From: Aaron Conole + +[ Upstream commit fd954cc1919e35cb92f78671cab6e42d661945a3 ] + +As noted by Paolo Abeni, pr_warn doesn't generate any splat and can still +preserve the warning to the user that feature downgrade occurred. We +likely cannot introduce other kinds of checks / enforcement here because +syzbot can generate different genl versions to the datapath. + +Reported-by: syzbot+31cde0bef4bbf8ba2d86@syzkaller.appspotmail.com +Fixes: 44da5ae5fbea ("openvswitch: Drop user features if old user space attempted to create datapath") +Cc: Thomas Graf +Signed-off-by: Aaron Conole +Acked-by: Ilya Maximets +Signed-off-by: Paolo Abeni +Signed-off-by: Sasha Levin +--- + net/openvswitch/datapath.c | 3 ++- + 1 file changed, 2 insertions(+), 1 deletion(-) + +diff --git a/net/openvswitch/datapath.c b/net/openvswitch/datapath.c +index 41035ce0d23c..5dc517d64965 100644 +--- a/net/openvswitch/datapath.c ++++ b/net/openvswitch/datapath.c +@@ -1560,7 +1560,8 @@ static void ovs_dp_reset_user_features(struct sk_buff *skb, struct genl_info *in + if (IS_ERR(dp)) + return; + +- WARN(dp->user_features, "Dropping previously announced user features\n"); ++ pr_warn("%s: Dropping previously announced user features\n", ++ ovs_dp_name(dp)); + dp->user_features = 0; + } + +-- +2.35.1 + diff --git a/queue-5.4/pm-domains-fix-handling-of-unavailable-disabled-idle.patch b/queue-5.4/pm-domains-fix-handling-of-unavailable-disabled-idle.patch new file mode 100644 index 00000000000..63324313e58 --- /dev/null +++ b/queue-5.4/pm-domains-fix-handling-of-unavailable-disabled-idle.patch @@ -0,0 +1,44 @@ +From a98043e78a8cd742d76016eccaab20f40e67ef1d Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Tue, 25 Oct 2022 13:34:32 +0100 +Subject: PM: domains: Fix handling of unavailable/disabled idle states + +From: Sudeep Holla + +[ Upstream commit e0c57a5c70c13317238cb19a7ded0eab4a5f7de5 ] + +Platforms can provide the information about the availability of each +idle states via status flag. Platforms may have to disable one or more +idle states for various reasons like broken firmware or other unmet +dependencies. + +Fix handling of such unavailable/disabled idle states by ignoring them +while parsing the states. + +Fixes: a3381e3a65cb ("PM / domains: Fix up domain-idle-states OF parsing") +Signed-off-by: Sudeep Holla +Reviewed-by: Ulf Hansson +Signed-off-by: Rafael J. Wysocki +Signed-off-by: Sasha Levin +--- + drivers/base/power/domain.c | 4 ++++ + 1 file changed, 4 insertions(+) + +diff --git a/drivers/base/power/domain.c b/drivers/base/power/domain.c +index 8428d02cfe58..4f63a8bc7260 100644 +--- a/drivers/base/power/domain.c ++++ b/drivers/base/power/domain.c +@@ -2622,6 +2622,10 @@ static int genpd_iterate_idle_states(struct device_node *dn, + np = it.node; + if (!of_match_node(idle_state_match, np)) + continue; ++ ++ if (!of_device_is_available(np)) ++ continue; ++ + if (states) { + ret = genpd_parse_state(&states[i], np); + if (ret) { +-- +2.35.1 + diff --git a/queue-5.4/pm-hibernate-allow-hybrid-sleep-to-work-with-s2idle.patch b/queue-5.4/pm-hibernate-allow-hybrid-sleep-to-work-with-s2idle.patch new file mode 100644 index 00000000000..f23da0495d9 --- /dev/null +++ b/queue-5.4/pm-hibernate-allow-hybrid-sleep-to-work-with-s2idle.patch @@ -0,0 +1,43 @@ +From faa83def986a158e54545292da60fd890957122d Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Wed, 12 Oct 2022 22:50:17 -0500 +Subject: PM: hibernate: Allow hybrid sleep to work with s2idle + +From: Mario Limonciello + +[ Upstream commit 85850af4fc47132f3f2f0dd698b90f67906600b4 ] + +Hybrid sleep is currently hardcoded to only operate with S3 even +on systems that might not support it. + +Instead of assuming this mode is what the user wants to use, for +hybrid sleep follow the setting of `mem_sleep_current` which +will respect mem_sleep_default kernel command line and policy +decisions made by the presence of the FADT low power idle bit. + +Fixes: 81d45bdf8913 ("PM / hibernate: Untangle power_down()") +Reported-and-tested-by: kolAflash +Link: https://bugzilla.kernel.org/show_bug.cgi?id=216574 +Signed-off-by: Mario Limonciello +Signed-off-by: Rafael J. Wysocki +Signed-off-by: Sasha Levin +--- + kernel/power/hibernate.c | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +diff --git a/kernel/power/hibernate.c b/kernel/power/hibernate.c +index 406b4cbbec5e..f8934f9746e6 100644 +--- a/kernel/power/hibernate.c ++++ b/kernel/power/hibernate.c +@@ -625,7 +625,7 @@ static void power_down(void) + int error; + + if (hibernation_mode == HIBERNATION_SUSPEND) { +- error = suspend_devices_and_enter(PM_SUSPEND_MEM); ++ error = suspend_devices_and_enter(mem_sleep_current); + if (error) { + hibernation_mode = hibernation_ops ? + HIBERNATION_PLATFORM : +-- +2.35.1 + diff --git a/queue-5.4/series b/queue-5.4/series index f22708a4857..27eb28bad33 100644 --- a/queue-5.4/series +++ b/queue-5.4/series @@ -28,3 +28,36 @@ xen-gntdev-prevent-leaking-grants.patch cgroup-v1-add-disabled-controller-check-in-cgroup1_parse_param.patch mm-hugetlb-take-hugetlb_lock-before-decrementing-h-resv_huge_pages.patch net-ieee802154-fix-error-return-code-in-dgram_bind.patch +media-v4l2-fix-v4l2_i2c_subdev_set_name-function-doc.patch +drm-msm-fix-return-type-of-mdp4_lvds_connector_mode_.patch +arc-iounmap-arg-is-volatile.patch +alsa-ac97-fix-possible-memory-leak-in-snd_ac97_dev_r.patch +tipc-fix-a-null-ptr-deref-in-tipc_topsrv_accept.patch +net-netsec-fix-error-handling-in-netsec_register_mdi.patch +x86-unwind-orc-fix-unreliable-stack-dump-with-gcov.patch +amd-xgbe-fix-the-sfp-compliance-codes-check-for-dac-.patch +amd-xgbe-add-the-bit-rate-quirk-for-molex-cables.patch +kcm-annotate-data-races-around-kcm-rx_psock.patch +kcm-annotate-data-races-around-kcm-rx_wait.patch +net-fix-uaf-issue-in-nfqnl_nf_hook_drop-when-ops_ini.patch +net-lantiq_etop-don-t-free-skb-when-returning-netdev.patch +tcp-fix-indefinite-deferral-of-rto-with-sack-renegin.patch +can-mscan-mpc5xxx-mpc5xxx_can_probe-add-missing-put_.patch +pm-hibernate-allow-hybrid-sleep-to-work-with-s2idle.patch +media-vivid-s_fbuf-add-more-sanity-checks.patch +media-vivid-dev-bitmap_cap-wasn-t-freed-in-all-cases.patch +media-v4l2-dv-timings-add-sanity-checks-for-blanking.patch +media-videodev2.h-v4l2_dv_bt_blanking_height-should-.patch +i40e-fix-ethtool-rx-flow-hash-setting-for-x722.patch +i40e-fix-vf-hang-when-reset-is-triggered-on-another-.patch +i40e-fix-flow-type-by-setting-gl_hash_inset-register.patch +net-ksz884x-fix-missing-pci_disable_device-on-error-.patch +pm-domains-fix-handling-of-unavailable-disabled-idle.patch +alsa-aoa-i2sbus-fix-possible-memory-leak-in-i2sbus_a.patch +alsa-aoa-fix-i2s-device-accounting.patch +openvswitch-switch-from-warn-to-pr_warn.patch +net-ehea-fix-possible-memory-leak-in-ehea_register_p.patch +nh-fix-scope-used-to-find-saddr-when-adding-non-gw-n.patch +net-mlx5e-do-not-increment-esn-when-updating-ipsec-e.patch +net-mlx5-fix-possible-use-after-free-in-async-comman.patch +net-enetc-survive-memory-pressure-without-crashing.patch diff --git a/queue-5.4/tcp-fix-indefinite-deferral-of-rto-with-sack-renegin.patch b/queue-5.4/tcp-fix-indefinite-deferral-of-rto-with-sack-renegin.patch new file mode 100644 index 00000000000..98b2754933c --- /dev/null +++ b/queue-5.4/tcp-fix-indefinite-deferral-of-rto-with-sack-renegin.patch @@ -0,0 +1,65 @@ +From 10bc4b92898b48e99f21c2e5f95814102c5c03f8 Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Fri, 21 Oct 2022 17:08:21 +0000 +Subject: tcp: fix indefinite deferral of RTO with SACK reneging + +From: Neal Cardwell + +[ Upstream commit 3d2af9cce3133b3bc596a9d065c6f9d93419ccfb ] + +This commit fixes a bug that can cause a TCP data sender to repeatedly +defer RTOs when encountering SACK reneging. + +The bug is that when we're in fast recovery in a scenario with SACK +reneging, every time we get an ACK we call tcp_check_sack_reneging() +and it can note the apparent SACK reneging and rearm the RTO timer for +srtt/2 into the future. In some SACK reneging scenarios that can +happen repeatedly until the receive window fills up, at which point +the sender can't send any more, the ACKs stop arriving, and the RTO +fires at srtt/2 after the last ACK. But that can take far too long +(O(10 secs)), since the connection is stuck in fast recovery with a +low cwnd that cannot grow beyond ssthresh, even if more bandwidth is +available. + +This fix changes the logic in tcp_check_sack_reneging() to only rearm +the RTO timer if data is cumulatively ACKed, indicating forward +progress. This avoids this kind of nearly infinite loop of RTO timer +re-arming. In addition, this meets the goals of +tcp_check_sack_reneging() in handling Windows TCP behavior that looks +temporarily like SACK reneging but is not really. + +Many thanks to Jakub Kicinski and Neil Spring, who reported this issue +and provided critical packet traces that enabled root-causing this +issue. Also, many thanks to Jakub Kicinski for testing this fix. + +Fixes: 5ae344c949e7 ("tcp: reduce spurious retransmits due to transient SACK reneging") +Reported-by: Jakub Kicinski +Reported-by: Neil Spring +Signed-off-by: Neal Cardwell +Reviewed-by: Eric Dumazet +Cc: Yuchung Cheng +Tested-by: Jakub Kicinski +Link: https://lore.kernel.org/r/20221021170821.1093930-1-ncardwell.kernel@gmail.com +Signed-off-by: Jakub Kicinski +Signed-off-by: Sasha Levin +--- + net/ipv4/tcp_input.c | 3 ++- + 1 file changed, 2 insertions(+), 1 deletion(-) + +diff --git a/net/ipv4/tcp_input.c b/net/ipv4/tcp_input.c +index 12585546ed15..44398317f033 100644 +--- a/net/ipv4/tcp_input.c ++++ b/net/ipv4/tcp_input.c +@@ -2047,7 +2047,8 @@ void tcp_enter_loss(struct sock *sk) + */ + static bool tcp_check_sack_reneging(struct sock *sk, int flag) + { +- if (flag & FLAG_SACK_RENEGING) { ++ if (flag & FLAG_SACK_RENEGING && ++ flag & FLAG_SND_UNA_ADVANCED) { + struct tcp_sock *tp = tcp_sk(sk); + unsigned long delay = max(usecs_to_jiffies(tp->srtt_us >> 4), + msecs_to_jiffies(10)); +-- +2.35.1 + diff --git a/queue-5.4/tipc-fix-a-null-ptr-deref-in-tipc_topsrv_accept.patch b/queue-5.4/tipc-fix-a-null-ptr-deref-in-tipc_topsrv_accept.patch new file mode 100644 index 00000000000..afdb22f10ab --- /dev/null +++ b/queue-5.4/tipc-fix-a-null-ptr-deref-in-tipc_topsrv_accept.patch @@ -0,0 +1,98 @@ +From ea3be412f0eb8841c323f15cfd902f1da7fe6b76 Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Tue, 18 Oct 2022 15:19:50 -0400 +Subject: tipc: fix a null-ptr-deref in tipc_topsrv_accept + +From: Xin Long + +[ Upstream commit 82cb4e4612c633a9ce320e1773114875604a3cce ] + +syzbot found a crash in tipc_topsrv_accept: + + KASAN: null-ptr-deref in range [0x0000000000000008-0x000000000000000f] + Workqueue: tipc_rcv tipc_topsrv_accept + RIP: 0010:kernel_accept+0x22d/0x350 net/socket.c:3487 + Call Trace: + + tipc_topsrv_accept+0x197/0x280 net/tipc/topsrv.c:460 + process_one_work+0x991/0x1610 kernel/workqueue.c:2289 + worker_thread+0x665/0x1080 kernel/workqueue.c:2436 + kthread+0x2e4/0x3a0 kernel/kthread.c:376 + ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:306 + +It was caused by srv->listener that might be set to null by +tipc_topsrv_stop() in net .exit whereas it's still used in +tipc_topsrv_accept() worker. + +srv->listener is protected by srv->idr_lock in tipc_topsrv_stop(), so add +a check for srv->listener under srv->idr_lock in tipc_topsrv_accept() to +avoid the null-ptr-deref. To ensure the lsock is not released during the +tipc_topsrv_accept(), move sock_release() after tipc_topsrv_work_stop() +where it's waiting until the tipc_topsrv_accept worker to be done. + +Note that sk_callback_lock is used to protect sk->sk_user_data instead of +srv->listener, and it should check srv in tipc_topsrv_listener_data_ready() +instead. This also ensures that no more tipc_topsrv_accept worker will be +started after tipc_conn_close() is called in tipc_topsrv_stop() where it +sets sk->sk_user_data to null. + +Fixes: 0ef897be12b8 ("tipc: separate topology server listener socket from subcsriber sockets") +Reported-by: syzbot+c5ce866a8d30f4be0651@syzkaller.appspotmail.com +Signed-off-by: Xin Long +Acked-by: Jon Maloy +Link: https://lore.kernel.org/r/4eee264380c409c61c6451af1059b7fb271a7e7b.1666120790.git.lucien.xin@gmail.com +Signed-off-by: Jakub Kicinski +Signed-off-by: Sasha Levin +--- + net/tipc/topsrv.c | 16 ++++++++++++---- + 1 file changed, 12 insertions(+), 4 deletions(-) + +diff --git a/net/tipc/topsrv.c b/net/tipc/topsrv.c +index b8797ff153e6..1c5319678f28 100644 +--- a/net/tipc/topsrv.c ++++ b/net/tipc/topsrv.c +@@ -450,12 +450,19 @@ static void tipc_conn_data_ready(struct sock *sk) + static void tipc_topsrv_accept(struct work_struct *work) + { + struct tipc_topsrv *srv = container_of(work, struct tipc_topsrv, awork); +- struct socket *lsock = srv->listener; +- struct socket *newsock; ++ struct socket *newsock, *lsock; + struct tipc_conn *con; + struct sock *newsk; + int ret; + ++ spin_lock_bh(&srv->idr_lock); ++ if (!srv->listener) { ++ spin_unlock_bh(&srv->idr_lock); ++ return; ++ } ++ lsock = srv->listener; ++ spin_unlock_bh(&srv->idr_lock); ++ + while (1) { + ret = kernel_accept(lsock, &newsock, O_NONBLOCK); + if (ret < 0) +@@ -489,7 +496,7 @@ static void tipc_topsrv_listener_data_ready(struct sock *sk) + + read_lock_bh(&sk->sk_callback_lock); + srv = sk->sk_user_data; +- if (srv->listener) ++ if (srv) + queue_work(srv->rcv_wq, &srv->awork); + read_unlock_bh(&sk->sk_callback_lock); + } +@@ -699,8 +706,9 @@ static void tipc_topsrv_stop(struct net *net) + __module_get(lsock->sk->sk_prot_creator->owner); + srv->listener = NULL; + spin_unlock_bh(&srv->idr_lock); +- sock_release(lsock); ++ + tipc_topsrv_work_stop(srv); ++ sock_release(lsock); + idr_destroy(&srv->conn_idr); + kfree(srv); + } +-- +2.35.1 + diff --git a/queue-5.4/x86-unwind-orc-fix-unreliable-stack-dump-with-gcov.patch b/queue-5.4/x86-unwind-orc-fix-unreliable-stack-dump-with-gcov.patch new file mode 100644 index 00000000000..8edccdfce8b --- /dev/null +++ b/queue-5.4/x86-unwind-orc-fix-unreliable-stack-dump-with-gcov.patch @@ -0,0 +1,80 @@ +From 7007e63b702c84cfaf395097cb2602ea472bebaa Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Wed, 27 Jul 2022 11:15:06 +0800 +Subject: x86/unwind/orc: Fix unreliable stack dump with gcov + +From: Chen Zhongjin + +[ Upstream commit 230db82413c091bc16acee72650f48d419cebe49 ] + +When a console stack dump is initiated with CONFIG_GCOV_PROFILE_ALL +enabled, show_trace_log_lvl() gets out of sync with the ORC unwinder, +causing the stack trace to show all text addresses as unreliable: + + # echo l > /proc/sysrq-trigger + [ 477.521031] sysrq: Show backtrace of all active CPUs + [ 477.523813] NMI backtrace for cpu 0 + [ 477.524492] CPU: 0 PID: 1021 Comm: bash Not tainted 6.0.0 #65 + [ 477.525295] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.0-1.fc36 04/01/2014 + [ 477.526439] Call Trace: + [ 477.526854] + [ 477.527216] ? dump_stack_lvl+0xc7/0x114 + [ 477.527801] ? dump_stack+0x13/0x1f + [ 477.528331] ? nmi_cpu_backtrace.cold+0xb5/0x10d + [ 477.528998] ? lapic_can_unplug_cpu+0xa0/0xa0 + [ 477.529641] ? nmi_trigger_cpumask_backtrace+0x16a/0x1f0 + [ 477.530393] ? arch_trigger_cpumask_backtrace+0x1d/0x30 + [ 477.531136] ? sysrq_handle_showallcpus+0x1b/0x30 + [ 477.531818] ? __handle_sysrq.cold+0x4e/0x1ae + [ 477.532451] ? write_sysrq_trigger+0x63/0x80 + [ 477.533080] ? proc_reg_write+0x92/0x110 + [ 477.533663] ? vfs_write+0x174/0x530 + [ 477.534265] ? handle_mm_fault+0x16f/0x500 + [ 477.534940] ? ksys_write+0x7b/0x170 + [ 477.535543] ? __x64_sys_write+0x1d/0x30 + [ 477.536191] ? do_syscall_64+0x6b/0x100 + [ 477.536809] ? entry_SYSCALL_64_after_hwframe+0x63/0xcd + [ 477.537609] + +This happens when the compiled code for show_stack() has a single word +on the stack, and doesn't use a tail call to show_stack_log_lvl(). +(CONFIG_GCOV_PROFILE_ALL=y is the only known case of this.) Then the +__unwind_start() skip logic hits an off-by-one bug and fails to unwind +all the way to the intended starting frame. + +Fix it by reverting the following commit: + + f1d9a2abff66 ("x86/unwind/orc: Don't skip the first frame for inactive tasks") + +The original justification for that commit no longer exists. That +original issue was later fixed in a different way, with the following +commit: + + f2ac57a4c49d ("x86/unwind/orc: Fix inactive tasks with stack pointer in %sp on GCC 10 compiled kernels") + +Fixes: f1d9a2abff66 ("x86/unwind/orc: Don't skip the first frame for inactive tasks") +Signed-off-by: Chen Zhongjin +[jpoimboe: rewrite commit log] +Signed-off-by: Josh Poimboeuf +Signed-off-by: Peter Zijlstra +Signed-off-by: Sasha Levin +--- + arch/x86/kernel/unwind_orc.c | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +diff --git a/arch/x86/kernel/unwind_orc.c b/arch/x86/kernel/unwind_orc.c +index 4e7c49fcf003..c85634152d30 100644 +--- a/arch/x86/kernel/unwind_orc.c ++++ b/arch/x86/kernel/unwind_orc.c +@@ -687,7 +687,7 @@ void __unwind_start(struct unwind_state *state, struct task_struct *task, + /* Otherwise, skip ahead to the user-specified starting frame: */ + while (!unwind_done(state) && + (!on_stack(&state->stack_info, first_frame, sizeof(long)) || +- state->sp < (unsigned long)first_frame)) ++ state->sp <= (unsigned long)first_frame)) + unwind_next_frame(state); + + return; +-- +2.35.1 +