5.15.180-rc1 review
Subsystems (5)
Greg Kroah-Hartman
maintainerPATCH 154/279 PCI: cadence-ep: Fix the driver to send MSG TLP for INTx without data payload
In reply to Greg Kroah-Hartman5.15-stable review patch. If anyone has any objections, please let me know.
------------------
From: Hans Zhang <[email protected]>
[ Upstream commit 3ac47fbf4f6e8c3a7c3855fac68cc3246f90f850 ]
Per the Cadence's "PCIe Controller IP for AX14" user guide, Version 1.04, Section 9.1.7.1, "AXI Subordinate to PCIe Address Translation Registers", Table 9.4, the bit 16 of the AXI Subordinate Address (axi_s_awaddr) when set corresponds to MSG with data, and when not set, to MSG without data.
However, the driver is currently doing the opposite and due to this, the INTx is never received on the host.
So, fix the driver to reflect the documentation and also make INTx work.
--- drivers/pci/controller/cadence/pcie-cadence-ep.c | 3 +-- drivers/pci/controller/cadence/pcie-cadence.h | 2 +- 2 files changed, 2 insertions(+), 3 deletions(-)
drivers/pci/controller/cadence/pcie-cadence-ep.c +1 -2
@@ -354,8 +354,7 @@ static void cdns_pcie_ep_assert_intx(struct cdns_pcie_ep *ep, u8 fn, u8 intx,spin_unlock_irqrestore (&ep->lock, flags); offset =CDNS_PCIE_NORMAL_MSG_ROUTING (MSG_ROUTING_LOCAL ) | -CDNS_PCIE_NORMAL_MSG_CODE (msg_code) | -CDNS_PCIE_MSG_NO_DATA ; +CDNS_PCIE_NORMAL_MSG_CODE (msg_code);writel (0 , ep->irq_cpu_addr + offset); }
drivers/pci/controller/cadence/pcie-cadence.h +1 -1
@@ -235,7 +235,7 @@ struct cdns_pcie_rp_ib_bar {#define CDNS_PCIE_NORMAL_MSG_CODE_MASK GENMASK(15, 8)#define CDNS_PCIE_NORMAL_MSG_CODE (code) \ (((code) << 8) & CDNS_PCIE_NORMAL_MSG_CODE_MASK) -#define CDNS_PCIE_MSG_NO_DATA BIT(16) +#define CDNS_PCIE_MSG_DATA BIT(16)struct cdns_pcie ;
Signature · 1 line
2.39.5
Greg Kroah-Hartman
maintainerPATCH 155/279 PCI: brcmstb: Use internal register to change link capability
In reply to Greg Kroah-Hartman5.15-stable review patch. If anyone has any objections, please let me know.
------------------
From: Jim Quinlan <[email protected]>
[ Upstream commit 0c97321e11e0e9e18546f828492758f6aaecec59 ]
The driver has been mistakenly writing to a read-only (RO) configuration space register (PCI_EXP_LNKCAP) to change the PCIe link capability.
Although harmless in this case, the proper write destination is an internal register that is reflected by PCI_EXP_LNKCAP.
Thus, fix the brcm_pcie_set_gen() function to correctly update the link capability.
--- drivers/pci/controller/pcie-brcmstb.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
drivers/pci/controller/pcie-brcmstb.c +2 -2
@@ -410,10 +410,10 @@ static int brcm_pcie_set_ssc(struct brcm_pcie *pcie)static void brcm_pcie_set_gen (struct brcm_pcie *pcie,int gen) {u16 lnkctl2 =readw (pcie->base +BRCM_PCIE_CAP_REGS +PCI_EXP_LNKCTL2 ); -u32 lnkcap =readl (pcie->base +BRCM_PCIE_CAP_REGS +PCI_EXP_LNKCAP ); +u32 lnkcap =readl (pcie->base +PCIE_RC_CFG_PRIV1_LINK_CAPABILITY ); lnkcap = (lnkcap & ~PCI_EXP_LNKCAP_SLS ) | gen; -writel (lnkcap, pcie->base +BRCM_PCIE_CAP_REGS +PCI_EXP_LNKCAP ); +writel (lnkcap, pcie->base +PCIE_RC_CFG_PRIV1_LINK_CAPABILITY ); lnkctl2 = (lnkctl2 & ~0xf ) | gen;writew (lnkctl2, pcie->base +BRCM_PCIE_CAP_REGS +PCI_EXP_LNKCTL2 );
Signature · 1 line
2.39.5
Greg Kroah-Hartman
maintainerPATCH 156/279 PCI/portdrv: Only disable pciehp interrupts early when needed
In reply to Greg Kroah-Hartman5.15-stable review patch. If anyone has any objections, please let me know.
------------------
From: Feng Tang <[email protected]>
[ Upstream commit 9d7db4db19827380e225914618c0c1bf435ed2f5 ]
Firmware developers reported that Linux issues two PCIe hotplug commands in very short intervals on an ARM server, which doesn't comply with the PCIe spec. According to PCIe r6.1, sec 6.7.3.2, if the Command Completed event is supported, software must wait for a command to complete or wait at least 1 second before sending a new command.
In the failure case, the first PCIe hotplug command is from get_port_device_capability(), which sends a command to disable PCIe hotplug interrupts without waiting for its completion, and the second command comes from pcie_enable_notification() of pciehp driver, which enables hotplug interrupts again.
Fix this by only disabling the hotplug interrupts when the pciehp driver is not enabled.
--- drivers/pci/pcie/portdrv_core.c | 8 +++++--- 1 file changed, 5 insertions(+), 3 deletions(-)
drivers/pci/pcie/portdrv_core.c +5 -3
@@ -214,10 +214,12 @@ static int get_port_device_capability(struct pci_dev *dev)/* * Disable hot-plug interrupts in case they have been enabled -* by the BIOS and the hot-plug service driver is not loaded. +* by the BIOS and the hot-plug service driver won't be loaded +* to handle them. */ -pcie_capability_clear_word (dev,PCI_EXP_SLTCTL , -PCI_EXP_SLTCTL_CCIE |PCI_EXP_SLTCTL_HPIE ); +if (!IS_ENABLED (CONFIG_HOTPLUG_PCI_PCIE )) +pcie_capability_clear_word (dev,PCI_EXP_SLTCTL , +PCI_EXP_SLTCTL_CCIE |PCI_EXP_SLTCTL_HPIE ); }#ifdef CONFIG_PCIEAER
Signature · 1 line
2.39.5
Greg Kroah-Hartman
maintainerPATCH 157/279 PCI: Avoid reset when disabled via sysfs
In reply to Greg Kroah-Hartman5.15-stable review patch. If anyone has any objections, please let me know.
------------------
From: Nishanth Aravamudan <[email protected]>
[ Upstream commit 479380efe1625e251008d24b2810283db60d6fcd ]
After d88f521da3ef ("PCI: Allow userspace to query and set device reset mechanism"), userspace can disable reset of specific PCI devices by writing an empty string to the sysfs reset_method file.
However, pci_slot_resettable() does not check pci_reset_supported(), which means that pci_reset_function() will still reset the device even if userspace has disabled all the reset methods.
I was able to reproduce this issue with a vfio device passed to a qemu guest, where I had disabled PCI reset via sysfs.
Add an explicit check of pci_reset_supported() in both pci_slot_resettable() and pci_bus_resettable() to ensure both the reset status and reset execution are bypassed if an administrator disables it for a device.
--- drivers/pci/pci.c | 4 ++++ 1 file changed, 4 insertions(+)
drivers/pci/pci.c +4 -0
@@ -5484,6 +5484,8 @@ static bool pci_bus_resetable(struct pci_bus *bus)return false;list_for_each_entry (dev, &bus->devices, bus_list) { +if (!pci_reset_supported (dev)) +return false;if (dev->dev_flags &PCI_DEV_FLAGS_NO_BUS_RESET || (dev->subordinate && !pci_bus_resetable (dev->subordinate)))return false;
@@ -5560,6 +5562,8 @@ static bool pci_slot_resetable(struct pci_slot *slot)list_for_each_entry (dev, &slot->bus->devices, bus_list) {if (!dev->slot || dev->slot != slot)continue ; +if (!pci_reset_supported (dev)) +return false;if (dev->dev_flags &PCI_DEV_FLAGS_NO_BUS_RESET || (dev->subordinate && !pci_bus_resetable (dev->subordinate)))return false;
Signature · 1 line
2.39.5
Greg Kroah-Hartman
maintainerPATCH 158/279 drm/amd/display: fix type mismatch in CalculateDynamicMetadataParameters()
In reply to Greg Kroah-Hartman5.15-stable review patch. If anyone has any objections, please let me know.
------------------
From: Vitaliy Shevtsov <[email protected]>
[ Upstream commit c3c584c18c90a024a54716229809ba36424f9660 ]
There is a type mismatch between what CalculateDynamicMetadataParameters() takes and what is passed to it. Currently this function accepts several args as signed long but it's called with unsigned integers and integer. On some systems where long is 32 bits and one of these unsigned int params is greater than INT_MAX it may cause passing input params as negative values.
Fix this by changing these argument types from long to unsigned int and to int respectively. Also this will align the function's definition with similar functions in other dcn* drivers.
Found by Linux Verification Center (linuxtesting.org) with Svace.
--- .../amd/display/dc/dml/dcn30/display_mode_vba_30.c | 12 ++++++------ 1 file changed, 6 insertions(+), 6 deletions(-)
drivers/gpu/drm/amd/display/dc/dml/dcn30/display_mode_vba_30.c +6 -6
@@ -283,10 +283,10 @@ static void CalculateDynamicMetadataParameters(double DISPCLK , double DCFClkDeepSleep, double PixelClock, - long HTotal, - long VBlank, - long DynamicMetadataTransmittedBytes, - long DynamicMetadataLinesBeforeActiveRequired, + unsigned int HTotal, + unsigned int VBlank, + unsigned int DynamicMetadataTransmittedBytes, + int DynamicMetadataLinesBeforeActiveRequired, int InterlaceEnable, bool ProgressiveToInterlaceUnitInOPP, double *Tsetup,
@@ -3375,8 +3375,8 @@ static double CalculateWriteBackDelay(static void CalculateDynamicMetadataParameters (int MaxInterDCNTileRepeaters,double DPPCLK ,double DISPCLK , -double DCFClkDeepSleep,double PixelClock,long HTotal,long VBlank,long DynamicMetadataTransmittedBytes, -long DynamicMetadataLinesBeforeActiveRequired,int InterlaceEnable,bool ProgressiveToInterlaceUnitInOPP, +double DCFClkDeepSleep,double PixelClock,unsigned int HTotal,unsigned int VBlank,unsigned int DynamicMetadataTransmittedBytes, +int DynamicMetadataLinesBeforeActiveRequired,int InterlaceEnable,bool ProgressiveToInterlaceUnitInOPP,double *Tsetup,double *Tdmbf,double *Tdmec,double *Tdmsks) {double TotalRepeaterDelayTime =0 ;
Signature · 1 line
2.39.5
Greg Kroah-Hartman
maintainerPATCH 159/279 PCI: Remove stray put_device() in pci_register_host_bridge()
In reply to Greg Kroah-Hartman5.15-stable review patch. If anyone has any objections, please let me know.
------------------
From: Dan Carpenter <[email protected]>
[ Upstream commit 6e8d06e5096c80cbf41313b4a204f43071ca42be ]
This put_device() was accidentally left over from when we changed the code from using device_register() to calling device_add(). Delete it.
--- drivers/pci/probe.c | 5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-)
drivers/pci/probe.c +2 -3
@@ -926,10 +926,9 @@ static int pci_register_host_bridge(struct pci_host_bridge *bridge) goto free; err =device_add (&bridge->dev); -if (err) { -put_device (&bridge->dev); +if (err) goto free; - } + bus->bridge =get_device (&bridge->dev);device_enable_async_suspend (bus->bridge);pci_set_bus_of_node (bus);
Signature · 1 line
2.39.5
Greg Kroah-Hartman
maintainerPATCH 160/279 PCI: xilinx-cpm: Fix IRQ domain leak in error path of probe
In reply to Greg Kroah-Hartman5.15-stable review patch. If anyone has any objections, please let me know.
------------------
From: Thippeswamy Havalige <[email protected]>
[ Upstream commit 57b0302240741e73fe51f88404b3866e0d2933ad ]
The IRQ domain allocated for the PCIe controller is not freed if resource_list_first_type() returns NULL, leading to a resource leak.
This fix ensures properly cleaning up the allocated IRQ domain in the error path.
--- drivers/pci/controller/pcie-xilinx-cpm.c | 10 ++++++---- 1 file changed, 6 insertions(+), 4 deletions(-)
drivers/pci/controller/pcie-xilinx-cpm.c +6 -4
@@ -556,13 +556,15 @@ static int xilinx_cpm_pcie_probe(struct platform_device *pdev)return err; bus =resource_list_first_type (&bridge->windows,IORESOURCE_BUS ); -if (!bus) -return -ENODEV ; +if (!bus) { + err = -ENODEV ; + goto err_free_irq_domains; + } err =xilinx_cpm_pcie_parse_dt (port, bus->res);if (err) {dev_err (dev,"Parsing DT failed\n" ); - goto err_parse_dt; + goto err_free_irq_domains; }xilinx_cpm_pcie_init_port (port);
@@ -586,7 +588,7 @@ static int xilinx_cpm_pcie_probe(struct platform_device *pdev)xilinx_cpm_free_interrupts (port); err_setup_irq:pci_ecam_free (port->cfg); -err_parse_dt: +err_free_irq_domains:xilinx_cpm_free_irq_domains (port);return err; }
Signature · 1 line
2.39.5
Greg Kroah-Hartman
maintainerPATCH 161/279 drm/mediatek: dsi: fix error codes in mtk_dsi_host_transfer()
In reply to Greg Kroah-Hartman5.15-stable review patch. If anyone has any objections, please let me know.
------------------
From: Dan Carpenter <[email protected]>
[ Upstream commit dcb166ee43c3d594e7b73a24f6e8cf5663eeff2c ]
There is a type bug because the return statement:
return ret < 0 ? ret : recv_cnt;
The issue is that ret is an int, recv_cnt is a u32 and the function returns ssize_t, which is a signed long. The way that the type promotion works is that the negative error codes are first cast to u32 and then to signed long. The error codes end up being positive instead of negative and the callers treat them as success.
--- drivers/gpu/drm/mediatek/mtk_dsi.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-)
drivers/gpu/drm/mediatek/mtk_dsi.c +3 -3
@@ -920,12 +920,12 @@ static ssize_t mtk_dsi_host_transfer(struct mipi_dsi_host *host, const struct mipi_dsi_msg *msg) {struct mtk_dsi *dsi =host_to_dsi (host); -u32 recv_cnt, i; +ssize_t recv_cnt;u8 read_data[16 ];void *src_addr;u8 irq_flag =CMD_DONE_INT_FLAG ;u32 dsi_mode; -int ret; +int ret, i; dsi_mode =readl (dsi->regs +DSI_MODE_CTRL );if (dsi_mode &MODE ) {
@@ -974,7 +974,7 @@ static ssize_t mtk_dsi_host_transfer(struct mipi_dsi_host *host,if (recv_cnt)memcpy (msg->rx_buf, src_addr, recv_cnt); -DRM_INFO ("dsi get %d byte data from the panel address(0x%x)\n" , +DRM_INFO ("dsi get %zd byte data from the panel address(0x%x)\n" , recv_cnt, *((u8 *)(msg->tx_buf))); restore_dsi_mode:
Signature · 1 line
2.39.5
Greg Kroah-Hartman
maintainerPATCH 162/279 PCI: pciehp: Dont enable HPIE when resuming in poll mode
In reply to Greg Kroah-Hartman5.15-stable review patch. If anyone has any objections, please let me know.
------------------
From: Ilpo Järvinen <[email protected]>
[ Upstream commit 527664f738afb6f2c58022cd35e63801e5dc7aec ]
PCIe hotplug can operate in poll mode without interrupt handlers using a polling kthread only. eb34da60edee ("PCI: pciehp: Disable hotplug interrupt during suspend") failed to consider that and enables HPIE (Hot-Plug Interrupt Enable) unconditionally when resuming the Port.
Only set HPIE if non-poll mode is in use. This makes pcie_enable_interrupt() match how pcie_enable_notification() already handles HPIE.
--- drivers/pci/hotplug/pciehp_hpc.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-)
drivers/pci/hotplug/pciehp_hpc.c +3 -1
@@ -840,7 +840,9 @@ void pcie_enable_interrupt(struct controller *ctrl) {u16 mask; - mask =PCI_EXP_SLTCTL_HPIE |PCI_EXP_SLTCTL_DLLSCE ; + mask =PCI_EXP_SLTCTL_DLLSCE ; +if (!pciehp_poll_mode) + mask |=PCI_EXP_SLTCTL_HPIE ;pcie_write_cmd (ctrl, mask, mask); }
Signature · 1 line
2.39.5
Greg Kroah-Hartman
maintainerPATCH 163/279 fbdev: au1100fb: Move a variable assignment behind a null pointer check
In reply to Greg Kroah-Hartman5.15-stable review patch. If anyone has any objections, please let me know.
------------------
From: Markus Elfring <[email protected]>
[ Upstream commit 2df2c0caaecfd869b49e14f2b8df822397c5dd7f ]
The address of a data structure member was determined before a corresponding null pointer check in the implementation of the function “au1100fb_setmode”.
This issue was detected by using the Coccinelle software.
--- drivers/video/fbdev/au1100fb.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-)
drivers/video/fbdev/au1100fb.c +3 -1
@@ -137,13 +137,15 @@ static int au1100fb_fb_blank(int blank_mode, struct fb_info *fbi)*/ int au1100fb_setmode (struct au1100fb_device *fbdev) { -struct fb_info *info = &fbdev->info; +struct fb_info *info;u32 words;int index;if (!fbdev)return -EINVAL ; + info = &fbdev->info; +/* Update var-dependent FB info */ if (panel_is_active (fbdev->panel) ||panel_is_color (fbdev->panel)) {if (info->var.bits_per_pixel <=8 ) {
Signature · 1 line
2.39.5
Greg Kroah-Hartman
maintainerPATCH 164/279 mdacon: rework dependency list
In reply to Greg Kroah-Hartman5.15-stable review patch. If anyone has any objections, please let me know.
------------------
From: Arnd Bergmann <[email protected]>
[ Upstream commit 5bbcc7645f4b244ffb5ac6563fbe9d3d42194447 ]
mdacon has roughly the same dependencies as vgacon but expresses them as a negative list instead of a positive list, with the only practical difference being PowerPC/CHRP, which uses vga16fb instead of vgacon.
The CONFIG_MDA_CONSOLE description advises to only turn it on when vgacon is also used because MDA/Hercules-only systems should be using vgacon instead, so just change the list to enforce that directly for simplicity.
The probing was broken from 2002 to 2008, this improves on the fix that was added then: If vgacon is a loadable module, then mdacon cannot be built-in now, and the list of systems that support vgacon is carried over.
--- drivers/video/console/Kconfig | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/video/console/Kconfig +1 -1
@@ -23,7 +23,7 @@ config VGA_CONSOLE Say Y. config MDA_CONSOLE - depends on !M68K && !PARISC && ISA + depends on VGA_CONSOLE && ISA tristate "MDA text console (dual-headed)" help Say Y here if you have an old MDA or monochrome Hercules graphics
Signature · 1 line
2.39.5
Greg Kroah-Hartman
maintainerPATCH 165/279 fbdev: sm501fb: Add some geometry checks.
In reply to Greg Kroah-Hartman5.15-stable review patch. If anyone has any objections, please let me know.
------------------
From: Danila Chernetsov <[email protected]>
[ Upstream commit aee50bd88ea5fde1ff4cc021385598f81a65830c ]
Added checks for xoffset, yoffset settings. Incorrect settings of these parameters can lead to errors in sm501fb_pan_ functions.
Found by Linux Verification Center (linuxtesting.org) with SVACE.
--- drivers/video/fbdev/sm501fb.c | 7 +++++++ 1 file changed, 7 insertions(+)
drivers/video/fbdev/sm501fb.c +7 -0
@@ -326,6 +326,13 @@ static int sm501fb_check_var(struct fb_var_screeninfo *var,if (var->xres_virtual >4096 || var->yres_virtual >2048 )return -EINVAL ; +/* geometry sanity checks */ +if (var->xres + var->xoffset > var->xres_virtual) +return -EINVAL ; + +if (var->yres + var->yoffset > var->yres_virtual) +return -EINVAL ; +/* can cope with 8,16 or 32bpp */ if (var->bits_per_pixel <=8 )
Signature · 1 line
2.39.5
Greg Kroah-Hartman
maintainerPATCH 166/279 clk: amlogic: gxbb: drop incorrect flag on 32k clock
In reply to Greg Kroah-Hartman5.15-stable review patch. If anyone has any objections, please let me know.
------------------
From: Jerome Brunet <[email protected]>
[ Upstream commit f38f7fe4830c5cb4eac138249225f119e7939965 ]
gxbb_32k_clk_div sets CLK_DIVIDER_ROUND_CLOSEST in the init_data flag which is incorrect. This is field is not where the divider flags belong.
Thankfully, CLK_DIVIDER_ROUND_CLOSEST maps to bit 4 which is an unused clock flag, so there is no unintended consequence to this error.
Effectively, the clock has been used without CLK_DIVIDER_ROUND_CLOSEST so far, so just drop it.
--- drivers/clk/meson/gxbb.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/clk/meson/gxbb.c +1 -1
@@ -1310,7 +1310,7 @@ static struct clk_regmap gxbb_32k_clk_div = { &gxbb_32k_clk_sel.hw }, .num_parents = 1, - .flags = CLK_SET_RATE_PARENT | CLK_DIVIDER_ROUND_CLOSEST, + .flags = CLK_SET_RATE_PARENT, }, };
Signature · 1 line
2.39.5
Greg Kroah-Hartman
maintainerPATCH 167/279 crypto: hisilicon/sec2 - fix for aead authsize alignment
In reply to Greg Kroah-Hartman5.15-stable review patch. If anyone has any objections, please let me know.
------------------
From: Wenkai Lin <[email protected]>
[ Upstream commit a49cc71e219040d771a8c1254879984f98192811 ]
The hardware only supports authentication sizes
that are 4-byte aligned. Therefore, the driver
switches to software computation in this case.
--- drivers/crypto/hisilicon/sec2/sec_crypto.c | 22 +++++++++------------- 1 file changed, 9 insertions(+), 13 deletions(-)
drivers/crypto/hisilicon/sec2/sec_crypto.c +9 -13
@@ -55,7 +55,6 @@#define SEC_TYPE_MASK 0x0F#define SEC_DONE_MASK 0x0001#define SEC_ICV_MASK 0x000E -#define SEC_SQE_LEN_RATE_MASK 0x3#define SEC_TOTAL_IV_SZ (SEC_IV_SIZE * QM_Q_DEPTH)#define SEC_SGL_SGE_NR 128
@@ -77,16 +76,16 @@#define SEC_TOTAL_PBUF_SZ (PAGE_SIZE * SEC_PBUF_PAGE_NUM + \ SEC_PBUF_LEFT_SZ) -#define SEC_SQE_LEN_RATE 4#define SEC_SQE_CFLAG 2#define SEC_SQE_AEAD_FLAG 3#define SEC_SQE_DONE 0x1#define SEC_ICV_ERR 0x2 -#define MIN_MAC_LEN 4#define MAC_LEN_MASK 0x1U#define MAX_INPUT_DATA_LEN 0xFFFE00#define BITS_MASK 0xFF +#define WORD_MASK 0x3#define BYTE_BITS 0x8 +#define BYTES_TO_WORDS (bcount) ((bcount) >> 2)#define SEC_XTS_NAME_SZ 0x3#define IV_CM_CAL_NUM 2#define IV_CL_MASK 0x7
@@ -1133,7 +1132,7 @@ static int sec_aead_setkey(struct crypto_aead *tfm, const u8 *key, goto bad_key; } -if (ctx->a_ctx.a_key_len &SEC_SQE_LEN_RATE_MASK ) { +if (ctx->a_ctx.a_key_len &WORD_MASK ) { ret = -EINVAL ;dev_err (dev,"AUTH key length error!\n" ); goto bad_key;
@@ -1538,11 +1537,10 @@ static void sec_auth_bd_fill_ex(struct sec_auth_ctx *ctx, int dir, sec_sqe->type2.a_key_addr =cpu_to_le64 (ctx->a_key_dma); - sec_sqe->type2.mac_key_alg =cpu_to_le32 (authsize /SEC_SQE_LEN_RATE ); + sec_sqe->type2.mac_key_alg =cpu_to_le32 (BYTES_TO_WORDS (authsize)); sec_sqe->type2.mac_key_alg |= -cpu_to_le32 ((u32)((ctx->a_key_len) / -SEC_SQE_LEN_RATE ) <<SEC_AKEY_OFFSET ); +cpu_to_le32 ((u32 )BYTES_TO_WORDS (ctx->a_key_len) <<SEC_AKEY_OFFSET ); sec_sqe->type2.mac_key_alg |=cpu_to_le32 ((u32)(ctx->a_alg) <<SEC_AEAD_ALG_OFFSET );
@@ -1594,12 +1592,10 @@ static void sec_auth_bd_fill_ex_v3(struct sec_auth_ctx *ctx, int dir, sqe3->a_key_addr =cpu_to_le64 (ctx->a_key_dma); sqe3->auth_mac_key |= -cpu_to_le32 ((u32)(authsize / -SEC_SQE_LEN_RATE ) <<SEC_MAC_OFFSET_V3 ); +cpu_to_le32 (BYTES_TO_WORDS (authsize) <<SEC_MAC_OFFSET_V3 ); sqe3->auth_mac_key |= -cpu_to_le32 ((u32)(ctx->a_key_len / -SEC_SQE_LEN_RATE ) <<SEC_AKEY_OFFSET_V3 ); +cpu_to_le32 ((u32 )BYTES_TO_WORDS (ctx->a_key_len) <<SEC_AKEY_OFFSET_V3 ); sqe3->auth_mac_key |=cpu_to_le32 ((u32)(ctx->a_alg) <<SEC_AUTH_ALG_OFFSET_V3 );
@@ -2205,8 +2201,8 @@ static int sec_aead_spec_check(struct sec_ctx *ctx, struct sec_req *sreq)struct device *dev = ctx->dev;int ret; -/* Hardware does not handle cases where authsize is less than 4 bytes */ -if (unlikely (sz <MIN_MAC_LEN )) { +/* Hardware does not handle cases where authsize is not 4 bytes aligned */ +if (c_mode ==SEC_CMODE_CBC && (sz &WORD_MASK )) { sreq->aead_req.fallback = true;return -EINVAL ; }
Signature · 1 line
2.39.5
Greg Kroah-Hartman
maintainerPATCH 168/279 remoteproc: core: Clear table_sz when rproc_shutdown
In reply to Greg Kroah-Hartman5.15-stable review patch. If anyone has any objections, please let me know.
------------------
From: Peng Fan <[email protected]>
[ Upstream commit efdde3d73ab25cef4ff2d06783b0aad8b093c0e4 ]
There is case as below could trigger kernel dump:
Use U-Boot to start remote processor(rproc) with resource table published to a fixed address by rproc. After Kernel boots up, stop the rproc, load a new firmware which doesn't have resource table ,and start rproc.
When starting rproc with a firmware not have resource table, memcpy(loaded_table, rproc->cached_table, rproc->table_sz) will trigger dump, because rproc->cache_table is set to NULL during the last stop operation, but rproc->table_sz is still valid.
This issue is found on i.MX8MP and i.MX9.
Dump as below:
Unable to handle kernel NULL pointer dereference at virtual address 0000000000000000
Mem abort info:
ESR = 0x0000000096000004
EC = 0x25: DABT (current EL), IL = 32 bits
SET = 0, FnV = 0
EA = 0, S1PTW = 0
FSC = 0x04: level 0 translation fault
Data abort info:
ISV = 0, ISS = 0x00000004, ISS2 = 0x00000000
CM = 0, WnR = 0, TnD = 0, TagAccess = 0
GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0
user pgtable: 4k pages, 48-bit VAs, pgdp=000000010af63000 [0000000000000000] pgd=0000000000000000, p4d=0000000000000000
Internal error: Oops: 0000000096000004 [#1] PREEMPT SMP Modules linked in: CPU: 2 UID: 0 PID: 1060 Comm: sh Not tainted 6.14.0-rc7-next-20250317-dirty #38 Hardware name: NXP i.MX8MPlus EVK board (DT) pstate: a0000005 (NzCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : __pi_memcpy_generic+0x110/0x22c lr : rproc_start+0x88/0x1e0 Call trace: __pi_memcpy_generic+0x110/0x22c (P) rproc_boot+0x198/0x57c state_store+0x40/0x104 dev_attr_store+0x18/0x2c sysfs_kf_write+0x7c/0x94 kernfs_fop_write_iter+0x120/0x1cc vfs_write+0x240/0x378 ksys_write+0x70/0x108 __arm64_sys_write+0x1c/0x28 invoke_syscall+0x48/0x10c el0_svc_common.constprop.0+0xc0/0xe0 do_el0_svc+0x1c/0x28 el0_svc+0x30/0xcc el0t_64_sync_handler+0x10c/0x138 el0t_64_sync+0x198/0x19c
Clear rproc->table_sz to address the issue.
--- drivers/remoteproc/remoteproc_core.c | 1 + 1 file changed, 1 insertion(+)
drivers/remoteproc/remoteproc_core.c +1 -0
@@ -2102,6 +2102,7 @@ void rproc_shutdown(struct rproc *rproc)kfree (rproc->cached_table); rproc->cached_table =NULL ; rproc->table_ptr =NULL ; + rproc->table_sz =0 ; out:mutex_unlock (&rproc->lock); }
Signature · 1 line
2.39.5
Greg Kroah-Hartman
maintainerPATCH 169/279 of: property: Increase NR_FWNODE_REFERENCE_ARGS
In reply to Greg Kroah-Hartman5.15-stable review patch. If anyone has any objections, please let me know.
------------------
From: Zijun Hu <[email protected]>
[ Upstream commit eb50844d728f11e87491f7c7af15a4a737f1159d ]
Currently, the following two macros have different values:
// The maximal argument count for firmware node reference
#define NR_FWNODE_REFERENCE_ARGS 8
// The maximal argument count for DT node reference
#define MAX_PHANDLE_ARGS 16
It may cause firmware node reference's argument count out of range if directly assign DT node reference's argument count to firmware's.
drivers/of/property.c:of_fwnode_get_reference_args() is doing the direct assignment, so may cause firmware's argument count @args->nargs got out of range, namely, in [9, 16].
Fix by increasing NR_FWNODE_REFERENCE_ARGS to 16 to meet DT requirement. Will align both macros later to avoid such inconsistency.
--- include/linux/fwnode.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
include/linux/fwnode.h +1 -1
@@ -67,7 +67,7 @@ struct fwnode_endpoint {#define SWNODE_GRAPH_PORT_NAME_FMT "port@%u"#define SWNODE_GRAPH_ENDPOINT_NAME_FMT "endpoint@%u" -#define NR_FWNODE_REFERENCE_ARGS 8 +#define NR_FWNODE_REFERENCE_ARGS 16/** * struct fwnode_reference_args - Fwnode reference with additional arguments
Signature · 1 line
2.39.5
Greg Kroah-Hartman
maintainerPATCH 170/279 remoteproc: qcom_q6v5_pas: Make single-PD handling more robust
In reply to Greg Kroah-Hartman5.15-stable review patch. If anyone has any objections, please let me know.
------------------
From: Luca Weiss <[email protected]>
[ Upstream commit e917b73234b02aa4966325e7380d2559bf127ba9 ]
Only go into the if condition for single-PD handling when there's actually just one power domain specified there. Otherwise it'll be an issue in the dts and we should fail in the regular code path.
This also mirrors the latest changes in the qcom_q6v5_mss driver.
--- drivers/remoteproc/qcom_q6v5_pas.c | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-)
drivers/remoteproc/qcom_q6v5_pas.c +5 -5
@@ -330,16 +330,16 @@ static int adsp_pds_attach(struct device *dev, struct device **devs,if (!pd_names)return 0 ; +while (pd_names[num_pds]) + num_pds++; +/* Handle single power domain */ -if (dev->pm_domain) { +if (num_pds ==1 && dev->pm_domain) { devs[0 ] = dev;pm_runtime_enable (dev);return 1 ; } -while (pd_names[num_pds]) - num_pds++; -for (i =0 ; i < num_pds; i++) { devs[i] =dev_pm_domain_attach_by_name (dev, pd_names[i]);if (IS_ERR_OR_NULL (devs[i])) {
@@ -364,7 +364,7 @@ static void adsp_pds_detach(struct qcom_adsp *adsp, struct device **pds,int i;/* Handle single power domain */ -if (dev->pm_domain && pd_count) { +if (pd_count ==1 && dev->pm_domain) {pm_runtime_disable (dev);return ; }
Signature · 1 line
2.39.5
Greg Kroah-Hartman
maintainerPATCH 171/279 libbpf: Fix hypothetical STT_SECTION extern NULL deref case
In reply to Greg Kroah-Hartman5.15-stable review patch. If anyone has any objections, please let me know.
------------------
From: Andrii Nakryiko <[email protected]>
[ Upstream commit e0525cd72b5979d8089fe524a071ea93fd011dc9 ]
Fix theoretical NULL dereference in linker when resolving *extern* STT_SECTION symbol against not-yet-existing ELF section. Not sure if it's possible in practice for valid ELF object files (this would require embedded assembly manipulations, at which point BTF will be missing), but fix the s/dst_sym/dst_sec/ typo guarding this condition anyways.
--- tools/lib/bpf/linker.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
tools/lib/bpf/linker.c +1 -1
@@ -1966,7 +1966,7 @@ static int linker_append_elf_sym(struct bpf_linker *linker, struct src_obj *obj, obj->sym_map[src_sym_idx] = dst_sym_idx; -if (sym_type ==STT_SECTION && dst_sym) { +if (sym_type ==STT_SECTION && dst_sec) { dst_sec->sec_sym_idx = dst_sym_idx; dst_sym->st_value =0 ; }
Signature · 1 line
2.39.5
Greg Kroah-Hartman
maintainerPATCH 172/279 clk: samsung: Fix UBSAN panic in samsung_clk_init()
In reply to Greg Kroah-Hartman5.15-stable review patch. If anyone has any objections, please let me know.
------------------
From: Will McVicker <[email protected]>
[ Upstream commit d19d7345a7bcdb083b65568a11b11adffe0687af ]
With UBSAN_ARRAY_BOUNDS=y, I'm hitting the below panic due to dereferencing ctx->clk_data.hws before setting ctx->clk_data.num = nr_clks. Move that up to fix the crash.
UBSAN: array index out of bounds: 00000000f2005512 [#1] PREEMPT SMP <snip> Call trace: samsung_clk_init+0x110/0x124 (P) samsung_clk_init+0x48/0x124 (L) samsung_cmu_register_one+0x3c/0xa0 exynos_arm64_register_cmu+0x54/0x64 __gs101_cmu_top_of_clk_init_declare+0x28/0x60 ...
--- drivers/clk/samsung/clk.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/clk/samsung/clk.c +1 -1
@@ -64,11 +64,11 @@ struct samsung_clk_provider *__init samsung_clk_init(struct device_node *np,if (!ctx)panic ("could not allocate clock provider context.\n" ); + ctx->clk_data.num = nr_clks;for (i =0 ; i < nr_clks; ++i) ctx->clk_data.hws[i] =ERR_PTR (-ENOENT ); ctx->reg_base = base; - ctx->clk_data.num = nr_clks;spin_lock_init (&ctx->lock);return ctx;
Signature · 1 line
2.39.5
Greg Kroah-Hartman
maintainerPATCH 173/279 clk: qcom: gcc-msm8953: fix stuck venus0_core0 clock
In reply to Greg Kroah-Hartman5.15-stable review patch. If anyone has any objections, please let me know.
------------------
From: Vladimir Lypak <[email protected]>
[ Upstream commit cdc59600bccf2cb4c483645438a97d4ec55f326b ]
This clock can't be enable with VENUS_CORE0 GDSC turned off. But that GDSC is under HW control so it can be turned off at any moment. Instead of checking the dependent clock we can just vote for it to enable later when GDSC gets turned on.
--- drivers/clk/qcom/gcc-msm8953.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/clk/qcom/gcc-msm8953.c +1 -1
@@ -3771,7 +3771,7 @@ static struct clk_branch gcc_venus0_axi_clk = {static struct clk_branch gcc_venus0_core0_vcodec0_clk = { .halt_reg =0x4c02c , - .halt_check =BRANCH_HALT , + .halt_check =BRANCH_HALT_SKIP , .clkr = { .enable_reg =0x4c02c , .enable_mask =BIT (0 ),
Signature · 1 line
2.39.5
Greg Kroah-Hartman
maintainerPATCH 174/279 bpf: Use preempt_count() directly in bpf_send_signal_common()
In reply to Greg Kroah-Hartman5.15-stable review patch. If anyone has any objections, please let me know.
------------------
From: Hou Tao <[email protected]>
[ Upstream commit b4a8b5bba712a711d8ca1f7d04646db63f9c88f5 ]
bpf_send_signal_common() uses preemptible() to check whether or not the current context is preemptible. If it is preemptible, it will use irq_work to send the signal asynchronously instead of trying to hold a spin-lock, because spin-lock is sleepable under PREEMPT_RT.
However, preemptible() depends on CONFIG_PREEMPT_COUNT. When CONFIG_PREEMPT_COUNT is turned off (e.g., CONFIG_PREEMPT_VOLUNTARY=y), !preemptible() will be evaluated as 1 and bpf_send_signal_common() will use irq_work unconditionally.
Fix it by unfolding "!preemptible()" and using "preempt_count() != 0 || irqs_disabled()" instead.
--- kernel/trace/bpf_trace.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
kernel/trace/bpf_trace.c +1 -1
@@ -799,7 +799,7 @@ static int bpf_send_signal_common(u32 sig, enum pid_type type)if (unlikely (is_global_init (current)))return -EPERM ; -if (!preemptible ()) { +if (preempt_count () !=0 ||irqs_disabled ()) {/* Do an early check on signal validity. Otherwise, * the error is lost in deferred irq_work. */
Signature · 1 line
2.39.5
Greg Kroah-Hartman
maintainerPATCH 175/279 lib: 842: Improve error handling in sw842_compress()
In reply to Greg Kroah-Hartman5.15-stable review patch. If anyone has any objections, please let me know.
------------------
From: Tanya Agarwal <[email protected]>
[ Upstream commit af324dc0e2b558678aec42260cce38be16cc77ca ]
The static code analysis tool "Coverity Scan" pointed the following implementation details out for further development considerations:
CID 1309755: Unused value
In sw842_compress: A value assigned to a variable is never used. (CWE-563)returned_value: Assigning value from add_repeat_template(p, repeat_count) to ret here, but that stored value is overwritten before it can be used.
Conclusion:
Add error handling for the return value from an add_repeat_template() call.
--- lib/842/842_compress.c | 2 ++ 1 file changed, 2 insertions(+)
lib/842/842_compress.c +2 -0
@@ -532,6 +532,8 @@ int sw842_compress(const u8 *in, unsigned int ilen, }if (repeat_count) { ret =add_repeat_template (p, repeat_count); +if (ret) +return ret; repeat_count =0 ;if (next == last)/* reached max repeat bits */ goto repeat;
Signature · 1 line
2.39.5
Greg Kroah-Hartman
maintainerPATCH 176/279 pinctrl: renesas: rza2: Fix missing of_node_put() call
In reply to Greg Kroah-Hartman5.15-stable review patch. If anyone has any objections, please let me know.
------------------
From: Fabrizio Castro <[email protected]>
[ Upstream commit abcdeb4e299a11ecb5a3ea0cce00e68e8f540375 ]
of_parse_phandle_with_fixed_args() requires its caller to call into of_node_put() on the node pointer from the output structure, but such a call is currently missing.
Call into of_node_put() to rectify that.
--- drivers/pinctrl/renesas/pinctrl-rza2.c | 2 ++ 1 file changed, 2 insertions(+)
drivers/pinctrl/renesas/pinctrl-rza2.c +2 -0
@@ -253,6 +253,8 @@ static int rza2_gpio_register(struct rza2_pinctrl_priv *priv)return ret; } +of_node_put (of_args.np); +if ((of_args.args[0 ] !=0 ) || (of_args.args[1 ] !=0 ) || (of_args.args[2 ] != priv->npins)) {
Signature · 1 line
2.39.5
Greg Kroah-Hartman
maintainerPATCH 177/279 pinctrl: renesas: rzg2l: Fix missing of_node_put() call
In reply to Greg Kroah-Hartman5.15-stable review patch. If anyone has any objections, please let me know.
------------------
From: Fabrizio Castro <[email protected]>
[ Upstream commit a5779e625e2b377f16a6675c432aaf299ce5028c ]
of_parse_phandle_with_fixed_args() requires its caller to call into of_node_put() on the node pointer from the output structure, but such a call is currently missing.
Call into of_node_put() to rectify that.
--- drivers/pinctrl/renesas/pinctrl-rzg2l.c | 2 ++ 1 file changed, 2 insertions(+)
drivers/pinctrl/renesas/pinctrl-rzg2l.c +2 -0
@@ -979,6 +979,8 @@ static int rzg2l_gpio_register(struct rzg2l_pinctrl *pctrl)return ret; } +of_node_put (of_args.np); +if (of_args.args[0 ] !=0 || of_args.args[1 ] !=0 || of_args.args[2 ] !=ARRAY_SIZE (rzg2l_gpio_names)) {dev_err (pctrl->dev,"gpio-ranges does not match selected SOC\n" );
Signature · 1 line
2.39.5
Greg Kroah-Hartman
maintainerPATCH 178/279 clk: rockchip: rk3328: fix wrong clk_ref_usb3otg parent
In reply to Greg Kroah-Hartman5.15-stable review patch. If anyone has any objections, please let me know.
------------------
From: Peter Geis <[email protected]>
[ Upstream commit a9e60f1ffe1ca57d6af6a2573e2f950e76efbf5b ]
Correct the clk_ref_usb3otg parent to fix clock control for the usb3 controller on rk3328. Verified against the rk3328 trm, the rk3228h trm, and the rk3328 usb3 phy clock map.
--- drivers/clk/rockchip/clk-rk3328.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/clk/rockchip/clk-rk3328.c +1 -1
@@ -201,7 +201,7 @@ PNAME(mux_aclk_peri_pre_p) = { "cpll_peri","gpll_peri" , "hdmiphy_peri" };PNAME (mux_ref_usb3otg_src_p) = {"xin24m" , -"clk_usb3otg_ref" }; +"clk_ref_usb3otg_src" };PNAME (mux_xin24m_32k_p) = {"xin24m" ,"clk_rtc32k" }; PNAME(mux_mac2io_src_p) = { "clk_mac2io_src",
Signature · 1 line
2.39.5
Greg Kroah-Hartman
maintainerPATCH 179/279 RDMA/core: Dont expose hw_counters outside of init net namespace
In reply to Greg Kroah-Hartman5.15-stable review patch. If anyone has any objections, please let me know.
------------------
From: Roman Gushchin <[email protected]>
[ Upstream commit a1ecb30f90856b0be4168ad51b8875148e285c1f ]
Commit 467f432a521a ("RDMA/core: Split port and device counter sysfs attributes") accidentally almost exposed hw counters to non-init net namespaces. It didn't expose them fully, as an attempt to read any of those counters leads to a crash like this one:
[42021.807566] BUG: kernel NULL pointer dereference, address: 0000000000000028 [42021.814463] #PF: supervisor read access in kernel mode [42021.819549] #PF: error_code(0x0000) - not-present page [42021.824636] PGD 0 P4D 0 [42021.827145] Oops: 0000 [#1] SMP PTI [42021.830598] CPU: 82 PID: 2843922 Comm: switchto-defaul Kdump: loaded Tainted: G S W I XXX [42021.841697] Hardware name: XXX [42021.849619] RIP: 0010:hw_stat_device_show+0x1e/0x40 [ib_core] [42021.855362] Code: 90 90 90 90 90 90 90 90 90 90 90 90 f3 0f 1e fa 0f 1f 44 00 00 49 89 d0 4c 8b 5e 20 48 8b 8f b8 04 00 00 48 81 c7 f0 fa ff ff <48> 8b 41 28 48 29 ce 48 83 c6 d0 48 c1 ee 04 69 d6 ab aa aa aa 48 [42021.873931] RSP: 0018:ffff97fe90f03da0 EFLAGS: 00010287 [42021.879108] RAX: ffff9406988a8c60 RBX: ffff940e1072d438 RCX: 0000000000000000 [42021.886169] RDX: ffff94085f1aa000 RSI: ffff93c6cbbdbcb0 RDI: ffff940c7517aef0 [42021.893230] RBP: ffff97fe90f03e70 R08: ffff94085f1aa000 R09: 0000000000000000 [42021.900294] R10: ffff94085f1aa000 R11: ffffffffc0775680 R12: ffffffff87ca2530 [42021.907355] R13: ffff940651602840 R14: ffff93c6cbbdbcb0 R15: ffff94085f1aa000 [42021.914418] FS: 00007fda1a3b9700(0000) GS:ffff94453fb80000(0000) knlGS:0000000000000000 [42021.922423] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [42021.928130] CR2: 0000000000000028 CR3: 00000042dcfb8003 CR4: 00000000003726f0 [42021.935194] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [42021.942257] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 [42021.949324] Call Trace: [42021.951756] <TASK> [42021.953842] [<ffffffff86c58674>] ? show_regs+0x64/0x70 [42021.959030] [<ffffffff86c58468>] ? __die+0x78/0xc0 [42021.963874] [<ffffffff86c9ef75>] ? page_fault_oops+0x2b5/0x3b0 [42021.969749] [<ffffffff87674b92>] ? exc_page_fault+0x1a2/0x3c0 [42021.975549] [<ffffffff87801326>] ? asm_exc_page_fault+0x26/0x30 [42021.981517] [<ffffffffc0775680>] ? __pfx_show_hw_stats+0x10/0x10 [ib_core] [42021.988482] [<ffffffffc077564e>] ? hw_stat_device_show+0x1e/0x40 [ib_core] [42021.995438] [<ffffffff86ac7f8e>] dev_attr_show+0x1e/0x50 [42022.000803] [<ffffffff86a3eeb1>] sysfs_kf_seq_show+0x81/0xe0 [42022.006508] [<ffffffff86a11134>] seq_read_iter+0xf4/0x410 [42022.011954] [<ffffffff869f4b2e>] vfs_read+0x16e/0x2f0 [42022.017058] [<ffffffff869f50ee>] ksys_read+0x6e/0xe0 [42022.022073] [<ffffffff8766f1ca>] do_syscall_64+0x6a/0xa0 [42022.027441] [<ffffffff8780013b>] entry_SYSCALL_64_after_hwframe+0x78/0xe2
The problem can be reproduced using the following steps:
ip netns add foo
ip netns exec foo bash
cat /sys/class/infiniband/mlx4_0/hw_counters/*
The panic occurs because of casting the device pointer into an ib_device pointer using container_of() in hw_stat_device_show() is wrong and leads to a memory corruption.
However the real problem is that hw counters should never been exposed outside of the non-init net namespace.
Fix this by saving the index of the corresponding attribute group (it might be 1 or 2 depending on the presence of driver-specific attributes) and zeroing the pointer to hw_counters group for compat devices during the initialization.
With this fix applied hw_counters are not available in a non-init net namespace:
find /sys/class/infiniband/mlx4_0/ -name hw_counters
/sys/class/infiniband/mlx4_0/ports/1/hw_counters /sys/class/infiniband/mlx4_0/ports/2/hw_counters /sys/class/infiniband/mlx4_0/hw_counters
ip netns add foo
ip netns exec foo bash
find /sys/class/infiniband/mlx4_0/ -name hw_counters
--- drivers/infiniband/core/device.c | 9 +++++++++ drivers/infiniband/core/sysfs.c | 1 + include/rdma/ib_verbs.h | 1 + 3 files changed, 11 insertions(+)
drivers/infiniband/core/device.c +9 -0
@@ -542,6 +542,8 @@ static struct class ib_class = {static void rdma_init_coredev (struct ib_core_device *coredev,struct ib_device *dev,struct net *net) { +bool is_full_dev = &dev->coredev == coredev; +/* This BUILD_BUG_ON is intended to catch layout change * of union of ib_core_device and device. * dev must be the first element as ib_core and providers
@@ -553,6 +555,13 @@ static void rdma_init_coredev(struct ib_core_device *coredev, coredev->dev.class = &ib_class; coredev->dev.groups = dev->groups; + +/* +* Don't expose hw counters outside of the init namespace. +*/ +if (!is_full_dev && dev->hw_stats_attr_index) + coredev->dev.groups[dev->hw_stats_attr_index] =NULL ; +device_initialize (&coredev->dev); coredev->owner = dev;INIT_LIST_HEAD (&coredev->port_list);
drivers/infiniband/core/sysfs.c +1 -0
@@ -976,6 +976,7 @@ int ib_setup_device_attrs(struct ib_device *ibdev)for (i =0 ; i !=ARRAY_SIZE (ibdev->groups); i++)if (!ibdev->groups[i]) { ibdev->groups[i] = &data->group; + ibdev->hw_stats_attr_index = i;return 0 ; }WARN (true,"struct ib_device->groups is too small" );
include/rdma/ib_verbs.h +1 -0
@@ -2707,6 +2707,7 @@ struct ib_device {* It is a NULL terminated array. */ const struct attribute_group *groups[4 ]; +u8 hw_stats_attr_index;u64 uverbs_cmd_mask;
Signature · 1 line
2.39.5
Greg Kroah-Hartman
maintainerPATCH 180/279 remoteproc: qcom_q6v5_mss: Handle platforms with one power domain
In reply to Greg Kroah-Hartman5.15-stable review patch. If anyone has any objections, please let me know.
------------------
From: Luca Weiss <[email protected]>
[ Upstream commit 4641840341f37dc8231e0840ec1514b4061b4322 ]
For example MSM8974 has mx voltage rail exposed as regulator and only cx voltage rail is exposed as power domain. This power domain (cx) is attached internally in power domain and cannot be attached in this driver.
--- drivers/remoteproc/qcom_q6v5_mss.c | 21 +++++++++++++++++---- 1 file changed, 17 insertions(+), 4 deletions(-)
drivers/remoteproc/qcom_q6v5_mss.c +17 -4
@@ -1594,6 +1594,13 @@ static int q6v5_pds_attach(struct device *dev, struct device **devs,while (pd_names[num_pds]) num_pds++; +/* Handle single power domain */ +if (num_pds ==1 && dev->pm_domain) { + devs[0 ] = dev; +pm_runtime_enable (dev); +return 1 ; + } +for (i =0 ; i < num_pds; i++) { devs[i] =dev_pm_domain_attach_by_name (dev, pd_names[i]);if (IS_ERR_OR_NULL (devs[i])) {
@@ -1614,8 +1621,15 @@ static int q6v5_pds_attach(struct device *dev, struct device **devs,static void q6v5_pds_detach (struct q6v5 *qproc,struct device **pds,size_t pd_count) { +struct device *dev = qproc->dev;int i; +/* Handle single power domain */ +if (pd_count ==1 && dev->pm_domain) { +pm_runtime_disable (dev); +return ; + } +for (i =0 ; i < pd_count; i++)dev_pm_domain_detach (pds[i], false); }
@@ -2081,13 +2095,13 @@ static const struct rproc_hexagon_res msm8974_mss = { .supply = "pll", .uA = 100000, }, - {} - }, - .fallback_proxy_supply = (struct qcom_mss_reg_res[]) { { .supply = "mx", .uV = 1050000, }, + {} + }, + .fallback_proxy_supply = (struct qcom_mss_reg_res[]) { { .supply ="cx" , .uA =100000 ,
@@ -2113,7 +2127,6 @@ static const struct rproc_hexagon_res msm8974_mss = {NULL }, .proxy_pd_names = (char *[]){ -"mx" ,"cx" ,NULL },
Signature · 1 line
2.39.5
Greg Kroah-Hartman
maintainerPATCH 181/279 IB/mad: Check available slots before posting receive WRs
In reply to Greg Kroah-Hartman5.15-stable review patch. If anyone has any objections, please let me know.
------------------
From: Maher Sanalla <[email protected]>
[ Upstream commit 37826f0a8c2f6b6add5179003b8597e32a445362 ]
The ib_post_receive_mads() function handles posting receive work requests (WRs) to MAD QPs and is called in two cases:
1) When a MAD port is opened.
2) When a receive WQE is consumed upon receiving a new MAD.
Whereas, if MADs arrive during the port open phase, a race condition might cause an extra WR to be posted, exceeding the QP’s capacity. This leads to failures such as:
infiniband mlx5_0: ib_post_recv failed: -12
infiniband mlx5_0: Couldn't post receive WRs
infiniband mlx5_0: Couldn't start port
infiniband mlx5_0: Couldn't open port 1
Fix this by checking the current receive count before posting a new WR. If the QP’s receive queue is full, do not post additional WRs.
--- drivers/infiniband/core/mad.c | 38 ++++++++++++++++++----------------- 1 file changed, 20 insertions(+), 18 deletions(-)
drivers/infiniband/core/mad.c +20 -18
@@ -2671,11 +2671,11 @@ static int ib_mad_post_receive_mads(struct ib_mad_qp_info *qp_info, struct ib_mad_private *mad) {unsigned long flags; -int post, ret;struct ib_mad_private *mad_priv;struct ib_sge sg_list;struct ib_recv_wr recv_wr;struct ib_mad_queue *recv_queue = &qp_info->recv_queue; +int ret =0 ;/* Initialize common scatter list fields */ sg_list.lkey = qp_info->port_priv->pd->local_dma_lkey;
@@ -2685,7 +2685,7 @@ static int ib_mad_post_receive_mads(struct ib_mad_qp_info *qp_info, recv_wr.sg_list = &sg_list; recv_wr.num_sge =1 ; - do { +while (true) {/* Allocate and map receive buffer */ if (mad) { mad_priv = mad;
@@ -2693,10 +2693,8 @@ static int ib_mad_post_receive_mads(struct ib_mad_qp_info *qp_info, }else { mad_priv =alloc_mad_private (port_mad_size (qp_info->port_priv),GFP_ATOMIC ); -if (!mad_priv) { - ret = -ENOMEM ; -break ; - } +if (!mad_priv) +return -ENOMEM ; } sg_list.length =mad_priv_dma_size (mad_priv); sg_list.addr = ib_dma_map_single(qp_info->port_priv->device,
@@ -2705,37 +2703,41 @@ static int ib_mad_post_receive_mads(struct ib_mad_qp_info *qp_info, DMA_FROM_DEVICE);if (unlikely (ib_dma_mapping_error (qp_info->port_priv->device, sg_list.addr))) { -kfree (mad_priv); ret = -ENOMEM ; -break ; + goto free_mad_priv; } mad_priv->header.mapping = sg_list.addr; mad_priv->header.mad_list.mad_queue = recv_queue; mad_priv->header.mad_list.cqe.done = ib_mad_recv_done; recv_wr.wr_cqe = &mad_priv->header.mad_list.cqe; - -/* Post receive WR */ spin_lock_irqsave (&recv_queue->lock, flags); - post = (++recv_queue->count < recv_queue->max_active); -list_add_tail (&mad_priv->header.mad_list.list, &recv_queue->list); +if (recv_queue->count >= recv_queue->max_active) { +/* Fully populated the receive queue */ +spin_unlock_irqrestore (&recv_queue->lock, flags); +break ; + } + recv_queue->count++; +list_add_tail (&mad_priv->header.mad_list.list, + &recv_queue->list);spin_unlock_irqrestore (&recv_queue->lock, flags); + ret =ib_post_recv (qp_info->qp, &recv_wr,NULL );if (ret) {spin_lock_irqsave (&recv_queue->lock, flags);list_del (&mad_priv->header.mad_list.list); recv_queue->count--;spin_unlock_irqrestore (&recv_queue->lock, flags); -ib_dma_unmap_single (qp_info->port_priv->device, - mad_priv->header.mapping, -mad_priv_dma_size (mad_priv), -DMA_FROM_DEVICE ); -kfree (mad_priv);dev_err (&qp_info->port_priv->device->dev,"ib_post_recv failed: %d\n" , ret);break ; } - }while (post); + } +ib_dma_unmap_single (qp_info->port_priv->device, + mad_priv->header.mapping, +mad_priv_dma_size (mad_priv),DMA_FROM_DEVICE ); +free_mad_priv: +kfree (mad_priv);return ret; }
Signature · 1 line
2.39.5
Greg Kroah-Hartman
maintainerPATCH 182/279 pinctrl: tegra: Set SFIO mode to Mux Register
In reply to Greg Kroah-Hartman5.15-stable review patch. If anyone has any objections, please let me know.
------------------
From: Prathamesh Shete <[email protected]>
[ Upstream commit 17013f0acb322e5052ff9b9d0fab0ab5a4bfd828 ]
Tegra devices have an 'sfsel' bit field that determines whether a pin operates in SFIO (Special Function I/O) or GPIO mode. Currently, tegra_pinctrl_gpio_disable_free() sets this bit when releasing a GPIO.
However, tegra_pinctrl_set_mux() can be called independently in certain code paths where gpio_disable_free() is not invoked. In such cases, failing to set the SFIO mode could lead to incorrect pin configurations, resulting in functional issues for peripherals relying on SFIO.
This patch ensures that whenever set_mux() is called, the SFIO mode is correctly set in the Mux Register if the 'sfsel' bit is present. This prevents situations where the pin remains in GPIO mode despite being configured for SFIO use.
--- drivers/pinctrl/tegra/pinctrl-tegra.c | 3 +++ 1 file changed, 3 insertions(+)
drivers/pinctrl/tegra/pinctrl-tegra.c +3 -0
@@ -270,6 +270,9 @@ static int tegra_pinctrl_set_mux(struct pinctrl_dev *pctldev, val =pmx_readl (pmx, g->mux_bank, g->mux_reg); val &= ~(0x3 << g->mux_bit); val |= i << g->mux_bit; +/* Set the SFIO/GPIO selection to SFIO when under pinmux control*/ +if (pmx->soc->sfsel_in_mux) + val |= (1 << g->sfsel_bit);pmx_writel (pmx, val, g->mux_bank, g->mux_reg);return 0 ;
Signature · 1 line
2.39.5
Greg Kroah-Hartman
maintainerPATCH 183/279 clk: amlogic: g12b: fix cluster A parent data
In reply to Greg Kroah-Hartman5.15-stable review patch. If anyone has any objections, please let me know.
------------------
From: Jerome Brunet <[email protected]>
[ Upstream commit 8995f8f108c3ac5ad52b12a6cfbbc7b3b32e9a58 ]
Several clocks used by both g12a and g12b use the g12a cpu A clock hw pointer as clock parent. This is incorrect on g12b since the parents of cluster A cpu clock are different. Also the hw clock provided as parent to these children is not even registered clock on g12b.
Fix the problem by reverting to the global namespace and let CCF pick the appropriate, as it is already done for other clocks, such as cpu_clk_trace_div.
--- drivers/clk/meson/g12a.c | 36 ++++++++++++++++++++++++------------ 1 file changed, 24 insertions(+), 12 deletions(-)
drivers/clk/meson/g12a.c +24 -12
@@ -1136,8 +1136,18 @@ static struct clk_regmap g12a_cpu_clk_div16_en = { .hw.init = &(struct clk_init_data) { .name ="cpu_clk_div16_en" , .ops = &clk_regmap_gate_ro_ops, - .parent_hws = (const struct clk_hw *[]) { - &g12a_cpu_clk.hw + .parent_data = &(const struct clk_parent_data ) { +/* +* Note: +* G12A and G12B have different cpu clocks (with +* different struct clk_hw). We fallback to the global +* naming string mechanism so this clock picks +* up the appropriate one. Same goes for the other +* clock using cpu cluster A clock output and present +* on both G12 variant. +*/ + .name ="cpu_clk" , + .index =-1 , }, .num_parents =1 ,/*
@@ -1202,7 +1212,10 @@ static struct clk_regmap g12a_cpu_clk_apb_div = { .hw.init = &(struct clk_init_data){ .name ="cpu_clk_apb_div" , .ops = &clk_regmap_divider_ro_ops, - .parent_hws = (const struct clk_hw *[]) { &g12a_cpu_clk.hw }, + .parent_data = &(const struct clk_parent_data ) { + .name ="cpu_clk" , + .index =-1 , + }, .num_parents =1 , }, };
@@ -1236,7 +1249,10 @@ static struct clk_regmap g12a_cpu_clk_atb_div = { .hw.init = &(struct clk_init_data){ .name ="cpu_clk_atb_div" , .ops = &clk_regmap_divider_ro_ops, - .parent_hws = (const struct clk_hw *[]) { &g12a_cpu_clk.hw }, + .parent_data = &(const struct clk_parent_data ) { + .name ="cpu_clk" , + .index =-1 , + }, .num_parents =1 , }, };
@@ -1270,7 +1286,10 @@ static struct clk_regmap g12a_cpu_clk_axi_div = { .hw.init = &(struct clk_init_data){ .name ="cpu_clk_axi_div" , .ops = &clk_regmap_divider_ro_ops, - .parent_hws = (const struct clk_hw *[]) { &g12a_cpu_clk.hw }, + .parent_data = &(const struct clk_parent_data ) { + .name ="cpu_clk" , + .index =-1 , + }, .num_parents =1 , }, };
@@ -1305,13 +1324,6 @@ static struct clk_regmap g12a_cpu_clk_trace_div = { .name = "cpu_clk_trace_div", .ops = &clk_regmap_divider_ro_ops, .parent_data = &(const struct clk_parent_data ) { -/* -* Note: -* G12A and G12B have different cpu_clks (with -* different struct clk_hw). We fallback to the global -* naming string mechanism so cpu_clk_trace_div picks -* up the appropriate one. -*/ .name ="cpu_clk" , .index =-1 , },
Signature · 1 line
2.39.5
Greg Kroah-Hartman
maintainerPATCH 184/279 clk: amlogic: gxbb: drop non existing 32k clock parent
In reply to Greg Kroah-Hartman5.15-stable review patch. If anyone has any objections, please let me know.
------------------
From: Jerome Brunet <[email protected]>
[ Upstream commit 7915d7d5407c026fa9343befb4d3343f7a345f97 ]
The 32k clock reference a parent 'cts_slow_oscin' with a fixme note saying that this clock should be provided by AO controller.
The HW probably has this clock but it does not exist at the moment in any controller implementation. Furthermore, referencing clock by the global name should be avoided whenever possible.
There is no reason to keep this hack around, at least for now.
--- drivers/clk/meson/gxbb.c | 12 ++++++------ 1 file changed, 6 insertions(+), 6 deletions(-)
drivers/clk/meson/gxbb.c +6 -6
@@ -1270,14 +1270,13 @@ static struct clk_regmap gxbb_cts_i958 = { }, }; +/* +* This table skips a clock named 'cts_slow_oscin' in the documentation +* This clock does not exist yet in this controller or the AO one +*/ +static u32 gxbb_32k_clk_parents_val_table[] = {0 ,2 ,3 };static const struct clk_parent_data gxbb_32k_clk_parent_data[] = { { .fw_name ="xtal" , }, -/* -* FIXME: This clock is provided by the ao clock controller but the -* clock is not yet part of the binding of this controller, so string -* name must be use to set this parent. -*/ - { .name ="cts_slow_oscin" , .index =-1 }, { .hw = &gxbb_fclk_div3.hw }, { .hw = &gxbb_fclk_div5.hw }, };
@@ -1287,6 +1286,7 @@ static struct clk_regmap gxbb_32k_clk_sel = { .offset = HHI_32K_CLK_CNTL, .mask = 0x3, .shift = 16, + .table = gxbb_32k_clk_parents_val_table, }, .hw.init = &(struct clk_init_data ){ .name ="32k_clk_sel" ,
Signature · 1 line
2.39.5
Greg Kroah-Hartman
maintainerPATCH 185/279 clk: amlogic: g12a: fix mmc A peripheral clock
In reply to Greg Kroah-Hartman5.15-stable review patch. If anyone has any objections, please let me know.
------------------
From: Jerome Brunet <[email protected]>
[ Upstream commit 0079e77c08de692cb20b38e408365c830a44b1ef ]
The bit index of the peripheral clock for mmc A is wrong
This was probably not a problem for mmc A as the peripheral is likely left enabled by the bootloader.
No issues has been reported so far but it could be a problem, most likely some form of conflict between the ethernet and mmc A clock, breaking ethernet on init.
Use the value provided by the documentation for mmc A before this becomes an actual problem.
--- drivers/clk/meson/g12a.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/clk/meson/g12a.c +1 -1
@@ -4199,7 +4199,7 @@ static MESON_GATE(g12a_spicc_1, HHI_GCLK_MPEG0, 14); static MESON_GATE(g12a_hiu_reg, HHI_GCLK_MPEG0, 19); static MESON_GATE(g12a_mipi_dsi_phy, HHI_GCLK_MPEG0, 20); static MESON_GATE(g12a_assist_misc, HHI_GCLK_MPEG0, 23); -static MESON_GATE(g12a_emmc_a, HHI_GCLK_MPEG0, 4); +static MESON_GATE(g12a_emmc_a, HHI_GCLK_MPEG0, 24); static MESON_GATE(g12a_emmc_b, HHI_GCLK_MPEG0, 25); static MESON_GATE(g12a_emmc_c, HHI_GCLK_MPEG0, 26); static MESON_GATE(g12a_audio_codec, HHI_GCLK_MPEG0, 28);
Signature · 1 line
2.39.5
Greg Kroah-Hartman
maintainerPATCH 186/279 x86/entry: Fix ORC unwinder for PUSH_REGS with save_ret=1
In reply to Greg Kroah-Hartman5.15-stable review patch. If anyone has any objections, please let me know.
------------------
From: Jann Horn <[email protected]>
[ Upstream commit 57e2428f8df8263275344566e02c277648a4b7f1 ]
PUSH_REGS with save_ret=1 is used by interrupt entry helper functions that initially start with a UNWIND_HINT_FUNC ORC state.
However, save_ret=1 means that we clobber the helper function's return address (and then later restore the return address further down on the stack); after that point, the only thing on the stack we can unwind through is the IRET frame, so use UNWIND_HINT_IRET_REGS until we have a full pt_regs frame.
( An alternate approach would be to move the pt_regs->di overwrite down
such that it is the final step of pt_regs setup; but I don't want to rearrange entry code just to make unwinding a tiny bit more elegant. )
--- arch/x86/entry/calling.h | 2 ++ 1 file changed, 2 insertions(+)
arch/x86/entry/calling.h +2 -0
@@ -70,6 +70,8 @@ For 32-bit we have the following conventions - kernel is built with pushq %rsi /* pt_regs->si */ movq 8(%rsp), %rsi /* temporarily store the return address in %rsi */ movq %rdi, 8(%rsp) /* pt_regs->di (overwriting original return address) */ +/* We just clobbered the return address - use the IRET frame for unwinding: */ +UNWIND_HINT_IRET_REGS offset=3 *8 .else pushq %rdi /* pt_regs->di */ pushq %rsi/* pt_regs->si */
Signature · 1 line
2.39.5
Greg Kroah-Hartman
maintainerPATCH 187/279 power: supply: max77693: Fix wrong conversion of charge input threshold value
In reply to Greg Kroah-Hartman5.15-stable review patch. If anyone has any objections, please let me know.
------------------
From: Artur Weber <[email protected]>
[ Upstream commit 30cc7b0d0e9341d419eb7da15fb5c22406dbe499 ]
The charge input threshold voltage register on the MAX77693 PMIC accepts four values: 0x0 for 4.3v, 0x1 for 4.7v, 0x2 for 4.8v and 0x3 for 4.9v. Due to an oversight, the driver calculated the values for 4.7v and above starting from 0x0, rather than from 0x1 ([(4700000 - 4700000) / 100000] gives 0).
Add 1 to the calculation to ensure that 4.7v is converted to a register value of 0x1 and that the other two voltages are converted correctly as well.
--- drivers/power/supply/max77693_charger.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/power/supply/max77693_charger.c +1 -1
@@ -556,7 +556,7 @@ static int max77693_set_charge_input_threshold_volt(struct max77693_charger *chgcase 4700000 :case 4800000 :case 4900000 : - data = (uvolt -4700000 ) /100000 ; + data = ((uvolt -4700000 ) /100000 ) +1 ;break ;default :dev_err (chg->dev,"Wrong value for charge input voltage regulation threshold\n" );
Signature · 1 line
2.39.5
Greg Kroah-Hartman
maintainerPATCH 188/279 crypto: nx - Fix uninitialised hv_nxc on error
In reply to Greg Kroah-Hartman5.15-stable review patch. If anyone has any objections, please let me know.
------------------
From: Herbert Xu <[email protected]>
[ Upstream commit 9b00eb923f3e60ca76cbc8b31123716f3a87ac6a ]
The compiler correctly warns that hv_nxc may be used uninitialised as that will occur when NX-GZIP is unavailable.
Fix it by rearranging the code and delay setting caps_feat until the final query succeeds.
--- drivers/crypto/nx/nx-common-pseries.c | 37 ++++++++++++--------------- 1 file changed, 17 insertions(+), 20 deletions(-)
drivers/crypto/nx/nx-common-pseries.c +17 -20
@@ -1142,6 +1142,7 @@ static void __init nxcop_get_capabilities(void) {struct hv_vas_all_caps *hv_caps;struct hv_nx_cop_caps *hv_nxc; +u64 feat;int rc; hv_caps =kmalloc (sizeof (*hv_caps),GFP_KERNEL );
@@ -1152,27 +1153,26 @@ static void __init nxcop_get_capabilities(void)*/ rc =h_query_vas_capabilities (H_QUERY_NX_CAPABILITIES ,0 , (u64 )virt_to_phys (hv_caps)); +if (!rc) + feat =be64_to_cpu (hv_caps->feat_type); +kfree (hv_caps);if (rc) - goto out; +return ; +if (!(feat &VAS_NX_GZIP_FEAT_BIT )) +return ; - caps_feat =be64_to_cpu (hv_caps->feat_type);/* * NX-GZIP feature available */ -if (caps_feat &VAS_NX_GZIP_FEAT_BIT ) { - hv_nxc =kmalloc (sizeof (*hv_nxc),GFP_KERNEL ); -if (!hv_nxc) - goto out; -/* -* Get capabilities for NX-GZIP feature -*/ - rc =h_query_vas_capabilities (H_QUERY_NX_CAPABILITIES , -VAS_NX_GZIP_FEAT , - (u64 )virt_to_phys (hv_nxc)); - }else { -pr_err ("NX-GZIP feature is not available\n" ); - rc = -EINVAL ; - } + hv_nxc =kmalloc (sizeof (*hv_nxc),GFP_KERNEL ); +if (!hv_nxc) +return ; +/* +* Get capabilities for NX-GZIP feature +*/ + rc =h_query_vas_capabilities (H_QUERY_NX_CAPABILITIES , +VAS_NX_GZIP_FEAT , + (u64 )virt_to_phys (hv_nxc));if (!rc) { nx_cop_caps.descriptor =be64_to_cpu (hv_nxc->descriptor);
@@ -1182,13 +1182,10 @@ static void __init nxcop_get_capabilities(void)be64_to_cpu (hv_nxc->min_compress_len); nx_cop_caps.min_decompress_len =be64_to_cpu (hv_nxc->min_decompress_len); - }else { - caps_feat =0 ; + caps_feat = feat; }kfree (hv_nxc); -out: -kfree (hv_caps); }static const struct vio_device_id nx842_vio_driver_ids[] = {
Signature · 1 line
2.39.5
Greg Kroah-Hartman
maintainerPATCH 189/279 RDMA/mlx5: Fix mlx5_poll_one() cur_qp update flow
In reply to Greg Kroah-Hartman5.15-stable review patch. If anyone has any objections, please let me know.
------------------
From: Patrisious Haddad <[email protected]>
[ Upstream commit 5ed3b0cb3f827072e93b4c5b6e2b8106fd7cccbd ]
When cur_qp isn't NULL, in order to avoid fetching the QP from the radix tree again we check if the next cqe QP is identical to the one we already have.
The bug however is that we are checking if the QP is identical by checking the QP number inside the CQE against the QP number inside the mlx5_ib_qp, but that's wrong since the QP number from the CQE is from FW so it should be matched against mlx5_core_qp which is our FW QP number.
Otherwise we could use the wrong QP when handling a CQE which could cause the kernel trace below.
This issue is mainly noticeable over QPs 0 & 1, since for now they are the only QPs in our driver whereas the QP number inside mlx5_ib_qp doesn't match the QP number inside mlx5_core_qp.
BUG: kernel NULL pointer dereference, address: 0000000000000012 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page PGD 0 P4D 0 Oops: Oops: 0000 [#1] SMP CPU: 0 UID: 0 PID: 7927 Comm: kworker/u62:1 Not tainted 6.14.0-rc3+ #189 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.16.3-0-ga6ed6b701f0a-prebuilt.qemu.org 04/01/2014 Workqueue: ib-comp-unb-wq ib_cq_poll_work [ib_core] RIP: 0010:mlx5_ib_poll_cq+0x4c7/0xd90 [mlx5_ib] Code: 03 00 00 8d 58 ff 21 cb 66 39 d3 74 39 48 c7 c7 3c 89 6e a0 0f b7 db e8 b7 d2 b3 e0 49 8b 86 60 03 00 00 48 c7 c7 4a 89 6e a0 <0f> b7 5c 98 02 e8 9f d2 b3 e0 41 0f b7 86 78 03 00 00 83 e8 01 21 RSP: 0018:ffff88810511bd60 EFLAGS: 00010046 RAX: 0000000000000010 RBX: 0000000000000000 RCX: 0000000000000000 RDX: 0000000000000000 RSI: ffff88885fa1b3c0 RDI: ffffffffa06e894a RBP: 00000000000000b0 R08: 0000000000000000 R09: ffff88810511bc10 R10: 0000000000000001 R11: 0000000000000001 R12: ffff88810d593000 R13: ffff88810e579108 R14: ffff888105146000 R15: 00000000000000b0 FS: 0000000000000000(0000) GS:ffff88885fa00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000012 CR3: 00000001077e6001 CR4: 0000000000370eb0 Call Trace: <TASK> ? __die+0x20/0x60 ? page_fault_oops+0x150/0x3e0 ? exc_page_fault+0x74/0x130 ? asm_exc_page_fault+0x22/0x30 ? mlx5_ib_poll_cq+0x4c7/0xd90 [mlx5_ib] __ib_process_cq+0x5a/0x150 [ib_core] ib_cq_poll_work+0x31/0x90 [ib_core] process_one_work+0x169/0x320 worker_thread+0x288/0x3a0 ? work_busy+0xb0/0xb0 kthread+0xd7/0x1f0 ? kthreads_online_cpu+0x130/0x130 ? kthreads_online_cpu+0x130/0x130 ret_from_fork+0x2d/0x50 ? kthreads_online_cpu+0x130/0x130 ret_from_fork_asm+0x11/0x20 </TASK>
--- drivers/infiniband/hw/mlx5/cq.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/infiniband/hw/mlx5/cq.c +1 -1
@@ -481,7 +481,7 @@ static int mlx5_poll_one(struct mlx5_ib_cq *cq, } qpn =ntohl (cqe64->sop_drop_qpn) &0xffffff ; -if (!*cur_qp || (qpn != (*cur_qp)->ibqp.qp_num)) { +if (!*cur_qp || (qpn != (*cur_qp)->trans_qp.base.mqp.qpn)) {/* We do not have to take the QP table lock here, * because CQs will be locked while QPs are removed * from the table.
Signature · 1 line
2.39.5
Greg Kroah-Hartman
maintainerPATCH 190/279 mfd: sm501: Switch to BIT() to mitigate integer overflows
In reply to Greg Kroah-Hartman5.15-stable review patch. If anyone has any objections, please let me know.
------------------
From: Nikita Zhandarovich <[email protected]>
[ Upstream commit 2d8cb9ffe18c2f1e5bd07a19cbce85b26c1d0cf0 ]
If offset end up being high enough, right hand expression in functions like sm501_gpio_set() shifted left for that number of bits, may not fit in int type.
Just in case, fix that by using BIT() both as an option safe from overflow issues and to make this step look similar to other gpio drivers.
Found by Linux Verification Center (linuxtesting.org) with static analysis tool SVACE.
--- drivers/mfd/sm501.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-)
drivers/mfd/sm501.c +3 -3
@@ -920,7 +920,7 @@ static void sm501_gpio_set(struct gpio_chip *chip, unsigned offset, int value) {struct sm501_gpio_chip *smchip =gpiochip_get_data (chip);struct sm501_gpio *smgpio = smchip->ourgpio; -unsigned long bit =1 << offset; +unsigned long bit =BIT (offset);void __iomem *regs = smchip->regbase;unsigned long save;unsigned long val;
@@ -946,7 +946,7 @@ static int sm501_gpio_input(struct gpio_chip *chip, unsigned offset)struct sm501_gpio_chip *smchip =gpiochip_get_data (chip);struct sm501_gpio *smgpio = smchip->ourgpio;void __iomem *regs = smchip->regbase; -unsigned long bit =1 << offset; +unsigned long bit =BIT (offset);unsigned long save;unsigned long ddr;
@@ -971,7 +971,7 @@ static int sm501_gpio_output(struct gpio_chip *chip, {struct sm501_gpio_chip *smchip =gpiochip_get_data (chip);struct sm501_gpio *smgpio = smchip->ourgpio; -unsigned long bit =1 << offset; +unsigned long bit =BIT (offset);void __iomem *regs = smchip->regbase;unsigned long save;unsigned long val;
Signature · 1 line
2.39.5
Greg Kroah-Hartman
maintainerPATCH 191/279 x86/dumpstack: Fix inaccurate unwinding from exception stacks due to misplaced assignment
In reply to Greg Kroah-Hartman5.15-stable review patch. If anyone has any objections, please let me know.
------------------
From: Jann Horn <[email protected]>
[ Upstream commit 2c118f50d7fd4d9aefc4533a26f83338b2906b7a ]
Commit:
2e4be0d011f2 ("x86/show_trace_log_lvl: Ensure stack pointer is aligned, again")
was intended to ensure alignment of the stack pointer; but it also moved the initialization of the "stack" variable down into the loop header.
This was likely intended as a no-op cleanup, since the commit message does not mention it; however, this caused a behavioral change because the value of "regs" is different between the two places.
Originally, get_stack_pointer() used the regs provided by the caller; after that commit, get_stack_pointer() instead uses the regs at the top of the stack frame the unwinder is looking at. Often, there are no such regs at all, and "regs" is NULL, causing get_stack_pointer() to fall back to the task's current stack pointer, which is not what we want here, but probably happens to mostly work. Other times, the original regs will point to another regs frame - in that case, the linear guess unwind logic in show_trace_log_lvl() will start unwinding too far up the stack, causing the first frame found by the proper unwinder to never be visited, resulting in a stack trace consisting purely of guess lines.
Fix it by moving the "stack = " assignment back where it belongs.
--- arch/x86/kernel/dumpstack.c | 5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-)
arch/x86/kernel/dumpstack.c +2 -3
@@ -195,6 +195,7 @@ static void show_trace_log_lvl(struct task_struct *task, struct pt_regs *regs,printk ("%sCall Trace:\n" , log_lvl);unwind_start (&state, task, regs, stack); + stack = stack ?:get_stack_pointer (task, regs); regs =unwind_get_entry_regs (&state, &partial);/*
@@ -213,9 +214,7 @@ static void show_trace_log_lvl(struct task_struct *task, struct pt_regs *regs,* - hardirq stack * - entry stack */ -for (stack = stack ?:get_stack_pointer (task, regs); - stack; - stack = stack_info.next_sp) { +for (; stack; stack = stack_info.next_sp) {const char *stack_name; stack =PTR_ALIGN (stack,sizeof (long ));
Signature · 1 line
2.39.5
Greg Kroah-Hartman
maintainerPATCH 192/279 crypto: hisilicon/sec2 - fix for aead auth key length
In reply to Greg Kroah-Hartman5.15-stable review patch. If anyone has any objections, please let me know.
------------------
From: Wenkai Lin <[email protected]>
[ Upstream commit 1b284ffc30b02808a0de698667cbcf5ce5f9144e ]
According to the HMAC RFC, the authentication key can be 0 bytes, and the hardware can handle this scenario. Therefore, remove the incorrect validation for this case.
--- drivers/crypto/hisilicon/sec2/sec_crypto.c | 8 ++------ 1 file changed, 2 insertions(+), 6 deletions(-)
drivers/crypto/hisilicon/sec2/sec_crypto.c +2 -6
@@ -1047,11 +1047,6 @@ static int sec_aead_auth_set_key(struct sec_auth_ctx *ctx,struct crypto_shash *hash_tfm = ctx->hash_tfm;int blocksize, digestsize, ret; -if (!keys->authkeylen) { -pr_err ("hisi_sec2: aead auth key error!\n" ); -return -EINVAL ; - } - blocksize =crypto_shash_blocksize (hash_tfm); digestsize =crypto_shash_digestsize (hash_tfm);if (keys->authkeylen > blocksize) {
@@ -1063,7 +1058,8 @@ static int sec_aead_auth_set_key(struct sec_auth_ctx *ctx, } ctx->a_key_len = digestsize; }else { -memcpy (ctx->a_key, keys->authkey, keys->authkeylen); +if (keys->authkeylen) +memcpy (ctx->a_key, keys->authkey, keys->authkeylen); ctx->a_key_len = keys->authkeylen; }
Signature · 1 line
2.39.5
Greg Kroah-Hartman
maintainerPATCH 193/279 clk: qcom: mmcc-sdm660: fix stuck video_subcore0 clock
In reply to Greg Kroah-Hartman5.15-stable review patch. If anyone has any objections, please let me know.
------------------
From: Barnabás Czémán <[email protected]>
[ Upstream commit 000cbe3896c56bf5c625e286ff096533a6b27657 ]
This clock can't be enable with VENUS_CORE0 GDSC turned off. But that GDSC is under HW control so it can be turned off at any moment. Instead of checking the dependent clock we can just vote for it to enable later when GDSC gets turned on.
--- drivers/clk/qcom/mmcc-sdm660.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/clk/qcom/mmcc-sdm660.c +1 -1
@@ -2544,7 +2544,7 @@ static struct clk_branch video_core_clk = {static struct clk_branch video_subcore0_clk = { .halt_reg =0x1048 , - .halt_check =BRANCH_HALT , + .halt_check =BRANCH_HALT_SKIP , .clkr = { .enable_reg =0x1048 , .enable_mask =BIT (0 ),
Signature · 1 line
2.39.5
Greg Kroah-Hartman
maintainerPATCH 194/279 isofs: fix KMSAN uninit-value bug in do_isofs_readdir()
In reply to Greg Kroah-Hartman5.15-stable review patch. If anyone has any objections, please let me know.
------------------
From: Qasim Ijaz <[email protected]>
[ Upstream commit 81a82e8f33880793029cd6f8a766fb13b737e6a7 ]
In do_isofs_readdir() when assigning the variable
"struct iso_directory_record *de" the b_data field of the buffer_head is accessed and an offset is added to it, the size of b_data is 2048 and the offset size is 2047, meaning
"de = (struct iso_directory_record *) (bh->b_data + offset);" yields the final byte of the 2048 sized b_data block.
The first byte of the directory record (de_len) is then read and found to be 31, meaning the directory record size is 31 bytes long. The directory record is defined by the structure:
struct iso_directory_record {
__u8 length; // 1 byte
__u8 ext_attr_length; // 1 byte
__u8 extent[8]; // 8 bytes
__u8 size[8]; // 8 bytes
__u8 date[7]; // 7 bytes
__u8 flags; // 1 byte
__u8 file_unit_size; // 1 byte
__u8 interleave; // 1 byte
__u8 volume_sequence_number[4]; // 4 bytes
__u8 name_len; // 1 byte
char name[]; // variable size
} __attribute__((packed));
The fixed portion of this structure occupies 33 bytes. Therefore, a valid directory record must be at least 33 bytes long (even without considering the variable-length name field). Since de_len is only 31, it is insufficient to contain the complete fixed header.
The code later hits the following sanity check that compares de_len against the sum of de->name_len and sizeof(struct iso_directory_record):
if (de_len < de->name_len[0] + sizeof(struct iso_directory_record)) {
...
}Since the fixed portion of the structure is
33 bytes (up to and including name_len member),
a valid record should have de_len of at least 33 bytes; here, however, de_len is too short, and the field de->name_len (located at offset 32) is accessed even though it lies beyond the available 31 bytes.
This access on the corrupted isofs data triggers a KASAN uninitialized memory warning. The fix would be to first verify that de_len is at least sizeof(struct iso_directory_record) before accessing any fields like de->name_len.
--- fs/isofs/dir.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-)
fs/isofs/dir.c +2 -1
@@ -147,7 +147,8 @@ static int do_isofs_readdir(struct inode *inode, struct file *file, de = tmpde; }/* Basic sanity check, whether name doesn't exceed dir entry */ -if (de_len < de->name_len[0 ] + +if (de_len <sizeof (struct iso_directory_record ) || + de_len < de->name_len[0 ] +sizeof (struct iso_directory_record )) { printk(KERN_NOTICE "iso9660: Corrupted directory entry" " in block %lu of inode %lu\n", block,
Signature · 1 line
2.39.5
Greg Kroah-Hartman
maintainerPATCH 195/279 soundwire: slave: fix an OF node reference leak in soundwire slave device
In reply to Greg Kroah-Hartman5.15-stable review patch. If anyone has any objections, please let me know.
------------------
From: Joe Hattori <[email protected]>
[ Upstream commit aac2f8363f773ae1f65aab140e06e2084ac6b787 ]
When initializing a soundwire slave device, an OF node is stored to the device with refcount incremented. However, the refcount is not decremented in .release(), thus call of_node_put() in sdw_slave_release().
--- drivers/soundwire/slave.c | 1 + 1 file changed, 1 insertion(+)
drivers/soundwire/slave.c +1 -0
@@ -12,6 +12,7 @@ static void sdw_slave_release(struct device *dev) {struct sdw_slave *slave =dev_to_sdw_dev (dev); +of_node_put (slave->dev.of_node);mutex_destroy (&slave->sdw_dev_lock);kfree (slave); }
Signature · 1 line
2.39.5
Greg Kroah-Hartman
maintainerPATCH 196/279 coresight: catu: Fix number of pages while using 64k pages
In reply to Greg Kroah-Hartman5.15-stable review patch. If anyone has any objections, please let me know.
------------------
From: Ilkka Koskinen <[email protected]>
[ Upstream commit 0e14e062f5ff98aa15264dfa87c5f5e924028561 ]
Trying to record a trace on kernel with 64k pages resulted in -ENOMEM. This happens due to a bug in calculating the number of table pages, which returns zero. Fix the issue by rounding up.
$ perf record --kcore -e cs_etm/@tmc_etr55,cycacc,branch_broadcast/k --per-thread taskset --cpu-list 1 dd if=/dev/zero of=/dev/null failed to mmap with 12 (Cannot allocate memory)
--- drivers/hwtracing/coresight/coresight-catu.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/hwtracing/coresight/coresight-catu.c +1 -1
@@ -267,7 +267,7 @@ catu_init_sg_table(struct device *catu_dev, int node,* Each table can address upto 1MB and we can have * CATU_PAGES_PER_SYSPAGE tables in a system page. */ - nr_tpages =DIV_ROUND_UP (size,SZ_1M ) /CATU_PAGES_PER_SYSPAGE ; + nr_tpages =DIV_ROUND_UP (size,CATU_PAGES_PER_SYSPAGE *SZ_1M ); catu_table =tmc_alloc_sg_table (catu_dev, node, nr_tpages, size >>PAGE_SHIFT , pages);if (IS_ERR (catu_table))
Signature · 1 line
2.39.5
Greg Kroah-Hartman
maintainerPATCH 197/279 iio: accel: mma8452: Ensure error return on failure to matching oversampling ratio
In reply to Greg Kroah-Hartman5.15-stable review patch. If anyone has any objections, please let me know.
------------------
From: Jonathan Cameron <[email protected]>
[ Upstream commit df330c808182a8beab5d0f84a6cbc9cff76c61fc ]
If a match was not found, then the write_raw() callback would return the odr index, not an error. Return -EINVAL if this occurs. To avoid similar issues in future, introduce j, a new indexing variable rather than using ret for this purpose.
--- drivers/iio/accel/mma8452.c | 10 +++++++--- 1 file changed, 7 insertions(+), 3 deletions(-)
drivers/iio/accel/mma8452.c +7 -3
@@ -709,7 +709,7 @@ static int mma8452_write_raw(struct iio_dev *indio_dev, int val, int val2, long mask) { struct mma8452_data *data = iio_priv(indio_dev); -int i, ret; +int i, j, ret; ret =iio_device_claim_direct_mode (indio_dev);if (ret)
@@ -769,14 +769,18 @@ static int mma8452_write_raw(struct iio_dev *indio_dev,break ;case IIO_CHAN_INFO_OVERSAMPLING_RATIO : - ret =mma8452_get_odr_index (data); + j =mma8452_get_odr_index (data);for (i =0 ; i <ARRAY_SIZE (mma8452_os_ratio); i++) { -if (mma8452_os_ratio[i][ret] == val) { +if (mma8452_os_ratio[i][j] == val) { ret =mma8452_set_power_mode (data, i);break ; } } +if (i ==ARRAY_SIZE (mma8452_os_ratio)) { + ret = -EINVAL ; +break ; + }break ;default : ret = -EINVAL ;
Signature · 1 line
2.39.5
Greg Kroah-Hartman
maintainerPATCH 198/279 fs/ntfs3: Fix a couple integer overflows on 32bit systems
In reply to Greg Kroah-Hartman5.15-stable review patch. If anyone has any objections, please let me know.
------------------
From: Dan Carpenter <[email protected]>
[ Upstream commit 5ad414f4df2294b28836b5b7b69787659d6aa708 ]
On 32bit systems the "off + sizeof(struct NTFS_DE)" addition can have an integer wrapping issue. Fix it by using size_add().
--- fs/ntfs3/index.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
fs/ntfs3/index.c +2 -2
@@ -617,7 +617,7 @@ static bool index_hdr_check(const struct INDEX_HDR *hdr, u32 bytes)u32 off =le32_to_cpu (hdr->de_off);if (!IS_ALIGNED (off,8 ) || tot > bytes || end > tot || - off +sizeof (struct NTFS_DE ) > end) { +size_add (off,sizeof (struct NTFS_DE )) > end) {/* incorrect index buffer. */ return false; }
@@ -736,7 +736,7 @@ static struct NTFS_DE *hdr_find_e(const struct ntfs_index *indx,if (end > total)return NULL ; -if (off +sizeof (struct NTFS_DE ) > end) +if (size_add (off,sizeof (struct NTFS_DE )) > end)return NULL ; e =Add2Ptr (hdr, off);
Signature · 1 line
2.39.5
Greg Kroah-Hartman
maintainerPATCH 199/279 iio: adc: ad7124: Fix comparison of channel configs
In reply to Greg Kroah-Hartman5.15-stable review patch. If anyone has any objections, please let me know.
------------------
From: Uwe Kleine-König <[email protected]>
[ Upstream commit 05a5d874f7327b75e9bc4359618017e047cc129c ]
Checking the binary representation of two structs (of the same type) for equality doesn't have the same semantic as comparing all members for equality. The former might find a difference where the latter doesn't in the presence of padding or when ambiguous types like float or bool are involved. (Floats typically have different representations for single values, like -0.0 vs +0.0, or 0.5 * 2² vs 0.25 * 2³. The type bool has at least 8 bits and the raw values 1 and 2 (probably) both evaluate to true, but memcmp finds a difference.)
When searching for a channel that already has the configuration we need, the comparison by member is the one that is needed.
Convert the comparison accordingly to compare the members one after another. Also add a static_assert guard to (somewhat) ensure that when struct ad7124_channel_config::config_props is expanded, the comparison is adapted, too.
This issue is somewhat theoretic, but using memcmp() on a struct is a bad pattern that is worth fixing.
--- drivers/iio/adc/ad7124.c | 35 +++++++++++++++++++++++++++++++---- 1 file changed, 31 insertions(+), 4 deletions(-)
drivers/iio/adc/ad7124.c +31 -4
@@ -144,7 +144,11 @@ struct ad7124_chip_info {struct ad7124_channel_config {bool live;unsigned int cfg_slot; -/* Following fields are used to compare equality. */ +/* +* Following fields are used to compare for equality. If you +* make adaptations in it, you most likely also have to adapt +* ad7124_find_similar_live_cfg(), too. +*/ struct_group(config_props, enum ad7124_ref_sel refsel;bool bipolar;
@@ -331,15 +335,38 @@ static struct ad7124_channel_config *ad7124_find_similar_live_cfg(struct ad7124_ struct ad7124_channel_config *cfg) {struct ad7124_channel_config *cfg_aux; -ptrdiff_t cmp_size;int i; - cmp_size = sizeof_field(struct ad7124_channel_config, config_props); +/* +* This is just to make sure that the comparison is adapted after +* struct ad7124_channel_config was changed. +*/ + static_assert(sizeof_field(struct ad7124_channel_config, config_props) == +sizeof (struct { +enum ad7124_ref_sel refsel; +bool bipolar; +bool buf_positive; +bool buf_negative; +unsigned int vref_mv; +unsigned int pga_bits; +unsigned int odr; +unsigned int odr_sel_bits; +unsigned int filter_type; + })); +for (i =0 ; i < st->num_channels; i++) { cfg_aux = &st->channels[i].cfg;if (cfg_aux->live && - !memcmp (&cfg->config_props, &cfg_aux->config_props, cmp_size)) + cfg->refsel == cfg_aux->refsel && + cfg->bipolar == cfg_aux->bipolar && + cfg->buf_positive == cfg_aux->buf_positive && + cfg->buf_negative == cfg_aux->buf_negative && + cfg->vref_mv == cfg_aux->vref_mv && + cfg->pga_bits == cfg_aux->pga_bits && + cfg->odr == cfg_aux->odr && + cfg->odr_sel_bits == cfg_aux->odr_sel_bits && + cfg->filter_type == cfg_aux->filter_type)return cfg_aux; }
Signature · 1 line
2.39.5
Greg Kroah-Hartman
maintainerPATCH 200/279 perf units: Fix insufficient array space
In reply to Greg Kroah-Hartman5.15-stable review patch. If anyone has any objections, please let me know.
------------------
From: Arnaldo Carvalho de Melo <[email protected]>
[ Upstream commit cf67629f7f637fb988228abdb3aae46d0c1748fe ]
No need to specify the array size, let the compiler figure that out.
This addresses this compiler warning that was noticed while build testing on fedora rawhide:
31 15.81 fedora:rawhide : FAIL gcc version 15.0.1 20250225 (Red Hat 15.0.1-0) (GCC)
util/units.c: In function 'unit_number__scnprintf':
util/units.c:67:24: error: initializer-string for array of 'char' is too long [-Werror=unterminated-string-initialization]
67 | char unit[4] = "BKMG";
| ^~~~~~
cc1: all warnings being treated as errors
--- tools/perf/util/units.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
tools/perf/util/units.c +1 -1
@@ -64,7 +64,7 @@ unsigned long convert_unit(unsigned long value, char *unit)int unit_number__scnprintf (char *buf,size_t size,u64 n) { -char unit[4 ] ="BKMG" ; +char unit[] ="BKMG" ;int i =0 ;while (((n /1024 ) >1 ) && (i <3 )) {
Signature · 1 line
2.39.5
Greg Kroah-Hartman
maintainerPATCH 201/279 kexec: initialize ELF lowest address to ULONG_MAX
In reply to Greg Kroah-Hartman5.15-stable review patch. If anyone has any objections, please let me know.
------------------
From: Sourabh Jain <[email protected]>
[ Upstream commit 9986fb5164c8b21f6439cfd45ba36d8cc80c9710 ]
Patch series "powerpc/crash: use generic crashkernel reservation", v3.
Commit 0ab97169aa05 ("crash_core: add generic function to do reservation") added a generic function to reserve crashkernel memory. So let's use the same function on powerpc and remove the architecture-specific code that essentially does the same thing.
The generic crashkernel reservation also provides a way to split the crashkernel reservation into high and low memory reservations, which can be enabled for powerpc in the future.
Additionally move powerpc to use generic APIs to locate memory hole for kexec segments while loading kdump kernel.
This patch (of 7):
kexec_elf_load() loads an ELF executable and sets the address of the lowest PT_LOAD section to the address held by the lowest_load_addr function argument.
To determine the lowest PT_LOAD address, a local variable lowest_addr (type unsigned long) is initialized to UINT_MAX. After loading each PT_LOAD, its address is compared to lowest_addr. If a loaded PT_LOAD address is lower, lowest_addr is updated. However, setting lowest_addr to UINT_MAX won't work when the kernel image is loaded above 4G, as the returned lowest PT_LOAD address would be invalid. This is resolved by initializing lowest_addr to ULONG_MAX instead.
This issue was discovered while implementing crashkernel high/low reservation on the PowerPC architecture.
--- kernel/kexec_elf.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
kernel/kexec_elf.c +1 -1
@@ -390,7 +390,7 @@ int kexec_elf_load(struct kimage *image, struct elfhdr *ehdr,struct kexec_buf *kbuf, unsigned long *lowest_load_addr) { - unsigned long lowest_addr = UINT_MAX; + unsigned long lowest_addr = ULONG_MAX;int ret;size_t i;
Signature · 1 line
2.39.5
Greg Kroah-Hartman
maintainerPATCH 202/279 ocfs2: validate l_tree_depth to avoid out-of-bounds access
In reply to Greg Kroah-Hartman5.15-stable review patch. If anyone has any objections, please let me know.
------------------
From: Vasiliy Kovalev <[email protected]>
[ Upstream commit a406aff8c05115119127c962cbbbbd202e1973ef ]
The l_tree_depth field is 16-bit (__le16), but the actual maximum depth is limited to OCFS2_MAX_PATH_DEPTH.
Add a check to prevent out-of-bounds access if l_tree_depth has an invalid value, which may occur when reading from a corrupted mounted disk [1].
--- fs/ocfs2/alloc.c | 8 ++++++++ 1 file changed, 8 insertions(+)
fs/ocfs2/alloc.c +8 -0
@@ -1796,6 +1796,14 @@ static int __ocfs2_find_path(struct ocfs2_caching_info *ci, el = root_el;while (el->l_tree_depth) { +if (unlikely (le16_to_cpu (el->l_tree_depth) >=OCFS2_MAX_PATH_DEPTH )) { +ocfs2_error (ocfs2_metadata_cache_get_super (ci), +"Owner %llu has invalid tree depth %u in extent list\n" , + (unsigned long long )ocfs2_metadata_cache_owner (ci), +le16_to_cpu (el->l_tree_depth)); + ret = -EROFS ; + goto out; + }if (le16_to_cpu (el->l_next_free_rec) ==0 ) { ocfs2_error(ocfs2_metadata_cache_get_super(ci), "Owner %llu has empty extent list at depth %u\n",
Signature · 1 line
2.39.5
Greg Kroah-Hartman
maintainerPATCH 203/279 NFSv4: Dont trigger uneccessary scans for return-on-close delegations
In reply to Greg Kroah-Hartman5.15-stable review patch. If anyone has any objections, please let me know.
------------------
From: Trond Myklebust <[email protected]>
[ Upstream commit 47acca884f714f41d95dc654f802845544554784 ]
The amount of looping through the list of delegations is occasionally leading to soft lockups. Avoid at least some loops by not requiring the NFSv4 state manager to scan for delegations that are marked for return-on-close. Instead, either mark them for immediate return (if possible) or else leave it up to nfs4_inode_return_delegation_on_close() to return them once the file is closed by the application.
--- fs/nfs/delegation.c | 33 ++++++++++++++++++--------------- 1 file changed, 18 insertions(+), 15 deletions(-)
fs/nfs/delegation.c +18 -15
@@ -570,17 +570,6 @@ static bool nfs_delegation_need_return(struct nfs_delegation *delegation)if (test_and_clear_bit (NFS_DELEGATION_RETURN , &delegation->flags)) ret = true; -else if (test_bit (NFS_DELEGATION_RETURN_IF_CLOSED , &delegation->flags)) { -struct inode *inode; - -spin_lock (&delegation->lock); - inode = delegation->inode; -if (inode &&list_empty (&NFS_I (inode)->open_files)) - ret = true; -spin_unlock (&delegation->lock); - } -if (ret) -clear_bit (NFS_DELEGATION_RETURN_IF_CLOSED , &delegation->flags);if (test_bit (NFS_DELEGATION_RETURNING , &delegation->flags) ||test_bit (NFS_DELEGATION_RETURN_DELAYED , &delegation->flags) ||test_bit (NFS_DELEGATION_REVOKED , &delegation->flags))
@@ -821,11 +810,25 @@ int nfs4_inode_make_writeable(struct inode *inode)return nfs4_inode_return_delegation (inode); } -static void nfs_mark_return_if_closed_delegation (struct nfs_server *server, -struct nfs_delegation *delegation) +static void +nfs_mark_return_if_closed_delegation (struct nfs_server *server, +struct nfs_delegation *delegation) { -set_bit (NFS_DELEGATION_RETURN_IF_CLOSED , &delegation->flags); -set_bit (NFS4CLNT_DELEGRETURN , &server->nfs_client->cl_state); +struct inode *inode; + +if (test_bit (NFS_DELEGATION_RETURN , &delegation->flags) || +test_bit (NFS_DELEGATION_RETURN_IF_CLOSED , &delegation->flags)) +return ; +spin_lock (&delegation->lock); + inode = delegation->inode; +if (!inode) + goto out; +if (list_empty (&NFS_I (inode)->open_files)) +nfs_mark_return_delegation (server, delegation); +else +set_bit (NFS_DELEGATION_RETURN_IF_CLOSED , &delegation->flags); +out: +spin_unlock (&delegation->lock); }static bool nfs_server_mark_return_all_delegations (struct nfs_server *server)
Signature · 1 line
2.39.5
Greg Kroah-Hartman
maintainerPATCH 204/279 fuse: fix dax truncate/punch_hole fault path
In reply to Greg Kroah-Hartman5.15-stable review patch. If anyone has any objections, please let me know.
------------------
From: Alistair Popple <[email protected]>
[ Upstream commit 7851bf649d423edd7286b292739f2eefded3d35c ]
Patch series "fs/dax: Fix ZONE_DEVICE page reference counts", v9.
Device and FS DAX pages have always maintained their own page reference counts without following the normal rules for page reference counting. In particular pages are considered free when the refcount hits one rather than zero and refcounts are not added when mapping the page.
Tracking this requires special PTE bits (PTE_DEVMAP) and a secondary mechanism for allowing GUP to hold references on the page (see get_dev_pagemap). However there doesn't seem to be any reason why FS DAX pages need their own reference counting scheme.
By treating the refcounts on these pages the same way as normal pages we can remove a lot of special checks. In particular pXd_trans_huge() becomes the same as pXd_leaf(), although I haven't made that change here. It also frees up a valuable SW define PTE bit on architectures that have devmap PTE bits defined.
It also almost certainly allows further clean-up of the devmap managed functions, but I have left that as a future improvment. It also enables support for compound ZONE_DEVICE pages which is one of my primary motivators for doing this work.
This patch (of 20):
FS DAX requires file systems to call into the DAX layout prior to unlinking inodes to ensure there is no ongoing DMA or other remote access to the direct mapped page. The fuse file system implements fuse_dax_break_layouts() to do this which includes a comment indicating that passing dmap_end == 0 leads to unmapping of the whole file.
However this is not true - passing dmap_end == 0 will not unmap anything before dmap_start, and further more dax_layout_busy_page_range() will not scan any of the range to see if there maybe ongoing DMA access to the range. Fix this by passing -1 for dmap_end to fuse_dax_break_layouts() which will invalidate the entire file range to dax_layout_busy_page_range().
--- fs/fuse/dax.c | 1 - fs/fuse/dir.c | 2 +- fs/fuse/file.c | 4 ++-- 3 files changed, 3 insertions(+), 4 deletions(-)
fs/fuse/dax.c +0 -1
@@ -681,7 +681,6 @@ static int __fuse_dax_break_layouts(struct inode *inode, bool *retry, 0, 0, fuse_wait_dax_page(inode)); } -/* dmap_end == 0 leads to unmapping of whole file */ int fuse_dax_break_layouts (struct inode *inode,u64 dmap_start,u64 dmap_end) {
fs/fuse/dir.c +1 -1
@@ -1600,7 +1600,7 @@ int fuse_do_setattr(struct dentry *dentry, struct iattr *attr,if (FUSE_IS_DAX (inode) && is_truncate) {filemap_invalidate_lock (mapping); fault_blocked = true; - err =fuse_dax_break_layouts (inode,0 ,0 ); + err =fuse_dax_break_layouts (inode,0 ,-1 );if (err) {filemap_invalidate_unlock (mapping);return err;
fs/fuse/file.c +2 -2
@@ -242,7 +242,7 @@ int fuse_open_common(struct inode *inode, struct file *file, bool isdir)if (dax_truncate) {filemap_invalidate_lock (inode->i_mapping); - err =fuse_dax_break_layouts (inode,0 ,0 ); + err =fuse_dax_break_layouts (inode,0 ,-1 );if (err) goto out_inode_unlock; }
@@ -2962,7 +2962,7 @@ static long fuse_file_fallocate(struct file *file, int mode, loff_t offset,inode_lock (inode);if (block_faults) {filemap_invalidate_lock (inode->i_mapping); - err =fuse_dax_break_layouts (inode,0 ,0 ); + err =fuse_dax_break_layouts (inode,0 ,-1 );if (err) goto out; }
Signature · 1 line
2.39.5
Greg Kroah-Hartman
maintainerPATCH 205/279 i3c: master: svc: Fix missing the IBI rules
In reply to Greg Kroah-Hartman5.15-stable review patch. If anyone has any objections, please let me know.
------------------
From: Stanley Chu <[email protected]>
[ Upstream commit 9cecad134d84d14dc72a0eea7a107691c3e5a837 ]
The code does not add IBI rules for devices with controller capability. However, the secondary controller has the controller capability and works at target mode when the device is probed. Therefore, add IBI rules for such devices.
--- drivers/i3c/master/svc-i3c-master.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/i3c/master/svc-i3c-master.c +1 -1
@@ -807,7 +807,7 @@ static int svc_i3c_update_ibirules(struct svc_i3c_master *master)/* Create the IBIRULES register for both cases */ i3c_bus_for_each_i3cdev (&master->base.bus, dev) { -if (I3C_BCR_DEVICE_ROLE (dev->info.bcr) ==I3C_BCR_I3C_MASTER ) +if (!(dev->info.bcr &I3C_BCR_IBI_REQ_CAP ))continue ;if (dev->info.bcr &I3C_BCR_IBI_PAYLOAD ) {
Signature · 1 line
2.39.5
Greg Kroah-Hartman
maintainerPATCH 206/279 perf python: Fixup description of sample.id event member
In reply to Greg Kroah-Hartman5.15-stable review patch. If anyone has any objections, please let me know.
------------------
From: Arnaldo Carvalho de Melo <[email protected]>
[ Upstream commit 1376c195e8ad327bb9f2d32e0acc5ac39e7cb30a ]
Some old cut'n'paste error, its "ip", so the description should be "event ip", not "event type".
--- tools/perf/util/python.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
tools/perf/util/python.c +1 -1
@@ -158,7 +158,7 @@ struct pyrf_event { };#define sample_members \ - sample_member_def(sample_ip, ip, T_ULONGLONG, "event type"), \ + sample_member_def(sample_ip, ip, T_ULONGLONG, "event ip"), \ sample_member_def(sample_pid, pid, T_INT, "event pid"), \ sample_member_def(sample_tid, tid, T_INT, "event tid"), \ sample_member_def(sample_time, time, T_ULONGLONG, "event timestamp"), \
Signature · 1 line
2.39.5
Greg Kroah-Hartman
maintainerPATCH 207/279 perf python: Decrement the refcount of just created event on failure
In reply to Greg Kroah-Hartman5.15-stable review patch. If anyone has any objections, please let me know.
------------------
From: Arnaldo Carvalho de Melo <[email protected]>
[ Upstream commit 3de5a2bf5b4847f7a59a184568f969f8fe05d57f ]
To avoid a leak if we have the python object but then something happens and we need to return the operation, decrement the offset of the newly created object.
--- tools/perf/util/python.c | 6 +++++- 1 file changed, 5 insertions(+), 1 deletion(-)
tools/perf/util/python.c +5 -1
@@ -1084,6 +1084,7 @@ static PyObject *pyrf_evlist__read_on_cpu(struct pyrf_evlist *pevlist, evsel =evlist__event2evsel (evlist, event);if (!evsel) { +Py_DECREF (pyevent);Py_INCREF (Py_None);return Py_None; }
@@ -1095,9 +1096,12 @@ static PyObject *pyrf_evlist__read_on_cpu(struct pyrf_evlist *pevlist,/* Consume the even only after we parsed it out. */ perf_mmap__consume (&md->core); -if (err) +if (err) { +Py_DECREF (pyevent);return PyErr_Format (PyExc_OSError,"perf: can't parse sample, err=%d" , err); + } +return pyevent; } end:
Signature · 1 line
2.39.5
Greg Kroah-Hartman
maintainerPATCH 208/279 perf python: Dont keep a raw_data pointer to consumed ring buffer space
In reply to Greg Kroah-Hartman5.15-stable review patch. If anyone has any objections, please let me know.
------------------
From: Arnaldo Carvalho de Melo <[email protected]>
[ Upstream commit f3fed3ae34d606819d87a63d970cc3092a5be7ab ]
When processing tracepoints the perf python binding was parsing the event before calling perf_mmap__consume(&md->core) in pyrf_evlist__read_on_cpu().
But part of this event parsing was to set the perf_sample->raw_data pointer to the payload of the event, which then could be overwritten by other event before tracepoint fields were asked for via event.prev_comm in a python program, for instance.
This also happened with other fields, but strings were were problems were surfacing, as there is UTF-8 validation for the potentially garbled data.
This ended up showing up as (with some added debugging messages):
( field 'prev_comm' ret=0x7f7c31f65110, raw_size=68 ) ( field 'prev_pid' ret=0x7f7c23b1bed0, raw_size=68 ) ( field 'prev_prio' ret=0x7f7c239c0030, raw_size=68 ) ( field 'prev_state' ret=0x7f7c239c0250, raw_size=68 ) time 14771421785867 prev_comm= prev_pid=1919907691 prev_prio=796026219 prev_state=0x303a32313175 ==> ( XXX '��' len=16, raw_size=68) ( field 'next_comm' ret=(nil), raw_size=68 ) Traceback (most recent call last):
File "/home/acme/git/perf-tools-next/tools/perf/python/tracepoint.py", line 51, in <module>
main()
File "/home/acme/git/perf-tools-next/tools/perf/python/tracepoint.py", line 46, in main
event.next_comm,
^^^^^^^^^^^^^^^ AttributeError: 'perf.sample_event' object has no attribute 'next_comm'
When event.next_comm was asked for, the PyUnicode_FromString() python API would fail and that tracepoint field wouldn't be available, stopping the tools/perf/python/tracepoint.py test tool.
But, since we already do a copy of the whole event in pyrf_event__new, just use it and while at it remove what was done in in e8968e654191390a ("perf python: Fix pyrf_evlist__read_on_cpu event consuming") because we don't really need to wait for parsing the sample before declaring the event as consumed.
This copy is questionable as is now, as it limits the maximum event + sample_type and tracepoint payload to sizeof(union perf_event), this all has been "working" because 'struct perf_event_mmap2', the largest entry in 'union perf_event' is:
$ pahole -C perf_event ~/bin/perf | grep mmap2 struct perf_record_mmap2 mmap2; /* 0 4168 */ $
--- tools/perf/util/python.c | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-)
tools/perf/util/python.c +1 -3
@@ -1091,11 +1091,9 @@ static PyObject *pyrf_evlist__read_on_cpu(struct pyrf_evlist *pevlist, pevent->evsel = evsel; - err =evsel__parse_sample (evsel, event, &pevent->sample); - -/* Consume the even only after we parsed it out. */ perf_mmap__consume (&md->core); + err =evsel__parse_sample (evsel, &pevent->event, &pevent->sample);if (err) {Py_DECREF (pyevent); return PyErr_Format(PyExc_OSError,
Signature · 1 line
2.39.5
Greg Kroah-Hartman
maintainerPATCH 209/279 perf python: Check if there is space to copy all the event
In reply to Greg Kroah-Hartman5.15-stable review patch. If anyone has any objections, please let me know.
------------------
From: Arnaldo Carvalho de Melo <[email protected]>
[ Upstream commit 89aaeaf84231157288035b366cb6300c1c6cac64 ]
The pyrf_event__new() method copies the event obtained from the perf ring buffer to a structure that will then be turned into a python object for further consumption, so it copies perf_event.header.size bytes to its 'event' member:
$ pahole -C pyrf_event /tmp/build/perf-tools-next/python/perf.cpython-312-x86_64-linux-gnu.so
struct pyrf_event {
PyObject ob_base; /* 0 16 */
struct evsel * evsel; /* 16 8 */
struct perf_sample sample; /* 24 312 *//* XXX last struct has 7 bytes of padding, 2 holes */
/* --- cacheline 5 boundary (320 bytes) was 16 bytes ago --- */
union perf_event event; /* 336 4168 */
/* size: 4504, cachelines: 71, members: 4 */ /* member types with holes: 1, total: 2 */ /* paddings: 1, sum paddings: 7 */ /* last cacheline: 24 bytes */ };
$
It was doing so without checking if the event just obtained has more than that space, fix it.
This isn't a proper, final solution, as we need to support larger events, but for the time being we at least bounds check and document it.
--- tools/perf/util/python.c | 5 +++++ 1 file changed, 5 insertions(+)
tools/perf/util/python.c +5 -0
@@ -585,6 +585,11 @@ static PyObject *pyrf_event__new(union perf_event *event) event->header.type == PERF_RECORD_SWITCH_CPU_WIDE))return NULL ; +// FIXME this better be dynamic or we need to parse everything +// before calling perf_mmap__consume(), including tracepoint fields. +if (sizeof (pevent->event) < event->header.size) +return NULL ; + ptype = pyrf_event__type[event->header.type]; pevent = PyObject_New(struct pyrf_event, ptype);if (pevent !=NULL )
Signature · 1 line
2.39.5
Greg Kroah-Hartman
maintainerPATCH 210/279 fs/procfs: fix the comment above proc_pid_wchan()
In reply to Greg Kroah-Hartman5.15-stable review patch. If anyone has any objections, please let me know.
------------------
From: Bart Van Assche <[email protected]>
[ Upstream commit 6287fbad1cd91f0c25cdc3a580499060828a8f30 ]
proc_pid_wchan() used to report kernel addresses to user space but that is no longer the case today. Bring the comment above proc_pid_wchan() in sync with the implementation.
--- fs/proc/base.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
fs/proc/base.c +1 -1
@@ -416,7 +416,7 @@ static const struct file_operations proc_pid_cmdline_ops = {#ifdef CONFIG_KALLSYMS /* * Provides a wchan file via kallsyms in a proper one-value-per-file format. -* Returns the resolved symbol. If that fails, simply return the address. +* Returns the resolved symbol to user space. */ static int proc_pid_wchan (struct seq_file *m,struct pid_namespace *ns,struct pid *pid,struct task_struct *task)
Signature · 1 line
2.39.5
Greg Kroah-Hartman
maintainerPATCH 211/279 objtool, media: dib8000: Prevent divide-by-zero in dib8000_set_dds()
In reply to Greg Kroah-Hartman5.15-stable review patch. If anyone has any objections, please let me know.
------------------
From: Josh Poimboeuf <[email protected]>
[ Upstream commit e63d465f59011dede0a0f1d21718b59a64c3ff5c ]
If dib8000_set_dds()'s call to dib8000_read32() returns zero, the result is a divide-by-zero. Prevent that from happening.
Fixes the following warning with an UBSAN kernel:
drivers/media/dvb-frontends/dib8000.o: warning: objtool: dib8000_tune() falls through to next function dib8096p_cfg_DibRx()
--- drivers/media/dvb-frontends/dib8000.c | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-)
drivers/media/dvb-frontends/dib8000.c +4 -1
@@ -2701,8 +2701,11 @@ static void dib8000_set_dds(struct dib8000_state *state, s32 offset_khz)u8 ratio;if (state->revision ==0x8090 ) { +u32 internal =dib8000_read32 (state,23 ) /1000 ; + ratio =4 ; - unit_khz_dds_val = (1 <<26 ) / (dib8000_read32 (state,23 ) /1000 ); + + unit_khz_dds_val = (1 <<26 ) / (internal ?:1 );if (offset_khz <0 ) dds = (1 <<26 ) - (abs_offset_khz * unit_khz_dds_val);else
Signature · 1 line
2.39.5
Greg Kroah-Hartman
maintainerPATCH 212/279 exfat: fix the infinite loop in exfat_find_last_cluster()
In reply to Greg Kroah-Hartman5.15-stable review patch. If anyone has any objections, please let me know.
------------------
From: Yuezhang Mo <[email protected]>
[ Upstream commit b0522303f67255926b946aa66885a0104d1b2980 ]
In exfat_find_last_cluster(), the cluster chain is traversed until the EOF cluster. If the cluster chain includes a loop due to file system corruption, the EOF cluster cannot be traversed, resulting in an infinite loop.
If the number of clusters indicated by the file size is inconsistent with the cluster chain length, exfat_find_last_cluster() will return an error, so if this inconsistency is found, the traversal can be aborted without traversing to the EOF cluster.
--- fs/exfat/fatent.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
fs/exfat/fatent.c +1 -1
@@ -264,7 +264,7 @@ int exfat_find_last_cluster(struct super_block *sb, struct exfat_chain *p_chain, clu = next;if (exfat_ent_get (sb, clu, &next))return -EIO ; - }while (next !=EXFAT_EOF_CLUSTER ); + }while (next !=EXFAT_EOF_CLUSTER && count <= p_chain->size);if (p_chain->size != count) { exfat_fs_error(sb,
Signature · 1 line
2.39.5
Greg Kroah-Hartman
maintainerPATCH 213/279 rtnetlink: Allocate vfinfo size for VF GUIDs when supported
In reply to Greg Kroah-Hartman5.15-stable review patch. If anyone has any objections, please let me know.
------------------
From: Mark Zhang <[email protected]>
[ Upstream commit 23f00807619d15063d676218f36c5dfeda1eb420 ]
Commit 30aad41721e0 ("net/core: Add support for getting VF GUIDs") added support for getting VF port and node GUIDs in netlink ifinfo messages, but their size was not taken into consideration in the function that allocates the netlink message, causing the following warning when a netlink message is filled with many VF port and node GUIDs:
# echo 64 > /sys/bus/pci/devices/0000\:08\:00.0/sriov_numvfs # ip link show dev ib0 RTNETLINK answers: Message too long Cannot send link get request: Message too long
Kernel warning:
------------[ cut here ]------------ WARNING: CPU: 2 PID: 1930 at net/core/rtnetlink.c:4151 rtnl_getlink+0x586/0x5a0 Modules linked in: xt_conntrack xt_MASQUERADE nfnetlink xt_addrtype iptable_nat nf_nat br_netfilter overlay mlx5_ib macsec mlx5_core tls rpcrdma rdma_ucm ib_uverbs ib_iser libiscsi scsi_transport_iscsi ib_umad rdma_cm iw_cm ib_ipoib fuse ib_cm ib_core CPU: 2 UID: 0 PID: 1930 Comm: ip Not tainted 6.14.0-rc2+ #1 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014 RIP: 0010:rtnl_getlink+0x586/0x5a0 Code: cb 82 e8 3d af 0a 00 4d 85 ff 0f 84 08 ff ff ff 4c 89 ff 41 be ea ff ff ff e8 66 63 5b ff 49 c7 07 80 4f cb 82 e9 36 fc ff ff <0f> 0b e9 16 fe ff ff e8 de a0 56 00 66 66 2e 0f 1f 84 00 00 00 00 RSP: 0018:ffff888113557348 EFLAGS: 00010246 RAX: 00000000ffffffa6 RBX: ffff88817e87aa34 RCX: dffffc0000000000 RDX: 0000000000000003 RSI: 0000000000000000 RDI: ffff88817e87afb8 RBP: 0000000000000009 R08: ffffffff821f44aa R09: 0000000000000000 R10: ffff8881260f79a8 R11: ffff88817e87af00 R12: ffff88817e87aa00 R13: ffffffff8563d300 R14: 00000000ffffffa6 R15: 00000000ffffffff FS: 00007f63a5dbf280(0000) GS:ffff88881ee00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f63a5ba4493 CR3: 00000001700fe002 CR4: 0000000000772eb0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 PKRU: 55555554 Call Trace: <TASK> ? __warn+0xa5/0x230 ? rtnl_getlink+0x586/0x5a0 ? report_bug+0x22d/0x240 ? handle_bug+0x53/0xa0 ? exc_invalid_op+0x14/0x50 ? asm_exc_invalid_op+0x16/0x20 ? skb_trim+0x6a/0x80 ? rtnl_getlink+0x586/0x5a0 ? __pfx_rtnl_getlink+0x10/0x10 ? rtnetlink_rcv_msg+0x1e5/0x860 ? __pfx___mutex_lock+0x10/0x10 ? rcu_is_watching+0x34/0x60 ? __pfx_lock_acquire+0x10/0x10 ? stack_trace_save+0x90/0xd0 ? filter_irq_stacks+0x1d/0x70 ? kasan_save_stack+0x30/0x40 ? kasan_save_stack+0x20/0x40 ? kasan_save_track+0x10/0x30 rtnetlink_rcv_msg+0x21c/0x860 ? entry_SYSCALL_64_after_hwframe+0x76/0x7e ? __pfx_rtnetlink_rcv_msg+0x10/0x10 ? arch_stack_walk+0x9e/0xf0 ? rcu_is_watching+0x34/0x60 ? lock_acquire+0xd5/0x410 ? rcu_is_watching+0x34/0x60 netlink_rcv_skb+0xe0/0x210 ? __pfx_rtnetlink_rcv_msg+0x10/0x10 ? __pfx_netlink_rcv_skb+0x10/0x10 ? rcu_is_watching+0x34/0x60 ? __pfx___netlink_lookup+0x10/0x10 ? lock_release+0x62/0x200 ? netlink_deliver_tap+0xfd/0x290 ? rcu_is_watching+0x34/0x60 ? lock_release+0x62/0x200 ? netlink_deliver_tap+0x95/0x290 netlink_unicast+0x31f/0x480 ? __pfx_netlink_unicast+0x10/0x10 ? rcu_is_watching+0x34/0x60 ? lock_acquire+0xd5/0x410 netlink_sendmsg+0x369/0x660 ? lock_release+0x62/0x200 ? __pfx_netlink_sendmsg+0x10/0x10 ? import_ubuf+0xb9/0xf0 ? __import_iovec+0x254/0x2b0 ? lock_release+0x62/0x200 ? __pfx_netlink_sendmsg+0x10/0x10 ____sys_sendmsg+0x559/0x5a0 ? __pfx_____sys_sendmsg+0x10/0x10 ? __pfx_copy_msghdr_from_user+0x10/0x10 ? rcu_is_watching+0x34/0x60 ? do_read_fault+0x213/0x4a0 ? rcu_is_watching+0x34/0x60 ___sys_sendmsg+0xe4/0x150 ? __pfx____sys_sendmsg+0x10/0x10 ? do_fault+0x2cc/0x6f0 ? handle_pte_fault+0x2e3/0x3d0 ? __pfx_handle_pte_fault+0x10/0x10 ? preempt_count_sub+0x14/0xc0 ? __down_read_trylock+0x150/0x270 ? __handle_mm_fault+0x404/0x8e0 ? __pfx___handle_mm_fault+0x10/0x10 ? lock_release+0x62/0x200 ? __rcu_read_unlock+0x65/0x90 ? rcu_is_watching+0x34/0x60 __sys_sendmsg+0xd5/0x150 ? __pfx___sys_sendmsg+0x10/0x10 ? __up_read+0x192/0x480 ? lock_release+0x62/0x200 ? __rcu_read_unlock+0x65/0x90 ? rcu_is_watching+0x34/0x60 do_syscall_64+0x6d/0x140 entry_SYSCALL_64_after_hwframe+0x76/0x7e RIP: 0033:0x7f63a5b13367 Code: 0e 00 f7 d8 64 89 02 48 c7 c0 ff ff ff ff eb b9 0f 1f 00 f3 0f 1e fa 64 8b 04 25 18 00 00 00 85 c0 75 10 b8 2e 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 51 c3 48 83 ec 28 89 54 24 1c 48 89 74 24 10 RSP: 002b:00007fff8c726bc8 EFLAGS: 00000246 ORIG_RAX: 000000000000002e RAX: ffffffffffffffda RBX: 0000000067b687c2 RCX: 00007f63a5b13367 RDX: 0000000000000000 RSI: 00007fff8c726c30 RDI: 0000000000000004 RBP: 00007fff8c726cb8 R08: 0000000000000000 R09: 0000000000000034 R10: 00007fff8c726c7c R11: 0000000000000246 R12: 0000000000000001 R13: 0000000000000000 R14: 00007fff8c726cd0 R15: 00007fff8c726cd0 </TASK> irq event stamp: 0 hardirqs last enabled at (0): [<0000000000000000>] 0x0 hardirqs last disabled at (0): [<ffffffff813f9e58>] copy_process+0xd08/0x2830 softirqs last enabled at (0): [<ffffffff813f9e58>] copy_process+0xd08/0x2830 softirqs last disabled at (0): [<0000000000000000>] 0x0 ---[ end trace 0000000000000000 ]---
Thus, when calculating ifinfo message size, take VF GUIDs sizes into account when supported.
--- net/core/rtnetlink.c | 3 +++ 1 file changed, 3 insertions(+)
net/core/rtnetlink.c +3 -0
@@ -972,6 +972,9 @@ static inline int rtnl_vfinfo_size(const struct net_device *dev,/* IFLA_VF_STATS_TX_DROPPED */ nla_total_size_64bit(sizeof(__u64))); } +if (dev->netdev_ops->ndo_get_vf_guid) + size += num_vfs *2 * +nla_total_size (sizeof (struct ifla_vf_guid ));return size; }else return 0 ;
Signature · 1 line
2.39.5
Greg Kroah-Hartman
maintainerPATCH 214/279 ksmbd: use aead_request_free to match aead_request_alloc
In reply to Greg Kroah-Hartman5.15-stable review patch. If anyone has any objections, please let me know.
------------------
From: Miaoqian Lin <[email protected]>
[ Upstream commit 6171063e9d046ffa46f51579b2ca4a43caef581a ]
Use aead_request_free() instead of kfree() to properly free memory allocated by aead_request_alloc(). This ensures sensitive crypto data is zeroed before being freed.
--- fs/ksmbd/auth.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
fs/ksmbd/auth.c +1 -1
@@ -1211,7 +1211,7 @@ int ksmbd_crypt_message(struct ksmbd_work *work, struct kvec *iov, free_sg:kfree (sg); free_req: -kfree (req); +aead_request_free (req); free_ctx:ksmbd_release_crypto_ctx (ctx);return rc;
Signature · 1 line
2.39.5
Greg Kroah-Hartman
maintainerPATCH 215/279 ksmbd: fix multichannel connection failure
In reply to Greg Kroah-Hartman5.15-stable review patch. If anyone has any objections, please let me know.
------------------
From: Namjae Jeon <[email protected]>
[ Upstream commit c1883049aa9b2b7dffd3a68c5fc67fa92c174bd9 ]
ksmbd check that the session of second channel is in the session list of first connection. If it is in session list, multichannel connection should not be allowed.
--- fs/ksmbd/mgmt/user_session.c | 16 ++++++++++++++++ fs/ksmbd/mgmt/user_session.h | 2 ++ fs/ksmbd/smb2pdu.c | 12 ++++-------- 3 files changed, 22 insertions(+), 8 deletions(-)
fs/ksmbd/mgmt/user_session.c +16 -0
@@ -250,6 +250,22 @@ void ksmbd_sessions_deregister(struct ksmbd_conn *conn)up_write (&conn->session_lock); } +bool is_ksmbd_session_in_connection (struct ksmbd_conn *conn, +unsigned long long id) +{ +struct ksmbd_session *sess; + +down_read (&conn->session_lock); + sess =xa_load (&conn->sessions, id); +if (sess) { +up_read (&conn->session_lock); +return true; + } +up_read (&conn->session_lock); + +return false; +} +struct ksmbd_session *ksmbd_session_lookup (struct ksmbd_conn *conn,unsigned long long id) {
fs/ksmbd/mgmt/user_session.h +2 -0
@@ -87,6 +87,8 @@ void ksmbd_session_destroy(struct ksmbd_session *sess);struct ksmbd_session *ksmbd_session_lookup_slowpath (unsigned long long id);struct ksmbd_session *ksmbd_session_lookup (struct ksmbd_conn *conn,unsigned long long id); +bool is_ksmbd_session_in_connection (struct ksmbd_conn *conn, +unsigned long long id);int ksmbd_session_register (struct ksmbd_conn *conn,struct ksmbd_session *sess);void ksmbd_sessions_deregister (struct ksmbd_conn *conn);
fs/ksmbd/smb2pdu.c +4 -8
@@ -1725,44 +1725,38 @@ int smb2_sess_setup(struct ksmbd_work *work)if (conn->dialect != sess->dialect) { rc = -EINVAL ; -ksmbd_user_session_put (sess); goto out_err; }if (!(req->hdr.Flags &SMB2_FLAGS_SIGNED )) { rc = -EINVAL ; -ksmbd_user_session_put (sess); goto out_err; }if (strncmp (conn->ClientGUID, sess->ClientGUID,SMB2_CLIENT_GUID_SIZE )) { rc = -ENOENT ; -ksmbd_user_session_put (sess); goto out_err; }if (sess->state ==SMB2_SESSION_IN_PROGRESS ) { rc = -EACCES ; -ksmbd_user_session_put (sess); goto out_err; }if (sess->state ==SMB2_SESSION_EXPIRED ) { rc = -EFAULT ; -ksmbd_user_session_put (sess); goto out_err; } -ksmbd_user_session_put (sess);if (ksmbd_conn_need_reconnect (conn)) { rc = -EFAULT ; +ksmbd_user_session_put (sess); sess =NULL ; goto out_err; } - sess =ksmbd_session_lookup (conn, sess_id); -if (!sess) { +if (is_ksmbd_session_in_connection (conn, sess_id)) { rc = -EACCES ; goto out_err; }
@@ -1928,6 +1922,8 @@ int smb2_sess_setup(struct ksmbd_work *work) sess->last_active = jiffies; sess->state =SMB2_SESSION_EXPIRED ; +ksmbd_user_session_put (sess); + work->sess =NULL ;if (try_delay) {ksmbd_conn_set_need_reconnect (conn);ssleep (5 );
Signature · 1 line
2.39.5
Greg Kroah-Hartman
maintainerPATCH 216/279 ring-buffer: Fix bytes_dropped calculation issue
In reply to Greg Kroah-Hartman5.15-stable review patch. If anyone has any objections, please let me know.
------------------
From: Feng Yang <[email protected]>
[ Upstream commit c73f0b69648501978e8b3e8fa7eef7f4197d0481 ]
The calculation of bytes-dropped and bytes_dropped_nested is reversed. Although it does not affect the final calculation of total_dropped, it should still be modified.
--- kernel/trace/ring_buffer.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
kernel/trace/ring_buffer.c +2 -2
@@ -5949,9 +5949,9 @@ static __init int rb_write_something(struct rb_test_data *data, bool nested)/* Ignore dropped events before test starts. */ if (started) {if (nested) - data->bytes_dropped += len; -else data->bytes_dropped_nested += len; +else + data->bytes_dropped += len; }return len; }
Signature · 1 line
2.39.5
Greg Kroah-Hartman
maintainerPATCH 217/279 ACPI: processor: idle: Return an error if both P_LVL{2,3} idle states are invalid
In reply to Greg Kroah-Hartman5.15-stable review patch. If anyone has any objections, please let me know.
------------------
From: Giovanni Gherdovich <[email protected]>
[ Upstream commit 9e9b893404d43894d69a18dd2fc8fcf1c36abb7e ]
Prior to commit 496121c02127 ("ACPI: processor: idle: Allow probing on platforms with one ACPI C-state"), the acpi_idle driver wouldn't load on systems without a valid C-State at least as deep as C2.
The behavior was desirable for guests on hypervisors such as VMWare ESXi, which by default don't have the _CST ACPI method, and set the C2 and C3 latencies to 101 and 1001 microseconds respectively via the FADT, to signify they're unsupported.
Since the above change though, these virtualized deployments end up loading acpi_idle, and thus entering the default C1 C-State set by acpi_processor_get_power_info_default(); this is undesirable for a system that's communicating to the OS it doesn't want C-States (missing _CST, and invalid C2/C3 in FADT).
Make acpi_processor_get_power_info_fadt() return -ENODEV in that case, so that acpi_processor_get_cstate_info() exits early and doesn't set pr->flags.power = 1.
--- drivers/acpi/processor_idle.c | 4 ++++ 1 file changed, 4 insertions(+)
drivers/acpi/processor_idle.c +4 -0
@@ -265,6 +265,10 @@ static int acpi_processor_get_power_info_fadt(struct acpi_processor *pr)ACPI_CX_DESC_LEN ,"ACPI P_LVL3 IOPORT 0x%x" , pr->power.states[ACPI_STATE_C3].address); +if (!pr->power.states[ACPI_STATE_C2 ].address && + !pr->power.states[ACPI_STATE_C3 ].address) +return -ENODEV ; +return 0 ; }
Signature · 1 line
2.39.5
Greg Kroah-Hartman
maintainerPATCH 218/279 octeontx2-af: Fix mbox INTR handler when num VFs > 64
In reply to Greg Kroah-Hartman5.15-stable review patch. If anyone has any objections, please let me know.
------------------
From: Geetha sowjanya <[email protected]>
[ Upstream commit 0fdba88a211508984eb5df62008c29688692b134 ]
When number of RVU VFs > 64, the vfs value passed to "rvu_queue_work" function is incorrect. Due to which mbox workqueue entries for VFs 0 to 63 never gets added to workqueue.
--- drivers/net/ethernet/marvell/octeontx2/af/rvu.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/net/ethernet/marvell/octeontx2/af/rvu.c +1 -1
@@ -2469,7 +2469,7 @@ static irqreturn_t rvu_mbox_intr_handler(int irq, void *rvu_irq)rvupf_write64 (rvu,RVU_PF_VFPF_MBOX_INTX (1 ), intr);rvu_queue_work (&rvu->afvf_wq_info,64 , vfs, intr); - vfs -=64 ; + vfs =64 ; } intr =rvupf_read64 (rvu,RVU_PF_VFPF_MBOX_INTX (0 ));
Signature · 1 line
2.39.5
Greg Kroah-Hartman
maintainerPATCH 219/279 octeontx2-af: Free NIX_AF_INT_VEC_GEN irq
In reply to Greg Kroah-Hartman5.15-stable review patch. If anyone has any objections, please let me know.
------------------
From: Geetha sowjanya <[email protected]>
[ Upstream commit 323d6db6dc7decb06f2545efb9496259ddacd4f4 ]
Due to the incorrect initial vector number in rvu_nix_unregister_interrupts(), NIX_AF_INT_VEC_GEN is not geeting free. Fix the vector number to include NIX_AF_INT_VEC_GEN irq.
--- drivers/net/ethernet/marvell/octeontx2/af/rvu_devlink.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/net/ethernet/marvell/octeontx2/af/rvu_devlink.c +1 -1
@@ -216,7 +216,7 @@ static void rvu_nix_unregister_interrupts(struct rvu *rvu) rvu->irq_allocated[offs +NIX_AF_INT_VEC_RVU ] = false; } -for (i =NIX_AF_INT_VEC_AF_ERR ; i <NIX_AF_INT_VEC_CNT ; i++) +for (i =NIX_AF_INT_VEC_GEN ; i <NIX_AF_INT_VEC_CNT ; i++)if (rvu->irq_allocated[offs + i]) {free_irq (pci_irq_vector (rvu->pdev, offs + i), rvu_dl); rvu->irq_allocated[offs + i] = false;
Signature · 1 line
2.39.5
Greg Kroah-Hartman
maintainerPATCH 220/279 sched/smt: Always inline sched_smt_active()
In reply to Greg Kroah-Hartman5.15-stable review patch. If anyone has any objections, please let me know.
------------------
From: Josh Poimboeuf <[email protected]>
[ Upstream commit 09f37f2d7b21ff35b8b533f9ab8cfad2fe8f72f6 ]
sched_smt_active() can be called from noinstr code, so it should always be inlined. The CONFIG_SCHED_SMT version already has __always_inline. Do the same for its !CONFIG_SCHED_SMT counterpart.
Fixes the following warning:
vmlinux.o: error: objtool: intel_idle_ibrs+0x13: call to sched_smt_active() leaves .noinstr.text section
--- include/linux/sched/smt.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
include/linux/sched/smt.h +1 -1
@@ -12,7 +12,7 @@ static __always_inline bool sched_smt_active(void)return static_branch_likely (&sched_smt_present); }#else -static inline bool sched_smt_active (void ) {return false; } +static __always_inline bool sched_smt_active(void) { return false; }#endif void arch_smt_update (void );
Signature · 1 line
2.39.5
Greg Kroah-Hartman
maintainerPATCH 221/279 wifi: iwlwifi: fw: allocate chained SG tables for dump
In reply to Greg Kroah-Hartman5.15-stable review patch. If anyone has any objections, please let me know.
------------------
From: Johannes Berg <[email protected]>
[ Upstream commit 7774e3920029398ad49dc848b23840593f14d515 ]
The firmware dumps can be pretty big, and since we use single pages for each SG table entry, even the table itself may end up being an order-5 allocation. Build chained tables so that we need not allocate a higher-order table here.
This could be improved and cleaned up, e.g. by using the SG pool code or simply kvmalloc(), but all of that would require also updating the devcoredump first since that frees it all, so we need to be more careful. SG pool might also run against the CONFIG_ARCH_NO_SG_CHAIN limitation, which is irrelevant here.
Also use _devcd_free_sgtable() for the error paths now, much simpler especially since it's in two places now.
--- drivers/net/wireless/intel/iwlwifi/fw/dbg.c | 86 ++++++++++++++------- 1 file changed, 58 insertions(+), 28 deletions(-)
drivers/net/wireless/intel/iwlwifi/fw/dbg.c +58 -28
@@ -558,41 +558,71 @@ static void iwl_dump_prph(struct iwl_fw_runtime *fwrt, }/* -* alloc_sgtable - allocates scallerlist table in the given size, -* fills it with pages and returns it +* alloc_sgtable - allocates (chained) scatterlist in the given size, +* fills it with pages and returns it * @size: the size (in bytes) of the table -*/ -static struct scatterlist *alloc_sgtable (int size) +*/ +static struct scatterlist *alloc_sgtable (ssize_t size) { -int alloc_size, nents, i; -struct page *new_page; -struct scatterlist *iter; -struct scatterlist *table; +struct scatterlist *result =NULL , *prev; +int nents, i, n_prev; nents =DIV_ROUND_UP (size,PAGE_SIZE ); - table =kcalloc (nents,sizeof (*table),GFP_KERNEL ); -if (!table) -return NULL ; -sg_init_table (table, nents); - iter = table; -for_each_sg (table, iter,sg_nents (table), i) { - new_page =alloc_page (GFP_KERNEL ); -if (!new_page) { -/* release all previous allocated pages in the table */ - iter = table; -for_each_sg (table, iter,sg_nents (table), i) { - new_page =sg_page (iter); -if (new_page) -__free_page (new_page); - } -kfree (table); + +#define N_ENTRIES_PER_PAGE (PAGE_SIZE / sizeof(*result)) +/* +* We need an additional entry for table chaining, +* this ensures the loop can finish i.e. we can +* fit at least two entries per page (obviously, +* many more really fit.) +*/ +BUILD_BUG_ON (N_ENTRIES_PER_PAGE <2 ); + +while (nents >0 ) { +struct scatterlist *new, *iter; +int n_fill, n_alloc; + +if (nents <=N_ENTRIES_PER_PAGE ) { +/* last needed table */ + n_fill = nents; + n_alloc = nents; + nents =0 ; + }else { +/* fill a page with entries */ + n_alloc =N_ENTRIES_PER_PAGE ; +/* reserve one for chaining */ + n_fill = n_alloc -1 ; + nents -= n_fill; + } + + new =kcalloc (n_alloc,sizeof (*new),GFP_KERNEL ); +if (!new) { +if (result) +_devcd_free_sgtable (result);return NULL ; } - alloc_size =min_t (int, size,PAGE_SIZE ); - size -=PAGE_SIZE ; -sg_set_page (iter, new_page, alloc_size,0 ); +sg_init_table (new, n_alloc); + +if (!result) + result = new; +else +sg_chain (prev, n_prev, new); + prev = new; + n_prev = n_alloc; + +for_each_sg (new, iter, n_fill, i) { +struct page *new_page =alloc_page (GFP_KERNEL ); + +if (!new_page) { +_devcd_free_sgtable (result); +return NULL ; + } + +sg_set_page (iter, new_page,PAGE_SIZE ,0 ); + } } -return table; + +return result; } static void iwl_fw_get_prph_len(struct iwl_fw_runtime *fwrt,
Signature · 1 line
2.39.5
Greg Kroah-Hartman
maintainerPATCH 222/279 nvme-tcp: fix possible UAF in nvme_tcp_poll
In reply to Greg Kroah-Hartman5.15-stable review patch. If anyone has any objections, please let me know.
------------------
From: Sagi Grimberg <[email protected]>
[ Upstream commit 8c1624b63a7d24142a2bbc3a5ee7e95f004ea36e ]
nvme_tcp_poll() may race with the send path error handler because it may complete the request while it is actively being polled for completion, resulting in a UAF panic [1]:
We should make sure to stop polling when we see an error when trying to read from the socket. Hence make sure to propagate the error so that the block layer breaks the polling cycle.
[1]:
--
[35665.692310] nvme nvme2: failed to send request -13 [35665.702265] nvme nvme2: unsupported pdu type (3) [35665.702272] BUG: kernel NULL pointer dereference, address: 0000000000000000 [35665.702542] nvme nvme2: queue 1 receive failed: -22 [35665.703209] #PF: supervisor write access in kernel mode [35665.703213] #PF: error_code(0x0002) - not-present page [35665.703214] PGD 8000003801cce067 P4D 8000003801cce067 PUD 37e6f79067 PMD 0 [35665.703220] Oops: 0002 [#1] SMP PTI [35665.703658] nvme nvme2: starting error recovery [35665.705809] Hardware name: Inspur aaabbb/YZMB-00882-104, BIOS 4.1.26 09/22/2022 [35665.705812] Workqueue: kblockd blk_mq_requeue_work [35665.709172] RIP: 0010:_raw_spin_lock+0xc/0x30 [35665.715788] Call Trace: [35665.716201] <TASK> [35665.716613] ? show_trace_log_lvl+0x1c1/0x2d9 [35665.717049] ? show_trace_log_lvl+0x1c1/0x2d9 [35665.717457] ? blk_mq_request_bypass_insert+0x2c/0xb0 [35665.717950] ? __die_body.cold+0x8/0xd [35665.718361] ? page_fault_oops+0xac/0x140 [35665.718749] ? blk_mq_start_request+0x30/0xf0 [35665.719144] ? nvme_tcp_queue_rq+0xc7/0x170 [nvme_tcp] [35665.719547] ? exc_page_fault+0x62/0x130 [35665.719938] ? asm_exc_page_fault+0x22/0x30 [35665.720333] ? _raw_spin_lock+0xc/0x30 [35665.720723] blk_mq_request_bypass_insert+0x2c/0xb0 [35665.721101] blk_mq_requeue_work+0xa5/0x180 [35665.721451] process_one_work+0x1e8/0x390 [35665.721809] worker_thread+0x53/0x3d0 [35665.722159] ? process_one_work+0x390/0x390 [35665.722501] kthread+0x124/0x150 [35665.722849] ? set_kthread_struct+0x50/0x50 [35665.723182] ret_from_fork+0x1f/0x30
--- drivers/nvme/host/tcp.c | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-)
drivers/nvme/host/tcp.c +3 -2
@@ -2491,6 +2491,7 @@ static int nvme_tcp_poll(struct blk_mq_hw_ctx *hctx) {struct nvme_tcp_queue *queue = hctx->driver_data;struct sock *sk = queue->sock->sk; +int ret;if (!test_bit (NVME_TCP_Q_LIVE , &queue->flags))return 0 ;
@@ -2498,9 +2499,9 @@ static int nvme_tcp_poll(struct blk_mq_hw_ctx *hctx)set_bit (NVME_TCP_Q_POLLING , &queue->flags);if (sk_can_busy_loop (sk) &&skb_queue_empty_lockless (&sk->sk_receive_queue))sk_busy_loop (sk, true); -nvme_tcp_try_recv (queue); + ret =nvme_tcp_try_recv (queue);clear_bit (NVME_TCP_Q_POLLING , &queue->flags); -return queue->nr_cqe; +return ret <0 ? ret : queue->nr_cqe; }static const struct blk_mq_ops nvme_tcp_mq_ops = {
Signature · 1 line
2.39.5
Greg Kroah-Hartman
maintainerPATCH 223/279 nvme-pci: clean up CMBMSC when registering CMB fails
In reply to Greg Kroah-Hartman5.15-stable review patch. If anyone has any objections, please let me know.
------------------
From: Icenowy Zheng <[email protected]>
[ Upstream commit 6a3572e10f740acd48e2713ef37e92186a3ce5e8 ]
CMB decoding should get disabled when the CMB block isn't successfully registered to P2P DMA subsystem.
Clean up the CMBMSC register in this error handling codepath to disable CMB decoding (and CMBLOC/CMBSZ registers).
--- drivers/nvme/host/pci.c | 1 + 1 file changed, 1 insertion(+)
drivers/nvme/host/pci.c +1 -0
@@ -1870,6 +1870,7 @@ static void nvme_map_cmb(struct nvme_dev *dev)if (pci_p2pdma_add_resource (pdev, bar, size, offset)) {dev_warn (dev->ctrl.device,"failed to register the CMB\n" ); +hi_lo_writeq (0 , dev->bar +NVME_REG_CMBMSC );return ; }
Signature · 1 line
2.39.5
Greg Kroah-Hartman
maintainerPATCH 224/279 nvme-pci: skip CMB blocks incompatible with PCI P2P DMA
In reply to Greg Kroah-Hartman5.15-stable review patch. If anyone has any objections, please let me know.
------------------
From: Icenowy Zheng <[email protected]>
[ Upstream commit 56cf7ef0d490b28fad8f8629fc135c5ab7c9f54e ]
The PCI P2PDMA code will register the CMB block to the memory hot-plugging subsystem, which have an alignment requirement. Memory blocks that do not satisfy this alignment requirement (usually 2MB) will lead to a WARNING from memory hotplugging.
Verify the CMB block's address and size against the alignment and only try to send CMB blocks compatible with it to prevent this warning.
Tested on Intel DC D4502 SSD, which has a 512K CMB block that is too small for memory hotplugging (thus PCI P2PDMA).
--- drivers/nvme/host/pci.c | 20 ++++++++++++-------- 1 file changed, 12 insertions(+), 8 deletions(-)
drivers/nvme/host/pci.c +12 -8
@@ -1849,6 +1849,18 @@ static void nvme_map_cmb(struct nvme_dev *dev)if (offset > bar_size)return ; +/* +* Controllers may support a CMB size larger than their BAR, for +* example, due to being behind a bridge. Reduce the CMB to the +* reported size of the BAR +*/ + size =min (size, bar_size - offset); + +if (!IS_ALIGNED (size,memremap_compat_align ()) || + !IS_ALIGNED (pci_resource_start (pdev, bar), +memremap_compat_align ())) +return ; +/* * Tell the controller about the host side address mapping the CMB, * and enable CMB decoding for the NVMe 1.4+ scheme:
@@ -1859,14 +1871,6 @@ static void nvme_map_cmb(struct nvme_dev *dev) dev->bar + NVME_REG_CMBMSC); } -/* -* Controllers may support a CMB size larger than their BAR, -* for example, due to being behind a bridge. Reduce the CMB to -* the reported size of the BAR -*/ -if (size > bar_size - offset) - size = bar_size - offset; -if (pci_p2pdma_add_resource (pdev, bar, size, offset)) {dev_warn (dev->ctrl.device,"failed to register the CMB\n" );
Signature · 1 line
2.39.5
Greg Kroah-Hartman
maintainerPATCH 225/279 affs: generate OFS sequence numbers starting at 1
In reply to Greg Kroah-Hartman5.15-stable review patch. If anyone has any objections, please let me know.
------------------
From: Simon Tatham <[email protected]>
[ Upstream commit e4cf8ec4de4e13f156c1d61977d282d90c221085 ]
If I write a file to an OFS floppy image, and try to read it back on an emulated Amiga running Workbench 1.3, the Amiga reports a disk error trying to read the file. (That is, it's unable to read it _at all_, even to copy it to the NIL: device. It isn't a matter of getting the wrong data and being unable to parse the file format.)
This is because the 'sequence number' field in the OFS data block header is supposed to be based at 1, but affs writes it based at 0. All three locations changed by this patch were setting the sequence number to a variable 'bidx' which was previously obtained by dividing a file position by bsize, so bidx will naturally use 0 for the first block. Therefore all three should add 1 to that value before writing it into the sequence number field.
With this change, the Amiga successfully reads the file.
For data block reference: https://wiki.osdev.org/FFS_(Amiga)
--- fs/affs/file.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-)
fs/affs/file.c +3 -3
@@ -598,7 +598,7 @@ affs_extent_file_ofs(struct inode *inode, u32 newsize)BUG_ON (tmp > bsize);AFFS_DATA_HEAD (bh)->ptype =cpu_to_be32 (T_DATA );AFFS_DATA_HEAD (bh)->key =cpu_to_be32 (inode->i_ino); -AFFS_DATA_HEAD (bh)->sequence =cpu_to_be32 (bidx); +AFFS_DATA_HEAD (bh)->sequence =cpu_to_be32 (bidx +1 );AFFS_DATA_HEAD (bh)->size =cpu_to_be32 (tmp);affs_fix_checksum (sb, bh); bh->b_state &= ~(1UL << BH_New);
@@ -748,7 +748,7 @@ static int affs_write_end_ofs(struct file *file, struct address_space *mapping,if (buffer_new (bh)) {AFFS_DATA_HEAD (bh)->ptype =cpu_to_be32 (T_DATA );AFFS_DATA_HEAD (bh)->key =cpu_to_be32 (inode->i_ino); -AFFS_DATA_HEAD (bh)->sequence =cpu_to_be32 (bidx); +AFFS_DATA_HEAD (bh)->sequence =cpu_to_be32 (bidx +1 );AFFS_DATA_HEAD (bh)->size =cpu_to_be32 (bsize);AFFS_DATA_HEAD (bh)->next =0 ; bh->b_state &= ~(1UL << BH_New);
@@ -782,7 +782,7 @@ static int affs_write_end_ofs(struct file *file, struct address_space *mapping,if (buffer_new (bh)) {AFFS_DATA_HEAD (bh)->ptype =cpu_to_be32 (T_DATA );AFFS_DATA_HEAD (bh)->key =cpu_to_be32 (inode->i_ino); -AFFS_DATA_HEAD (bh)->sequence =cpu_to_be32 (bidx); +AFFS_DATA_HEAD (bh)->sequence =cpu_to_be32 (bidx +1 );AFFS_DATA_HEAD (bh)->size =cpu_to_be32 (tmp);AFFS_DATA_HEAD (bh)->next =0 ; bh->b_state &= ~(1UL << BH_New);
Signature · 1 line
2.39.5
Greg Kroah-Hartman
maintainerPATCH 226/279 affs: dont write overlarge OFS data block size fields
In reply to Greg Kroah-Hartman5.15-stable review patch. If anyone has any objections, please let me know.
------------------
From: Simon Tatham <[email protected]>
[ Upstream commit 011ea742a25a77bac3d995f457886a67d178c6f0 ]
If a data sector on an OFS floppy contains a value > 0x1e8 (the largest amount of data that fits in the sector after its header), then an Amiga reading the file can return corrupt data, by taking the overlarge size at its word and reading past the end of the buffer it read the disk sector into!
The cause: when affs_write_end_ofs() writes data to an OFS filesystem, the new size field for a data block was computed by adding the amount of data currently being written (into the block) to the existing value of the size field. This is correct if you're extending the file at the end, but if you seek backwards in the file and overwrite _existing_ data, it can lead to the size field being larger than the maximum legal value.
This commit changes the calculation so that it sets the size field to the max of its previous size and the position within the block that we just wrote up to.
--- fs/affs/file.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-)
fs/affs/file.c +2 -1
@@ -726,7 +726,8 @@ static int affs_write_end_ofs(struct file *file, struct address_space *mapping, tmp =min (bsize - boff, to - from);BUG_ON (boff + tmp > bsize || tmp > bsize);memcpy (AFFS_DATA (bh) + boff, data + from, tmp); -be32_add_cpu (&AFFS_DATA_HEAD (bh)->size, tmp); +AFFS_DATA_HEAD (bh)->size =cpu_to_be32 ( +max (boff + tmp,be32_to_cpu (AFFS_DATA_HEAD (bh)->size)));affs_fix_checksum (sb, bh);mark_buffer_dirty_inode (bh, inode); written += tmp;
Signature · 1 line
2.39.5
Greg Kroah-Hartman
maintainerPATCH 227/279 ksmbd: fix incorrect validation for num_aces field of smb_acl
In reply to Greg Kroah-Hartman5.15-stable review patch. If anyone has any objections, please let me know.
------------------
From: Namjae Jeon <[email protected]>
[ Upstream commit 1b8b67f3c5e5169535e26efedd3e422172e2db64 ]
parse_dcal() validate num_aces to allocate posix_ace_state_array.
if (num_aces > ULONG_MAX / sizeof(struct smb_ace *))
It is an incorrect validation that we can create an array of size ULONG_MAX. smb_acl has ->size field to calculate actual number of aces in request buffer size. Use this to check invalid num_aces.
--- fs/ksmbd/smbacl.c | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-)
fs/ksmbd/smbacl.c +4 -1
@@ -396,7 +396,9 @@ static void parse_dacl(struct user_namespace *user_ns,if (num_aces <=0 )return ; -if (num_aces >ULONG_MAX /sizeof (struct smb_ace *)) +if (num_aces > (le16_to_cpu (pdacl->size) -sizeof (struct smb_acl )) / + (offsetof(struct smb_ace , sid) + + offsetof(struct smb_sid , sub_auth) +sizeof (__le16)))return ; ret =init_acl_state (&acl_state, num_aces);
@@ -430,6 +432,7 @@ static void parse_dacl(struct user_namespace *user_ns, offsetof(struct smb_sid , sub_auth); if (end_of_acl - acl_base < acl_size || + ppace[i]->sid.num_subauth == 0 || ppace[i]->sid.num_subauth > SID_MAX_SUB_AUTHORITIES || (end_of_acl - acl_base < acl_size + sizeof(__le32) * ppace[i]->sid.num_subauth) ||
Signature · 1 line
2.39.5
Greg Kroah-Hartman
maintainerPATCH 228/279 sched/deadline: Use online cpus for validating runtime
In reply to Greg Kroah-Hartman5.15-stable review patch. If anyone has any objections, please let me know.
------------------
From: Shrikanth Hegde <[email protected]>
[ Upstream commit 14672f059d83f591afb2ee1fff56858efe055e5a ]
The ftrace selftest reported a failure because writing -1 to sched_rt_runtime_us returns -EBUSY. This happens when the possible CPUs are different from active CPUs.
Active CPUs are part of one root domain, while remaining CPUs are part of def_root_domain. Since active cpumask is being used, this results in cpus=0 when a non active CPUs is used in the loop.
Fix it by looping over the online CPUs instead for validating the bandwidth calculations.
--- kernel/sched/deadline.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
kernel/sched/deadline.c +1 -1
@@ -2610,7 +2610,7 @@ int sched_dl_global_validate(void)* value smaller than the currently allocated bandwidth in * any of the root_domains. */ -for_each_possible_cpu (cpu) { +for_each_online_cpu (cpu) {rcu_read_lock_sched ();if (dl_bw_visited (cpu, gen))
Signature · 1 line
2.39.5
Greg Kroah-Hartman
maintainerPATCH 229/279 locking/semaphore: Use wake_q to wake up processes outside lock critical section
In reply to Greg Kroah-Hartman5.15-stable review patch. If anyone has any objections, please let me know.
------------------
From: Waiman Long <[email protected]>
[ Upstream commit 85b2b9c16d053364e2004883140538e73b333cdb ]
A circular lock dependency splat has been seen involving down_trylock():
======================================================
WARNING: possible circular locking dependency detected 6.12.0-41.el10.s390x+debug
------------------------------------------------------
dd/32479 is trying to acquire lock:
0015a20accd0d4f8 ((console_sem).lock){-.-.}-{2:2}, at: down_trylock+0x26/0x90
but task is already holding lock:
000000017e461698 (&zone->lock){-.-.}-{2:2}, at: rmqueue_bulk+0xac/0x8f0
the existing dependency chain (in reverse order) is:
-> #4 (&zone->lock){-.-.}-{2:2}:
-> #3 (hrtimer_bases.lock){-.-.}-{2:2}:
-> #2 (&rq->__lock){-.-.}-{2:2}:
-> #1 (&p->pi_lock){-.-.}-{2:2}:
-> #0 ((console_sem).lock){-.-.}-{2:2}:
The console_sem -> pi_lock dependency is due to calling try_to_wake_up() while holding the console_sem raw_spinlock. This dependency can be broken by using wake_q to do the wakeup instead of calling try_to_wake_up() under the console_sem lock. This will also make the semaphore's raw_spinlock become a terminal lock without taking any further locks underneath it.
The hrtimer_bases.lock is a raw_spinlock while zone->lock is a spinlock. The hrtimer_bases.lock -> zone->lock dependency happens via the debug_objects_fill_pool() helper function in the debugobjects code.
-> #4 (&zone->lock){-.-.}-{2:2}:
__lock_acquire+0xe86/0x1cc0
lock_acquire.part.0+0x258/0x630
lock_acquire+0xb8/0xe0
_raw_spin_lock_irqsave+0xb4/0x120
rmqueue_bulk+0xac/0x8f0
__rmqueue_pcplist+0x580/0x830
rmqueue_pcplist+0xfc/0x470
rmqueue.isra.0+0xdec/0x11b0
get_page_from_freelist+0x2ee/0xeb0
__alloc_pages_noprof+0x2c2/0x520
alloc_pages_mpol_noprof+0x1fc/0x4d0
alloc_pages_noprof+0x8c/0xe0
allocate_slab+0x320/0x460
___slab_alloc+0xa58/0x12b0
__slab_alloc.isra.0+0x42/0x60
kmem_cache_alloc_noprof+0x304/0x350
fill_pool+0xf6/0x450
debug_object_activate+0xfe/0x360
enqueue_hrtimer+0x34/0x190
__run_hrtimer+0x3c8/0x4c0
__hrtimer_run_queues+0x1b2/0x260
hrtimer_interrupt+0x316/0x760
do_IRQ+0x9a/0xe0
do_irq_async+0xf6/0x160Normally a raw_spinlock to spinlock dependency is not legitimate and will be warned if CONFIG_PROVE_RAW_LOCK_NESTING is enabled, but debug_objects_fill_pool() is an exception as it explicitly allows this dependency for non-PREEMPT_RT kernel without causing PROVE_RAW_LOCK_NESTING lockdep splat. As a result, this dependency is legitimate and not a bug.
Anyway, semaphore is the only locking primitive left that is still using try_to_wake_up() to do wakeup inside critical section, all the other locking primitives had been migrated to use wake_q to do wakeup outside of the critical section. It is also possible that there are other circular locking dependencies involving printk/console_sem or other existing/new semaphores lurking somewhere which may show up in the future. Let just do the migration now to wake_q to avoid headache like this.
--- kernel/locking/semaphore.c | 13 +++++++++---- 1 file changed, 9 insertions(+), 4 deletions(-)
kernel/locking/semaphore.c +9 -4
@@ -29,6 +29,7 @@#include <linux/export.h> #include <linux/sched.h> #include <linux/sched/debug.h> +#include <linux/sched/wake_q.h> #include <linux/semaphore.h> #include <linux/spinlock.h> #include <linux/ftrace.h>
@@ -37,7 +38,7 @@ static noinline void __down(struct semaphore *sem); static noinline int __down_interruptible(struct semaphore *sem); static noinline int __down_killable(struct semaphore *sem); static noinline int __down_timeout(struct semaphore *sem, long timeout); -static noinline void __up(struct semaphore *sem); +static noinline void __up(struct semaphore *sem, struct wake_q_head *wake_q);/** * down - acquire the semaphore
@@ -182,13 +183,16 @@ EXPORT_SYMBOL(down_timeout);void up (struct semaphore *sem) {unsigned long flags; +DEFINE_WAKE_Q (wake_q);raw_spin_lock_irqsave (&sem->lock, flags);if (likely (list_empty (&sem->wait_list))) sem->count++;else -__up (sem); +__up (sem, &wake_q);raw_spin_unlock_irqrestore (&sem->lock, flags); +if (!wake_q_empty (&wake_q)) +wake_up_q (&wake_q); }EXPORT_SYMBOL (up);
@@ -256,11 +260,12 @@ static noinline int __sched __down_timeout(struct semaphore *sem, long timeout)return __down_common (sem,TASK_UNINTERRUPTIBLE , timeout); } -static noinline void __sched __up(struct semaphore *sem) +static noinline void __sched __up(struct semaphore *sem, +struct wake_q_head *wake_q) {struct semaphore_waiter *waiter =list_first_entry (&sem->wait_list, struct semaphore_waiter, list);list_del (&waiter->list); waiter->up = true; -wake_up_process (waiter->task); +wake_q_add (wake_q, waiter->task); }
Signature · 1 line
2.39.5
Greg Kroah-Hartman
maintainerPATCH 230/279 x86/sgx: Warn explicitly if X86_FEATURE_SGX_LC is not enabled
In reply to Greg Kroah-Hartman5.15-stable review patch. If anyone has any objections, please let me know.
------------------
From: Vladis Dronov <[email protected]>
[ Upstream commit 65be5c95d08eedda570a6c888a12384c77fe7614 ]
The kernel requires X86_FEATURE_SGX_LC to be able to create SGX enclaves, not just X86_FEATURE_SGX.
There is quite a number of hardware which has X86_FEATURE_SGX but not X86_FEATURE_SGX_LC. A kernel running on such hardware does not create the /dev/sgx_enclave file and does so silently.
Explicitly warn if X86_FEATURE_SGX_LC is not enabled to properly notify users that the kernel disabled the SGX driver.
The X86_FEATURE_SGX_LC, a.k.a. SGX Launch Control, is a CPU feature that enables LE (Launch Enclave) hash MSRs to be writable (with additional opt-in required in the 'feature control' MSR) when running enclaves, i.e. using a custom root key rather than the Intel proprietary key for enclave signing.
I've hit this issue myself and have spent some time researching where my /dev/sgx_enclave file went on SGX-enabled hardware.
Related links:
https://github.com/intel/linux-sgx/issues/837
https://patchwork.kernel.org/project/platform-driver-x86/patch/[email protected]/
[ mingo: Made the error message a bit more verbose, and added other cases
where the kernel fails to create the /dev/sgx_enclave device node. ]
--- arch/x86/kernel/cpu/sgx/driver.c | 10 +++++++--- 1 file changed, 7 insertions(+), 3 deletions(-)
arch/x86/kernel/cpu/sgx/driver.c +7 -3
@@ -150,13 +150,15 @@ int __init sgx_drv_init(void)u64 xfrm_mask;int ret; -if (!cpu_feature_enabled (X86_FEATURE_SGX_LC )) +if (!cpu_feature_enabled (X86_FEATURE_SGX_LC )) { +pr_info ("SGX disabled: SGX launch control CPU feature is not available, /dev/sgx_enclave disabled.\n" );return -ENODEV ; + }cpuid_count (SGX_CPUID ,0 , &eax, &ebx, &ecx, &edx);if (!(eax &1 )) { -pr_err ("SGX disabled: SGX1 instruction support not available.\n" ); +pr_info ("SGX disabled: SGX1 instruction support not available, /dev/sgx_enclave disabled.\n" );return -ENODEV ; }
@@ -173,8 +175,10 @@ int __init sgx_drv_init(void) } ret =misc_register (&sgx_dev_enclave); -if (ret) +if (ret) { +pr_info ("SGX disabled: Unable to register the /dev/sgx_enclave driver (%d).\n" , ret);return ret; + }return 0 ; }
Signature · 1 line
2.39.5
Greg Kroah-Hartman
maintainerPATCH 231/279 drm/amd: Keep display off while going into S4
In reply to Greg Kroah-Hartman5.15-stable review patch. If anyone has any objections, please let me know.
------------------
From: Mario Limonciello <[email protected]>
[ Upstream commit 4afacc9948e1f8fdbca401d259ae65ad93d298c0 ]
When userspace invokes S4 the flow is:
1) amdgpu_pmops_prepare()
2) amdgpu_pmops_freeze()
3) Create hibernation image
4) amdgpu_pmops_thaw()
5) Write out image to disk
6) Turn off system
Then on resume amdgpu_pmops_restore() is called.
This flow has a problem that because amdgpu_pmops_thaw() is called it will call amdgpu_device_resume() which will resume all of the GPU.
This includes turning the display hardware back on and discovering connectors again.
This is an unexpected experience for the display to turn back on. Adjust the flow so that during the S4 sequence display hardware is not turned back on.
--- drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c | 11 +++++++++-- drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 5 +++++ 2 files changed, 14 insertions(+), 2 deletions(-)
drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c +9 -2
@@ -2294,7 +2294,6 @@ static int amdgpu_pmops_freeze(struct device *dev) adev->in_s4 = true; r =amdgpu_device_suspend (drm_dev, true); - adev->in_s4 = false;if (r)return r;return amdgpu_asic_reset (adev);
@@ -2303,8 +2302,13 @@ static int amdgpu_pmops_freeze(struct device *dev)static int amdgpu_pmops_thaw (struct device *dev) {struct drm_device *drm_dev =dev_get_drvdata (dev); +struct amdgpu_device *adev =drm_to_adev (drm_dev); +int r; -return amdgpu_device_resume (drm_dev, true); + r =amdgpu_device_resume (drm_dev, true); + adev->in_s4 = false; + +return r; }static int amdgpu_pmops_poweroff (struct device *dev)
@@ -2317,6 +2321,9 @@ static int amdgpu_pmops_poweroff(struct device *dev)static int amdgpu_pmops_restore (struct device *dev) {struct drm_device *drm_dev =dev_get_drvdata (dev); +struct amdgpu_device *adev =drm_to_adev (drm_dev); + + adev->in_s4 = false;return amdgpu_device_resume (drm_dev, true); }
drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c +5 -0
@@ -2710,6 +2710,11 @@ static int dm_resume(void *handle)return 0 ; } + +/* leave display off for S4 sequence */ +if (adev->in_s4) +return 0 ; +/* Recreate dc_state - DC invalidates it when setting power state to S3. */ dc_release_state (dm_state->context); dm_state->context =dc_create_state (dm->dc);
Signature · 1 line
2.39.5
Greg Kroah-Hartman
maintainerPATCH 232/279 ALSA: hda/realtek: Add mute LED quirk for HP Pavilion x360 14-dy1xxx
In reply to Greg Kroah-Hartman5.15-stable review patch. If anyone has any objections, please let me know.
------------------
From: Navon John Lukose <[email protected]>
[ Upstream commit b11a74ac4f545626d0dc95a8ca8c41df90532bf3 ]
Add a fixup to enable the mute LED on HP Pavilion x360 Convertible 14-dy1xxx with ALC295 codec. The appropriate coefficient index and bits were identified through a brute-force method, as detailed in
https://bbs.archlinux.org/viewtopic.php?pid=2079504#p2079504.
--- sound/pci/hda/patch_realtek.c | 21 +++++++++++++++++++++ 1 file changed, 21 insertions(+)
sound/pci/hda/patch_realtek.c +21 -0
@@ -4759,6 +4759,21 @@ static void alc236_fixup_hp_coef_micmute_led(struct hda_codec *codec, } } +static void alc295_fixup_hp_mute_led_coefbit11 (struct hda_codec *codec, +const struct hda_fixup *fix,int action) +{ +struct alc_spec *spec = codec->spec; + +if (action ==HDA_FIXUP_ACT_PRE_PROBE ) { + spec->mute_led_polarity =0 ; + spec->mute_led_coef.idx =0xb ; + spec->mute_led_coef.mask =3 <<3 ; + spec->mute_led_coef.on =1 <<3 ; + spec->mute_led_coef.off =1 <<4 ; +snd_hda_gen_add_mute_led_cdev (codec, coef_mute_led_set); + } +} +static void alc285_fixup_hp_mute_led (struct hda_codec *codec,const struct hda_fixup *fix,int action) {
@@ -6998,6 +7013,7 @@ enum {ALC290_FIXUP_MONO_SPEAKERS_HSJACK ,ALC290_FIXUP_SUBWOOFER ,ALC290_FIXUP_SUBWOOFER_HSJACK , +ALC295_FIXUP_HP_MUTE_LED_COEFBIT11 ,ALC269_FIXUP_THINKPAD_ACPI ,ALC269_FIXUP_DMIC_THINKPAD_ACPI , ALC269VB_FIXUP_INFINIX_ZERO_BOOK_13,
@@ -8544,6 +8560,10 @@ static const struct hda_fixup alc269_fixups[] = { .chained = true, .chain_id = ALC283_FIXUP_INT_MIC, }, + [ALC295_FIXUP_HP_MUTE_LED_COEFBIT11] = { + .type = HDA_FIXUP_FUNC, + .v.func = alc295_fixup_hp_mute_led_coefbit11, + }, [ALC298_FIXUP_SAMSUNG_AMP] = { .type = HDA_FIXUP_FUNC, .v.func = alc298_fixup_samsung_amp,
@@ -9258,6 +9278,7 @@ static const struct snd_pci_quirk alc269_fixup_tbl[] = {SND_PCI_QUIRK (0x103c ,0x84e7 ,"HP Pavilion 15" ,ALC269_FIXUP_HP_MUTE_LED_MIC3 ),SND_PCI_QUIRK (0x103c ,0x8519 ,"HP Spectre x360 15-df0xxx" ,ALC285_FIXUP_HP_SPECTRE_X360 ),SND_PCI_QUIRK (0x103c ,0x8537 ,"HP ProBook 440 G6" ,ALC236_FIXUP_HP_MUTE_LED_MICMUTE_VREF ), +SND_PCI_QUIRK (0x103c ,0x85c6 ,"HP Pavilion x360 Convertible 14-dy1xxx" ,ALC295_FIXUP_HP_MUTE_LED_COEFBIT11 ),SND_PCI_QUIRK (0x103c ,0x85de ,"HP Envy x360 13-ar0xxx" ,ALC285_FIXUP_HP_ENVY_X360 ),SND_PCI_QUIRK (0x103c ,0x860f ,"HP ZBook 15 G6" ,ALC285_FIXUP_HP_GPIO_AMP_INIT ), SND_PCI_QUIRK(0x103c, 0x861f, "HP Elite Dragonfly G1", ALC285_FIXUP_HP_GPIO_AMP_INIT),
Signature · 1 line
2.39.5
Greg Kroah-Hartman
maintainerPATCH 233/279 can: statistics: use atomic access in hot path
In reply to Greg Kroah-Hartman5.15-stable review patch. If anyone has any objections, please let me know.
------------------
From: Oliver Hartkopp <[email protected]>
[ Upstream commit 80b5f90158d1364cbd80ad82852a757fc0692bf2 ]
In can_send() and can_receive() CAN messages and CAN filter matches are counted to be visible in the CAN procfs files.
KCSAN detected a data race within can_send() when two CAN frames have been generated by a timer event writing to the same CAN netdevice at the same time. Use atomic operations to access the statistics in the hot path to fix the KCSAN complaint.
--- net/can/af_can.c | 12 ++++++------ net/can/af_can.h | 12 ++++++------ net/can/proc.c | 46 +++++++++++++++++++++++++++------------------- 3 files changed, 39 insertions(+), 31 deletions(-)
net/can/af_can.c +6 -6
@@ -288,8 +288,8 @@ int can_send(struct sk_buff *skb, int loop)netif_rx_ni (newskb);/* update statistics */ - pkg_stats->tx_frames++; - pkg_stats->tx_frames_delta++; +atomic_long_inc (&pkg_stats->tx_frames); +atomic_long_inc (&pkg_stats->tx_frames_delta);return 0 ;
@@ -649,8 +649,8 @@ static void can_receive(struct sk_buff *skb, struct net_device *dev)int matches;/* update statistics */ - pkg_stats->rx_frames++; - pkg_stats->rx_frames_delta++; +atomic_long_inc (&pkg_stats->rx_frames); +atomic_long_inc (&pkg_stats->rx_frames_delta);/* create non-zero unique skb identifier together with *skb */ while (!(can_skb_prv (skb)->skbcnt))
@@ -671,8 +671,8 @@ static void can_receive(struct sk_buff *skb, struct net_device *dev)consume_skb (skb);if (matches >0 ) { - pkg_stats->matches++; - pkg_stats->matches_delta++; +atomic_long_inc (&pkg_stats->matches); +atomic_long_inc (&pkg_stats->matches_delta); } }
net/can/af_can.h +6 -6
@@ -66,9 +66,9 @@ struct receiver {struct can_pkg_stats {unsigned long jiffies_init; -unsigned long rx_frames; -unsigned long tx_frames; -unsigned long matches; +atomic_long_t rx_frames; +atomic_long_t tx_frames; +atomic_long_t matches;unsigned long total_rx_rate;unsigned long total_tx_rate;
@@ -82,9 +82,9 @@ struct can_pkg_stats {unsigned long max_tx_rate;unsigned long max_rx_match_ratio; -unsigned long rx_frames_delta; -unsigned long tx_frames_delta; -unsigned long matches_delta; +atomic_long_t rx_frames_delta; +atomic_long_t tx_frames_delta; +atomic_long_t matches_delta; };/* persistent statistics */
net/can/proc.c +27 -19
86 lines not on this page · raw message
Signature · 1 line
2.39.5
Greg Kroah-Hartman
maintainerPATCH 234/279 hwmon: (nct6775-core) Fix out of bounds access for NCT679{8,9}
In reply to Greg Kroah-Hartman5.15-stable review patch. If anyone has any objections, please let me know.
------------------
From: Tasos Sahanidis <[email protected]>
[ Upstream commit 815f80ad20b63830949a77c816e35395d5d55144 ]
pwm_num is set to 7 for these chips, but NCT6776_REG_PWM_MODE and NCT6776_PWM_MODE_MASK only contain 6 values.
Fix this by adding another 0 to the end of each array.
--- drivers/hwmon/nct6775.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
drivers/hwmon/nct6775.c +2 -2
@@ -420,8 +420,8 @@ static const s8 NCT6776_BEEP_BITS[] = {static const u16 NCT6776_REG_TOLERANCE_H [] = {0x10c ,0x20c ,0x30c ,0x80c ,0x90c ,0xa0c ,0xb0c }; -static const u8 NCT6776_REG_PWM_MODE [] = {0x04 ,0 ,0 ,0 ,0 ,0 }; -static const u8 NCT6776_PWM_MODE_MASK [] = {0x01 ,0 ,0 ,0 ,0 ,0 }; +static const u8 NCT6776_REG_PWM_MODE [] = {0x04 ,0 ,0 ,0 ,0 ,0 ,0 }; +static const u8 NCT6776_PWM_MODE_MASK [] = {0x01 ,0 ,0 ,0 ,0 ,0 ,0 };static const u16 NCT6776_REG_FAN_MIN [] = {0x63a ,0x63c ,0x63e ,0x640 ,0x642 ,0x64a ,0x64c };
Signature · 1 line
2.39.5
Greg Kroah-Hartman
maintainerPATCH 235/279 spufs: fix a leak on spufs_new_file() failure
In reply to Greg Kroah-Hartman5.15-stable review patch. If anyone has any objections, please let me know.
------------------
From: Al Viro <[email protected]>
[ Upstream commit d1ca8698ca1332625d83ea0d753747be66f9906d ]
It's called from spufs_fill_dir(), and caller of that will do spufs_rmdir() in case of failure. That does remove everything we'd managed to create, but... the problem dentry is still negative. IOW, it needs to be explicitly dropped.
--- arch/powerpc/platforms/cell/spufs/inode.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-)
arch/powerpc/platforms/cell/spufs/inode.c +3 -1
@@ -190,8 +190,10 @@ static int spufs_fill_dir(struct dentry *dir,return -ENOMEM ; ret =spufs_new_file (dir->d_sb, dentry, files->ops, files->mode & mode, files->size, ctx); -if (ret) +if (ret) { +dput (dentry);return ret; + } files++; }return 0 ;
Signature · 1 line
2.39.5
Greg Kroah-Hartman
maintainerPATCH 236/279 spufs: fix a leak in spufs_create_context()
In reply to Greg Kroah-Hartman5.15-stable review patch. If anyone has any objections, please let me know.
------------------
From: Al Viro <[email protected]>
[ Upstream commit 0f5cce3fc55b08ee4da3372baccf4bcd36a98396 ]
Leak fixes back in 2008 missed one case - if we are trying to set affinity and spufs_mkdir() fails, we need to drop the reference to neighbor.
--- arch/powerpc/platforms/cell/spufs/inode.c | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-)
arch/powerpc/platforms/cell/spufs/inode.c +4 -1
@@ -436,8 +436,11 @@ spufs_create_context(struct inode *inode, struct dentry *dentry, } ret =spufs_mkdir (inode, dentry, flags, mode &0777 ); -if (ret) +if (ret) { +if (neighbor) +put_spu_context (neighbor); goto out_aff_unlock; + }if (affinity) { spufs_set_affinity(flags, SPUFS_I(d_inode(dentry))->i_ctx,
Signature · 1 line
2.39.5
Greg Kroah-Hartman
maintainerPATCH 237/279 riscv: ftrace: Add parentheses in macro definitions of make_call_t0 and make_call_ra
In reply to Greg Kroah-Hartman5.15-stable review patch. If anyone has any objections, please let me know.
------------------
From: Juhan Jin <[email protected]>
[ Upstream commit 5f1a58ed91a040d4625d854f9bb3dd4995919202 ]
This patch adds parentheses to parameters caller and callee of macros make_call_t0 and make_call_ra. Every existing invocation of these two macros uses a single variable for each argument, so the absence of the parentheses seems okay. However, future invocations might use more complex expressions as arguments. For example, a future invocation might look like this: make_call_t0(a - b, c, call). Without parentheses in the macro definition, the macro invocation expands to:
...
unsigned int offset = (unsigned long) c - (unsigned long) a - b;
...
which is clearly wrong.
The use of parentheses ensures arguments are correctly evaluated and potentially saves future users of make_call_t0 and make_call_ra debugging trouble.
--- arch/riscv/include/asm/ftrace.h | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
arch/riscv/include/asm/ftrace.h +2 -2
@@ -77,7 +77,7 @@ struct dyn_arch_ftrace {#define make_call_t0 (caller, callee, call) \ do { \ unsigned int offset = \ - (unsigned long) callee - (unsigned long) caller; \ + (unsigned long) (callee) - (unsigned long) (caller); \ call[0] = to_auipc_t0(offset); \ call[1] = to_jalr_t0(offset); \ } while (0)
@@ -93,7 +93,7 @@ do { \#define make_call_ra (caller, callee, call) \ do { \ unsigned int offset = \ - (unsigned long) callee - (unsigned long) caller; \ + (unsigned long) (callee) - (unsigned long) (caller); \ call[0] = to_auipc_ra(offset); \ call[1] = to_jalr_ra(offset); \ } while (0)
Signature · 1 line
2.39.5
Greg Kroah-Hartman
maintainerPATCH 238/279 ntb_hw_switchtec: Fix shift-out-of-bounds in switchtec_ntb_mw_set_trans
In reply to Greg Kroah-Hartman5.15-stable review patch. If anyone has any objections, please let me know.
------------------
From: Yajun Deng <[email protected]>
[ Upstream commit de203da734fae00e75be50220ba5391e7beecdf9 ]
There is a kernel API ntb_mw_clear_trans() would pass 0 to both addr and size. This would make xlate_pos negative.
[ 23.734156] switchtec switchtec0: MW 0: part 0 addr 0x0000000000000000 size 0x0000000000000000 [ 23.734158] ================================================================================ [ 23.734172] UBSAN: shift-out-of-bounds in drivers/ntb/hw/mscc/ntb_hw_switchtec.c:293:7 [ 23.734418] shift exponent -1 is negative
Ensuring xlate_pos is a positive or zero before BIT.
--- drivers/ntb/hw/mscc/ntb_hw_switchtec.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/ntb/hw/mscc/ntb_hw_switchtec.c +1 -1
@@ -288,7 +288,7 @@ static int switchtec_ntb_mw_set_trans(struct ntb_dev *ntb, int pidx, int widx,if (size !=0 && xlate_pos <12 )return -EINVAL ; -if (!IS_ALIGNED (addr,BIT_ULL (xlate_pos))) { +if (xlate_pos >=0 && !IS_ALIGNED (addr,BIT_ULL (xlate_pos))) {/* * In certain circumstances we can get a buffer that is * not aligned to its size. (Most of the time
Signature · 1 line
2.39.5
Greg Kroah-Hartman
maintainerPATCH 239/279 ntb: intel: Fix using link status DBs
In reply to Greg Kroah-Hartman5.15-stable review patch. If anyone has any objections, please let me know.
------------------
From: Nikita Shubin <[email protected]>
[ Upstream commit 8144e9c8f30fb23bb736a5d24d5c9d46965563c4 ]
Make sure we are not using DB's which were remapped for link status.
--- drivers/ntb/hw/intel/ntb_hw_gen3.c | 3 +++ 1 file changed, 3 insertions(+)
drivers/ntb/hw/intel/ntb_hw_gen3.c +3 -0
@@ -215,6 +215,9 @@ static int gen3_init_ntb(struct intel_ntb_dev *ndev) } ndev->db_valid_mask =BIT_ULL (ndev->db_count) -1 ; +/* Make sure we are not using DB's used for link status */ +if (ndev->hwerr_flags &NTB_HWERR_MSIX_VECTOR32_BAD ) + ndev->db_valid_mask &= ~ndev->db_link_mask; ndev->reg->db_iowrite(ndev->db_valid_mask, ndev->self_mmio +
Signature · 1 line
2.39.5
Greg Kroah-Hartman
maintainerPATCH 240/279 ASoC: imx-card: Add NULL check in imx_card_probe()
In reply to Greg Kroah-Hartman5.15-stable review patch. If anyone has any objections, please let me know.
------------------
From: Henry Martin <[email protected]>
[ Upstream commit 93d34608fd162f725172e780b1c60cc93a920719 ]
devm_kasprintf() returns NULL when memory allocation fails. Currently, imx_card_probe() does not check for this case, which results in a NULL pointer dereference.
Add NULL check after devm_kasprintf() to prevent this issue.
--- sound/soc/fsl/imx-card.c | 4 ++++ 1 file changed, 4 insertions(+)
sound/soc/fsl/imx-card.c +4 -0
@@ -759,6 +759,8 @@ static int imx_card_probe(struct platform_device *pdev) data->dapm_routes[i].sink =devm_kasprintf (&pdev->dev,GFP_KERNEL ,"%d %s" , i +1 ,"Playback" ); +if (!data->dapm_routes[i].sink) +return -ENOMEM ; data->dapm_routes[i].source ="CPU-Playback" ; } }
@@ -776,6 +778,8 @@ static int imx_card_probe(struct platform_device *pdev) data->dapm_routes[i].source =devm_kasprintf (&pdev->dev,GFP_KERNEL ,"%d %s" , i +1 ,"Capture" ); +if (!data->dapm_routes[i].source) +return -ENOMEM ; data->dapm_routes[i].sink ="CPU-Capture" ; } }
Signature · 1 line
2.39.5
Greg Kroah-Hartman
maintainerPATCH 241/279 netfilter: nft_set_hash: GC reaps elements with conncount for dynamic sets only
In reply to Greg Kroah-Hartman5.15-stable review patch. If anyone has any objections, please let me know.
------------------
From: Pablo Neira Ayuso <[email protected]>
[ Upstream commit 9d74da1177c800eb3d51c13f9821b7b0683845a5 ]
conncount has its own GC handler which determines when to reap stale elements, this is convenient for dynamic sets. However, this also reaps non-dynamic sets with static configurations coming from control plane. Always run connlimit gc handler but honor feedback to reap element if this set is dynamic.
--- net/netfilter/nft_set_hash.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-)
net/netfilter/nft_set_hash.c +2 -1
@@ -310,7 +310,8 @@ static bool nft_rhash_expr_needs_gc_run(const struct nft_set *set, nft_setelem_expr_foreach(expr, elem_expr, size) {if (expr->ops->gc && - expr->ops->gc (read_pnet (&set->net), expr)) + expr->ops->gc (read_pnet (&set->net), expr) && + set->flags &NFT_SET_EVAL )return true; }
Signature · 1 line
2.39.5
Greg Kroah-Hartman
maintainerPATCH 242/279 netlabel: Fix NULL pointer exception caused by CALIPSO on IPv4 sockets
In reply to Greg Kroah-Hartman5.15-stable review patch. If anyone has any objections, please let me know.
------------------
From: Debin Zhu <[email protected]>
[ Upstream commit 078aabd567de3d63d37d7673f714e309d369e6e2 ]
When calling netlbl_conn_setattr(), addr->sa_family is used to determine the function behavior. If sk is an IPv4 socket, but the connect function is called with an IPv6 address, the function calipso_sock_setattr() is triggered. Inside this function, the following code is executed:
sk_fullsock(__sk) ? inet_sk(__sk)->pinet6 : NULL;
Since sk is an IPv4 socket, pinet6 is NULL, leading to a null pointer dereference.
This patch fixes the issue by checking if inet6_sk(sk) returns a NULL pointer before accessing pinet6.
--- net/ipv6/calipso.c | 21 ++++++++++++++++++--- 1 file changed, 18 insertions(+), 3 deletions(-)
net/ipv6/calipso.c +18 -3
@@ -1075,8 +1075,13 @@ static int calipso_sock_getattr(struct sock *sk,struct ipv6_opt_hdr *hop;int opt_len, len, ret_val = -ENOMSG , offset;unsigned char *opt; -struct ipv6_txoptions *txopts =txopt_get (inet6_sk (sk)); +struct ipv6_pinfo *pinfo =inet6_sk (sk); +struct ipv6_txoptions *txopts; + +if (!pinfo) +return -EAFNOSUPPORT ; + txopts =txopt_get (pinfo);if (!txopts || !txopts->hopopt) goto done;
@@ -1128,8 +1133,13 @@ static int calipso_sock_setattr(struct sock *sk, {int ret_val;struct ipv6_opt_hdr *old, *new; -struct ipv6_txoptions *txopts =txopt_get (inet6_sk (sk)); +struct ipv6_pinfo *pinfo =inet6_sk (sk); +struct ipv6_txoptions *txopts; + +if (!pinfo) +return -EAFNOSUPPORT ; + txopts =txopt_get (pinfo); old =NULL ;if (txopts) old = txopts->hopopt;
@@ -1156,8 +1166,13 @@ static int calipso_sock_setattr(struct sock *sk,static void calipso_sock_delattr (struct sock *sk) {struct ipv6_opt_hdr *new_hop; -struct ipv6_txoptions *txopts =txopt_get (inet6_sk (sk)); +struct ipv6_pinfo *pinfo =inet6_sk (sk); +struct ipv6_txoptions *txopts; + +if (!pinfo) +return ; + txopts =txopt_get (pinfo);if (!txopts || !txopts->hopopt) goto done;
Signature · 1 line
2.39.5
Greg Kroah-Hartman
maintainerPATCH 243/279 net_sched: skbprio: Remove overly strict queue assertions
In reply to Greg Kroah-Hartman5.15-stable review patch. If anyone has any objections, please let me know.
------------------
From: Cong Wang <[email protected]>
[ Upstream commit ce8fe975fd99b49c29c42e50f2441ba53112b2e8 ]
In the current implementation, skbprio enqueue/dequeue contains an assertion that fails under certain conditions when SKBPRIO is used as a child qdisc under TBF with specific parameters. The failure occurs because TBF sometimes peeks at packets in the child qdisc without actually dequeuing them when tokens are unavailable.
This peek operation creates a discrepancy between the parent and child qdisc queue length counters. When TBF later receives a high-priority packet, SKBPRIO's queue length may show a different value than what's reflected in its internal priority queue tracking, triggering the assertion.
The fix removes this overly strict assertions in SKBPRIO, they are not necessary at all.
--- net/sched/sch_skbprio.c | 3 --- 1 file changed, 3 deletions(-)
net/sched/sch_skbprio.c +0 -3
@@ -121,8 +121,6 @@ static int skbprio_enqueue(struct sk_buff *skb, struct Qdisc *sch,/* Check to update highest and lowest priorities. */ if (skb_queue_empty (lp_qdisc)) {if (q->lowest_prio == q->highest_prio) { -/* The incoming packet is the only packet in queue. */ -BUG_ON (sch->q.qlen !=1 ); q->lowest_prio = prio; q->highest_prio = prio; }else {
@@ -154,7 +152,6 @@ static struct sk_buff *skbprio_dequeue(struct Qdisc *sch)/* Update highest priority field. */ if (skb_queue_empty (hpq)) {if (q->lowest_prio == q->highest_prio) { -BUG_ON (sch->q.qlen); q->highest_prio =0 ; q->lowest_prio =SKBPRIO_MAX_PRIORITY -1 ; }else {
Signature · 1 line
2.39.5
Greg Kroah-Hartman
maintainerPATCH 244/279 net: mvpp2: Prevent parser TCAM memory corruption
In reply to Greg Kroah-Hartman5.15-stable review patch. If anyone has any objections, please let me know.
------------------
From: Tobias Waldekranz <[email protected]>
[ Upstream commit 96844075226b49af25a69a1d084b648ec2d9b08d ]
Protect the parser TCAM/SRAM memory, and the cached (shadow) SRAM information, from concurrent modifications.
Both the TCAM and SRAM tables are indirectly accessed by configuring an index register that selects the row to read or write to. This means that operations must be atomic in order to, e.g., avoid spreading writes across multiple rows. Since the shadow SRAM array is used to find free rows in the hardware table, it must also be protected in order to avoid TOCTOU errors where multiple cores allocate the same row.
This issue was detected in a situation where mvpp2_set_rx_mode() ran concurrently on two CPUs. In this particular case the MVPP2_PE_MAC_UC_PROMISCUOUS entry was corrupted, causing the classifier unit to drop all incoming unicast - indicated by the rx_classifier_drops counter.
--- drivers/net/ethernet/marvell/mvpp2/mvpp2.h | 3 + .../net/ethernet/marvell/mvpp2/mvpp2_main.c | 3 +- .../net/ethernet/marvell/mvpp2/mvpp2_prs.c | 201 ++++++++++++------ 3 files changed, 140 insertions(+), 67 deletions(-)
drivers/net/ethernet/marvell/mvpp2/mvpp2.h +3 -0
@@ -1108,6 +1108,9 @@ struct mvpp2 {/* Spinlocks for CM3 shared memory configuration */ spinlock_t mss_spinlock; + +/* Spinlock for shared PRS parser memory and shadow table */ +spinlock_t prs_spinlock; };struct mvpp2_pcpu_stats {
drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c +2 -1
@@ -7589,8 +7589,9 @@ static int mvpp2_probe(struct platform_device *pdev)if (mvpp2_read (priv,MVPP2_VER_ID_REG ) ==MVPP2_VER_PP23 ) priv->hw_version =MVPP23 ; -/* Init mss lock */ +/* Init locks for shared packet processor resources */ spin_lock_init (&priv->mss_spinlock); +spin_lock_init (&priv->prs_spinlock);/* Initialize network controller */ err =mvpp2_init (pdev, priv);
drivers/net/ethernet/marvell/mvpp2/mvpp2_prs.c +135 -66
536 lines not on this page · raw message
Signature · 1 line
2.39.5
Greg Kroah-Hartman
maintainerPATCH 245/279 vsock: avoid timeout during connect() if the socket is closing
In reply to Greg Kroah-Hartman5.15-stable review patch. If anyone has any objections, please let me know.
------------------
From: Stefano Garzarella <[email protected]>
[ Upstream commit fccd2b711d9628c7ce0111d5e4938652101ee30a ]
When a peer attempts to establish a connection, vsock_connect() contains a loop that waits for the state to be TCP_ESTABLISHED. However, the other peer can be fast enough to accept the connection and close it immediately, thus moving the state to TCP_CLOSING.
When this happens, the peer in the vsock_connect() is properly woken up, but since the state is not TCP_ESTABLISHED, it goes back to sleep until the timeout expires, returning -ETIMEDOUT.
If the socket state is TCP_CLOSING, waiting for the timeout is pointless. vsock_connect() can return immediately without errors or delay since the connection actually happened. The socket will be in a closing state, but this is not an issue, and subsequent calls will fail as expected.
We discovered this issue while developing a test that accepts and immediately closes connections to stress the transport switch between two connect() calls, where the first one was interrupted by a signal (see Closes link).
--- net/vmw_vsock/af_vsock.c | 6 +++++- 1 file changed, 5 insertions(+), 1 deletion(-)
net/vmw_vsock/af_vsock.c +5 -1
@@ -1428,7 +1428,11 @@ static int vsock_connect(struct socket *sock, struct sockaddr *addr, timeout = vsk->connect_timeout;prepare_to_wait (sk_sleep (sk), &wait,TASK_INTERRUPTIBLE ); -while (sk->sk_state !=TCP_ESTABLISHED && sk->sk_err ==0 ) { +/* If the socket is already closing or it is in an error state, there +* is no point in waiting. +*/ +while (sk->sk_state !=TCP_ESTABLISHED && + sk->sk_state !=TCP_CLOSING && sk->sk_err ==0 ) {if (flags &O_NONBLOCK ) {/* If we're not going to block, we schedule a timeout * function to generate a timeout on the connection
Signature · 1 line
2.39.5
Greg Kroah-Hartman
maintainerPATCH 246/279 tunnels: Accept PACKET_HOST in skb_tunnel_check_pmtu().
In reply to Greg Kroah-Hartman5.15-stable review patch. If anyone has any objections, please let me know.
------------------
From: Guillaume Nault <[email protected]>
[ Upstream commit 8930424777e43257f5bf6f0f0f53defd0d30415c ]
Because skb_tunnel_check_pmtu() doesn't handle PACKET_HOST packets, commit 30a92c9e3d6b ("openvswitch: Set the skbuff pkt_type for proper pmtud support.") forced skb->pkt_type to PACKET_OUTGOING for openvswitch packets that are sent using the OVS_ACTION_ATTR_OUTPUT action. This allowed such packets to invoke the iptunnel_pmtud_check_icmp() or iptunnel_pmtud_check_icmpv6() helpers and thus trigger PMTU update on the input device.
However, this also broke other parts of PMTU discovery. Since these packets don't have the PACKET_HOST type anymore, they won't trigger the sending of ICMP Fragmentation Needed or Packet Too Big messages to remote hosts when oversized (see the skb_in->pkt_type condition in __icmp_send() for example).
These two skb->pkt_type checks are therefore incompatible as one requires skb->pkt_type to be PACKET_HOST, while the other requires it to be anything but PACKET_HOST.
It makes sense to not trigger ICMP messages for non-PACKET_HOST packets as these messages should be generated only for incoming l2-unicast packets. However there doesn't seem to be any reason for skb_tunnel_check_pmtu() to ignore PACKET_HOST packets.
Allow both cases to work by allowing skb_tunnel_check_pmtu() to work on PACKET_HOST packets and not overriding skb->pkt_type in openvswitch anymore.
--- net/ipv4/ip_tunnel_core.c | 2 +- net/openvswitch/actions.c | 6 ------ 2 files changed, 1 insertion(+), 7 deletions(-)
net/ipv4/ip_tunnel_core.c +1 -1
@@ -415,7 +415,7 @@ int skb_tunnel_check_pmtu(struct sk_buff *skb, struct dst_entry *encap_dst,skb_dst_update_pmtu_no_confirm (skb, mtu); -if (!reply || skb->pkt_type ==PACKET_HOST ) +if (!reply)return 0 ;if (skb->protocol ==htons (ETH_P_IP ))
net/openvswitch/actions.c +0 -6
@@ -924,12 +924,6 @@ static void do_output(struct datapath *dp, struct sk_buff *skb, int out_port,pskb_trim (skb,ovs_mac_header_len (key)); } -/* Need to set the pkt_type to involve the routing layer. The -* packet movement through the OVS datapath doesn't generally -* use routing, but this is needed for tunnel cases. -*/ - skb->pkt_type =PACKET_OUTGOING ; -if (likely (!mru || (skb->len <= mru + vport->dev->hard_header_len))) {ovs_vport_send (vport, skb,ovs_key_mac_proto (key));
Signature · 1 line
2.39.5
Greg Kroah-Hartman
maintainerPATCH 247/279 netfilter: nft_tunnel: fix geneve_opt type confusion addition
In reply to Greg Kroah-Hartman5.15-stable review patch. If anyone has any objections, please let me know.
------------------
From: Lin Ma <[email protected]>
[ Upstream commit 1b755d8eb1ace3870789d48fbd94f386ad6e30be ]
When handling multiple NFTA_TUNNEL_KEY_OPTS_GENEVE attributes, the parsing logic should place every geneve_opt structure one by one compactly. Hence, when deciding the next geneve_opt position, the pointer addition should be in units of char *.
However, the current implementation erroneously does type conversion before the addition, which will lead to heap out-of-bounds write.
[ 6.989857] ================================================================== [ 6.990293] BUG: KASAN: slab-out-of-bounds in nft_tunnel_obj_init+0x977/0xa70 [ 6.990725] Write of size 124 at addr ffff888005f18974 by task poc/178 [ 6.991162] [ 6.991259] CPU: 0 PID: 178 Comm: poc-oob-write Not tainted 6.1.132 #1 [ 6.991655] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 04/01/2014 [ 6.992281] Call Trace: [ 6.992423] <TASK> [ 6.992586] dump_stack_lvl+0x44/0x5c [ 6.992801] print_report+0x184/0x4be [ 6.993790] kasan_report+0xc5/0x100 [ 6.994252] kasan_check_range+0xf3/0x1a0 [ 6.994486] memcpy+0x38/0x60 [ 6.994692] nft_tunnel_obj_init+0x977/0xa70 [ 6.995677] nft_obj_init+0x10c/0x1b0 [ 6.995891] nf_tables_newobj+0x585/0x950 [ 6.996922] nfnetlink_rcv_batch+0xdf9/0x1020 [ 6.998997] nfnetlink_rcv+0x1df/0x220 [ 6.999537] netlink_unicast+0x395/0x530 [ 7.000771] netlink_sendmsg+0x3d0/0x6d0 [ 7.001462] __sock_sendmsg+0x99/0xa0 [ 7.001707] ____sys_sendmsg+0x409/0x450 [ 7.002391] ___sys_sendmsg+0xfd/0x170 [ 7.003145] __sys_sendmsg+0xea/0x170 [ 7.004359] do_syscall_64+0x5e/0x90 [ 7.005817] entry_SYSCALL_64_after_hwframe+0x6e/0xd8 [ 7.006127] RIP: 0033:0x7ec756d4e407 [ 7.006339] Code: 48 89 fa 4c 89 df e8 38 aa 00 00 8b 93 08 03 00 00 59 5e 48 83 f8 fc 74 1a 5b c3 0f 1f 84 00 00 00 00 00 48 8b 44 24 10 0f 05 <5b> c3 0f 1f 80 00 00 00 00 83 e2 39 83 faf [ 7.007364] RSP: 002b:00007ffed5d46760 EFLAGS: 00000202 ORIG_RAX: 000000000000002e [ 7.007827] RAX: ffffffffffffffda RBX: 00007ec756cc4740 RCX: 00007ec756d4e407 [ 7.008223] RDX: 0000000000000000 RSI: 00007ffed5d467f0 RDI: 0000000000000003 [ 7.008620] RBP: 00007ffed5d468a0 R08: 0000000000000000 R09: 0000000000000000 [ 7.009039] R10: 0000000000000000 R11: 0000000000000202 R12: 0000000000000000 [ 7.009429] R13: 00007ffed5d478b0 R14: 00007ec756ee5000 R15: 00005cbd4e655cb8
Fix this bug with correct pointer addition and conversion in parse and dump code.
--- net/netfilter/nft_tunnel.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
net/netfilter/nft_tunnel.c +2 -2
@@ -311,7 +311,7 @@ static const struct nla_policy nft_tunnel_opts_geneve_policy[NFTA_TUNNEL_KEY_GENstatic int nft_tunnel_obj_geneve_init (const struct nlattr *attr,struct nft_tunnel_opts *opts) { -struct geneve_opt *opt = (struct geneve_opt *)opts->u.data + opts->len; +struct geneve_opt *opt = (struct geneve_opt *)(opts->u.data + opts->len);struct nlattr *tb[NFTA_TUNNEL_KEY_GENEVE_MAX +1 ];int err, data_len;
@@ -592,7 +592,7 @@ static int nft_tunnel_opts_dump(struct sk_buff *skb,if (!inner) goto failure; while (opts->len > offset) { - opt = (struct geneve_opt *)opts->u.data + offset; + opt = (struct geneve_opt *)(opts->u.data + offset); if (nla_put_be16(skb, NFTA_TUNNEL_KEY_GENEVE_CLASS, opt->opt_class) || nla_put_u8(skb, NFTA_TUNNEL_KEY_GENEVE_TYPE,
Signature · 1 line
2.39.5
Greg Kroah-Hartman
maintainerPATCH 248/279 ipv6: fix omitted netlink attributes when using RTEXT_FILTER_SKIP_STATS
In reply to Greg Kroah-Hartman5.15-stable review patch. If anyone has any objections, please let me know.
------------------
From: Fernando Fernandez Mancera <[email protected]>
[ Upstream commit 7ac6ea4a3e0898db76aecccd68fb2c403eb7d24e ]
Using RTEXT_FILTER_SKIP_STATS is incorrectly skipping non-stats IPv6 netlink attributes on link dump. This causes issues on userspace tools, e.g iproute2 is not rendering address generation mode as it should due to missing netlink attribute.
Move the filling of IFLA_INET6_STATS and IFLA_INET6_ICMP6STATS to a helper function guarded by a flag check to avoid hitting the same situation in the future.
--- net/ipv6/addrconf.c | 37 +++++++++++++++++++++++++------------ 1 file changed, 25 insertions(+), 12 deletions(-)
net/ipv6/addrconf.c +25 -12
@@ -5689,6 +5689,27 @@ static void snmp6_fill_stats(u64 *stats, struct inet6_dev *idev, int attrtype, } } +static int inet6_fill_ifla6_stats_attrs (struct sk_buff *skb, +struct inet6_dev *idev) +{ +struct nlattr *nla; + + nla =nla_reserve (skb,IFLA_INET6_STATS ,IPSTATS_MIB_MAX *sizeof (u64)); +if (!nla) + goto nla_put_failure; +snmp6_fill_stats (nla_data (nla), idev,IFLA_INET6_STATS ,nla_len (nla)); + + nla =nla_reserve (skb,IFLA_INET6_ICMP6STATS ,ICMP6_MIB_MAX *sizeof (u64)); +if (!nla) + goto nla_put_failure; +snmp6_fill_stats (nla_data (nla), idev,IFLA_INET6_ICMP6STATS ,nla_len (nla)); + +return 0 ; + +nla_put_failure: +return -EMSGSIZE ; +} +static int inet6_fill_ifla6_attrs (struct sk_buff *skb,struct inet6_dev *idev,u32 ext_filter_mask) {
@@ -5710,18 +5731,10 @@ static int inet6_fill_ifla6_attrs(struct sk_buff *skb, struct inet6_dev *idev,/* XXX - MC not implemented */ -if (ext_filter_mask &RTEXT_FILTER_SKIP_STATS ) -return 0 ; - - nla =nla_reserve (skb,IFLA_INET6_STATS ,IPSTATS_MIB_MAX *sizeof (u64)); -if (!nla) - goto nla_put_failure; -snmp6_fill_stats (nla_data (nla), idev,IFLA_INET6_STATS ,nla_len (nla)); - - nla =nla_reserve (skb,IFLA_INET6_ICMP6STATS ,ICMP6_MIB_MAX *sizeof (u64)); -if (!nla) - goto nla_put_failure; -snmp6_fill_stats (nla_data (nla), idev,IFLA_INET6_ICMP6STATS ,nla_len (nla)); +if (!(ext_filter_mask &RTEXT_FILTER_SKIP_STATS )) { +if (inet6_fill_ifla6_stats_attrs (skb, idev) <0 ) + goto nla_put_failure; + } nla =nla_reserve (skb,IFLA_INET6_TOKEN ,sizeof (struct in6_addr ));if (!nla)
Signature · 1 line
2.39.5
Greg Kroah-Hartman
maintainerPATCH 249/279 net: fix geneve_opt length integer overflow
In reply to Greg Kroah-Hartman5.15-stable review patch. If anyone has any objections, please let me know.
------------------
From: Lin Ma <[email protected]>
[ Upstream commit b27055a08ad4b415dcf15b63034f9cb236f7fb40 ]
struct geneve_opt uses 5 bit length for each single option, which means every vary size option should be smaller than 128 bytes.
However, all current related Netlink policies cannot promise this length condition and the attacker can exploit a exact 128-byte size option to *fake* a zero length option and confuse the parsing logic, further achieve heap out-of-bounds read.
One example crash log is like below:
[ 3.905425] ================================================================== [ 3.905925] BUG: KASAN: slab-out-of-bounds in nla_put+0xa9/0xe0 [ 3.906255] Read of size 124 at addr ffff888005f291cc by task poc/177 [ 3.906646] [ 3.906775] CPU: 0 PID: 177 Comm: poc-oob-read Not tainted 6.1.132 #1 [ 3.907131] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 04/01/2014 [ 3.907784] Call Trace: [ 3.907925] <TASK> [ 3.908048] dump_stack_lvl+0x44/0x5c [ 3.908258] print_report+0x184/0x4be [ 3.909151] kasan_report+0xc5/0x100 [ 3.909539] kasan_check_range+0xf3/0x1a0 [ 3.909794] memcpy+0x1f/0x60 [ 3.909968] nla_put+0xa9/0xe0 [ 3.910147] tunnel_key_dump+0x945/0xba0 [ 3.911536] tcf_action_dump_1+0x1c1/0x340 [ 3.912436] tcf_action_dump+0x101/0x180 [ 3.912689] tcf_exts_dump+0x164/0x1e0 [ 3.912905] fw_dump+0x18b/0x2d0 [ 3.913483] tcf_fill_node+0x2ee/0x460 [ 3.914778] tfilter_notify+0xf4/0x180 [ 3.915208] tc_new_tfilter+0xd51/0x10d0 [ 3.918615] rtnetlink_rcv_msg+0x4a2/0x560 [ 3.919118] netlink_rcv_skb+0xcd/0x200 [ 3.919787] netlink_unicast+0x395/0x530 [ 3.921032] netlink_sendmsg+0x3d0/0x6d0 [ 3.921987] __sock_sendmsg+0x99/0xa0 [ 3.922220] __sys_sendto+0x1b7/0x240 [ 3.922682] __x64_sys_sendto+0x72/0x90 [ 3.922906] do_syscall_64+0x5e/0x90 [ 3.923814] entry_SYSCALL_64_after_hwframe+0x6e/0xd8 [ 3.924122] RIP: 0033:0x7e83eab84407 [ 3.924331] Code: 48 89 fa 4c 89 df e8 38 aa 00 00 8b 93 08 03 00 00 59 5e 48 83 f8 fc 74 1a 5b c3 0f 1f 84 00 00 00 00 00 48 8b 44 24 10 0f 05 <5b> c3 0f 1f 80 00 00 00 00 83 e2 39 83 faf [ 3.925330] RSP: 002b:00007ffff505e370 EFLAGS: 00000202 ORIG_RAX: 000000000000002c [ 3.925752] RAX: ffffffffffffffda RBX: 00007e83eaafa740 RCX: 00007e83eab84407 [ 3.926173] RDX: 00000000000001a8 RSI: 00007ffff505e3c0 RDI: 0000000000000003 [ 3.926587] RBP: 00007ffff505f460 R08: 00007e83eace1000 R09: 000000000000000c [ 3.926977] R10: 0000000000000000 R11: 0000000000000202 R12: 00007ffff505f3c0 [ 3.927367] R13: 00007ffff505f5c8 R14: 00007e83ead1b000 R15: 00005d4fbbe6dcb8
Fix these issues by enforing correct length condition in related policies.
--- net/ipv4/ip_tunnel_core.c | 2 +- net/netfilter/nft_tunnel.c | 2 +- net/sched/act_tunnel_key.c | 2 +- net/sched/cls_flower.c | 2 +- 4 files changed, 4 insertions(+), 4 deletions(-)
net/ipv4/ip_tunnel_core.c +1 -1
@@ -450,7 +450,7 @@ static const struct nla_policy geneve_opt_policy[LWTUNNEL_IP_OPT_GENEVE_MAX + 1] = { [LWTUNNEL_IP_OPT_GENEVE_CLASS] = { .type = NLA_U16 }, [LWTUNNEL_IP_OPT_GENEVE_TYPE] = { .type = NLA_U8 }, - [LWTUNNEL_IP_OPT_GENEVE_DATA] = { .type = NLA_BINARY, .len = 128 }, + [LWTUNNEL_IP_OPT_GENEVE_DATA] = { .type = NLA_BINARY, .len = 127 }, }; static const struct nla_policy
net/netfilter/nft_tunnel.c +1 -1
@@ -305,7 +305,7 @@ static int nft_tunnel_obj_erspan_init(const struct nlattr *attr,static const struct nla_policy nft_tunnel_opts_geneve_policy[NFTA_TUNNEL_KEY_GENEVE_MAX +1 ] = { [NFTA_TUNNEL_KEY_GENEVE_CLASS ] = { .type =NLA_U16 }, [NFTA_TUNNEL_KEY_GENEVE_TYPE ] = { .type =NLA_U8 }, - [NFTA_TUNNEL_KEY_GENEVE_DATA ] = { .type =NLA_BINARY , .len =128 }, + [NFTA_TUNNEL_KEY_GENEVE_DATA ] = { .type =NLA_BINARY , .len =127 }, }; static int nft_tunnel_obj_geneve_init(const struct nlattr *attr,
net/sched/act_tunnel_key.c +1 -1
@@ -67,7 +67,7 @@ geneve_opt_policy[TCA_TUNNEL_KEY_ENC_OPT_GENEVE_MAX + 1] = { [TCA_TUNNEL_KEY_ENC_OPT_GENEVE_CLASS] = { .type = NLA_U16 }, [TCA_TUNNEL_KEY_ENC_OPT_GENEVE_TYPE] = { .type = NLA_U8 }, [TCA_TUNNEL_KEY_ENC_OPT_GENEVE_DATA ] = { .type =NLA_BINARY , - .len = 128 }, + .len = 127 }, }; static const struct nla_policy
net/sched/cls_flower.c +1 -1
@@ -723,7 +723,7 @@ geneve_opt_policy[TCA_FLOWER_KEY_ENC_OPT_GENEVE_MAX + 1] = { [TCA_FLOWER_KEY_ENC_OPT_GENEVE_CLASS] = { .type = NLA_U16 }, [TCA_FLOWER_KEY_ENC_OPT_GENEVE_TYPE] = { .type = NLA_U8 }, [TCA_FLOWER_KEY_ENC_OPT_GENEVE_DATA ] = { .type =NLA_BINARY , - .len = 128 }, + .len = 127 }, }; static const struct nla_policy
Signature · 1 line
2.39.5
Greg Kroah-Hartman
maintainerPATCH 250/279 arcnet: Add NULL check in com20020pci_probe()
In reply to Greg Kroah-Hartman5.15-stable review patch. If anyone has any objections, please let me know.
------------------
From: Henry Martin <[email protected]>
[ Upstream commit fda8c491db2a90ff3e6fbbae58e495b4ddddeca3 ]
devm_kasprintf() returns NULL when memory allocation fails. Currently, com20020pci_probe() does not check for this case, which results in a NULL pointer dereference.
Add NULL check after devm_kasprintf() to prevent this issue and ensure no resources are left allocated.
--- drivers/net/arcnet/com20020-pci.c | 17 ++++++++++++++++- 1 file changed, 16 insertions(+), 1 deletion(-)
drivers/net/arcnet/com20020-pci.c +16 -1
@@ -250,18 +250,33 @@ static int com20020pci_probe(struct pci_dev *pdev, card->tx_led.default_trigger =devm_kasprintf (&pdev->dev,GFP_KERNEL ,"arc%d-%d-tx" , dev->dev_id, i); +if (!card->tx_led.default_trigger) { + ret = -ENOMEM ; + goto err_free_arcdev; + } card->tx_led.name =devm_kasprintf (&pdev->dev,GFP_KERNEL ,"pci:green:tx:%d-%d" , dev->dev_id, i); - +if (!card->tx_led.name) { + ret = -ENOMEM ; + goto err_free_arcdev; + } card->tx_led.dev = &dev->dev; card->recon_led.brightness_set = led_recon_set; card->recon_led.default_trigger =devm_kasprintf (&pdev->dev,GFP_KERNEL ,"arc%d-%d-recon" , dev->dev_id, i); +if (!card->recon_led.default_trigger) { + ret = -ENOMEM ; + goto err_free_arcdev; + } card->recon_led.name =devm_kasprintf (&pdev->dev,GFP_KERNEL ,"pci:red:recon:%d-%d" , dev->dev_id, i); +if (!card->recon_led.name) { + ret = -ENOMEM ; + goto err_free_arcdev; + } card->recon_led.dev = &dev->dev; ret =devm_led_classdev_register (&pdev->dev, &card->tx_led);
Signature · 1 line
2.39.5
Greg Kroah-Hartman
maintainerPATCH 251/279 can: flexcan: only change CAN state when link up in system PM
In reply to Greg Kroah-Hartman5.15-stable review patch. If anyone has any objections, please let me know.
------------------
From: Haibo Chen <[email protected]>
[ Upstream commit fd99d6ed20234b83d65b9c5417794343577cf3e5 ]
After a suspend/resume cycle on a down interface, it will come up as ERROR-ACTIVE.
$ ip -details -s -s a s dev flexcan0
3: flexcan0: <NOARP,ECHO> mtu 16 qdisc pfifo_fast state DOWN group default qlen 10
link/can promiscuity 0 allmulti 0 minmtu 0 maxmtu 0
can state STOPPED (berr-counter tx 0 rx 0) restart-ms 1000$ sudo systemctl suspend
$ ip -details -s -s a s dev flexcan0
3: flexcan0: <NOARP,ECHO> mtu 16 qdisc pfifo_fast state DOWN group default qlen 10
link/can promiscuity 0 allmulti 0 minmtu 0 maxmtu 0
can state ERROR-ACTIVE (berr-counter tx 0 rx 0) restart-ms 1000And only set CAN state to CAN_STATE_ERROR_ACTIVE when resume process has no issue, otherwise keep in CAN_STATE_SLEEPING as suspend did.
--- drivers/net/can/flexcan.c | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-)
drivers/net/can/flexcan.c +4 -2
@@ -2343,8 +2343,9 @@ static int __maybe_unused flexcan_suspend(struct device *device) }netif_stop_queue (dev);netif_device_detach (dev); + + priv->can.state =CAN_STATE_SLEEPING ; } - priv->can.state =CAN_STATE_SLEEPING ;return 0 ; }
@@ -2355,7 +2356,6 @@ static int __maybe_unused flexcan_resume(struct device *device)struct flexcan_priv *priv =netdev_priv (dev);int err; - priv->can.state =CAN_STATE_ERROR_ACTIVE ;if (netif_running (dev)) {netif_device_attach (dev);netif_start_queue (dev);
@@ -2375,6 +2375,8 @@ static int __maybe_unused flexcan_resume(struct device *device)flexcan_chip_interrupts_enable (dev); } + + priv->can.state =CAN_STATE_ERROR_ACTIVE ; }return 0 ;
Signature · 1 line
2.39.5
Greg Kroah-Hartman
maintainerPATCH 252/279 can: flexcan: disable transceiver during system PM
In reply to Greg Kroah-Hartman5.15-stable review patch. If anyone has any objections, please let me know.
------------------
From: Haibo Chen <[email protected]>
[ Upstream commit 5a19143124be42900b3fbc9ada3c919632eb45eb ]
During system PM, if no wakeup requirement, disable transceiver to save power.
--- drivers/net/can/flexcan.c | 12 +++++++++++- 1 file changed, 11 insertions(+), 1 deletion(-)
drivers/net/can/flexcan.c +11 -1
@@ -2337,6 +2337,10 @@ static int __maybe_unused flexcan_suspend(struct device *device)flexcan_chip_interrupts_disable (dev); + err =flexcan_transceiver_disable (priv); +if (err) +return err; + err =pinctrl_pm_select_sleep_state (device);if (err)return err;
@@ -2369,10 +2373,16 @@ static int __maybe_unused flexcan_resume(struct device *device)if (err)return err; - err =flexcan_chip_start (dev); + err =flexcan_transceiver_enable (priv);if (err)return err; + err =flexcan_chip_start (dev); +if (err) { +flexcan_transceiver_disable (priv); +return err; + } +flexcan_chip_interrupts_enable (dev); }
Signature · 1 line
2.39.5
Greg Kroah-Hartman
maintainerPATCH 253/279 mmc: sdhci-brcmstb: Add ability to increase max clock rate for 72116b0
In reply to Greg Kroah-Hartman5.15-stable review patch. If anyone has any objections, please let me know.
------------------
From: Kamal Dasu <[email protected]>
[ Upstream commit 97904a59855c7ac7c613085bc6bdc550d48524ff ]
The 72116B0 has improved SDIO controllers that allow the max clock rate to be increased from a max of 100MHz to a max of 150MHz. The driver will need to get the clock and increase it's default rate and override the caps register, that still indicates a max of 100MHz. The new clock will be named "sdio_freq" in the DT node's "clock-names" list. The driver will use a DT property, "clock-frequency", to enable this functionality and will get the actual rate in MHz from the property to allow various speeds to be requested.
Stable-dep-of: 723ef0e20dbb ("mmc: sdhci-brcmstb: add cqhci suspend/resume to PM ops")
--- drivers/mmc/host/sdhci-brcmstb.c | 69 +++++++++++++++++++++++++++++++- 1 file changed, 68 insertions(+), 1 deletion(-)
drivers/mmc/host/sdhci-brcmstb.c +68 -1
@@ -32,6 +32,8 @@struct sdhci_brcmstb_priv {void __iomem *cfg_regs;unsigned int flags; +struct clk *base_clk; +u32 base_freq_hz; };struct brcmstb_match_priv {
@@ -251,9 +253,11 @@ static int sdhci_brcmstb_probe(struct platform_device *pdev)struct sdhci_pltfm_host *pltfm_host;const struct of_device_id *match;struct sdhci_brcmstb_priv *priv; +u32 actual_clock_mhz;struct sdhci_host *host;struct resource *iomem;struct clk *clk; +struct clk *base_clk;int res; match =of_match_node (sdhci_brcm_of_match, pdev->dev.of_node);
@@ -331,6 +335,35 @@ static int sdhci_brcmstb_probe(struct platform_device *pdev)if (match_priv->flags &BRCMSTB_MATCH_FLAGS_BROKEN_TIMEOUT ) host->quirks |=SDHCI_QUIRK_BROKEN_TIMEOUT_VAL ; +/* Change the base clock frequency if the DT property exists */ +if (device_property_read_u32 (&pdev->dev,"clock-frequency" , + &priv->base_freq_hz) !=0 ) + goto add_host; + + base_clk =devm_clk_get_optional (&pdev->dev,"sdio_freq" ); +if (IS_ERR (base_clk)) { +dev_warn (&pdev->dev,"Clock for \"sdio_freq\" not found\n" ); + goto add_host; + } + + res =clk_prepare_enable (base_clk); +if (res) + goto err; + +/* set improved clock rate */ +clk_set_rate (base_clk, priv->base_freq_hz); + actual_clock_mhz =clk_get_rate (base_clk) /1000000 ; + + host->caps &= ~SDHCI_CLOCK_V3_BASE_MASK ; + host->caps |= (actual_clock_mhz <<SDHCI_CLOCK_BASE_SHIFT ); +/* Disable presets because they are now incorrect */ + host->quirks2 |=SDHCI_QUIRK2_PRESET_VALUE_BROKEN ; + +dev_dbg (&pdev->dev,"Base Clock Frequency changed to %dMHz\n" , + actual_clock_mhz); + priv->base_clk = base_clk; + +add_host: res =sdhci_brcmstb_add_host (host, priv);if (res) goto err;
@@ -341,6 +374,7 @@ static int sdhci_brcmstb_probe(struct platform_device *pdev) err:sdhci_pltfm_free (pdev); err_clk: +clk_disable_unprepare (base_clk);clk_disable_unprepare (clk);return res; }
@@ -352,11 +386,44 @@ static void sdhci_brcmstb_shutdown(struct platform_device *pdev)MODULE_DEVICE_TABLE (of, sdhci_brcm_of_match); +#ifdef CONFIG_PM_SLEEP +static int sdhci_brcmstb_suspend (struct device *dev) +{ +struct sdhci_host *host =dev_get_drvdata (dev); +struct sdhci_pltfm_host *pltfm_host =sdhci_priv (host); +struct sdhci_brcmstb_priv *priv =sdhci_pltfm_priv (pltfm_host); + +clk_disable_unprepare (priv->base_clk); +return sdhci_pltfm_suspend (dev); +} + +static int sdhci_brcmstb_resume (struct device *dev) +{ +struct sdhci_host *host =dev_get_drvdata (dev); +struct sdhci_pltfm_host *pltfm_host =sdhci_priv (host); +struct sdhci_brcmstb_priv *priv =sdhci_pltfm_priv (pltfm_host); +int ret; + + ret =sdhci_pltfm_resume (dev); +if (!ret && priv->base_freq_hz) { + ret =clk_prepare_enable (priv->base_clk); +if (!ret) + ret =clk_set_rate (priv->base_clk, priv->base_freq_hz); + } + +return ret; +} +#endif + +static const struct dev_pm_ops sdhci_brcmstb_pmops = { +SET_SYSTEM_SLEEP_PM_OPS (sdhci_brcmstb_suspend, sdhci_brcmstb_resume) +}; +static struct platform_driver sdhci_brcmstb_driver = { .driver = { .name ="sdhci-brcmstb" , .probe_type =PROBE_PREFER_ASYNCHRONOUS , - .pm = &sdhci_pltfm_pmops, + .pm = &sdhci_brcmstb_pmops, .of_match_table =of_match_ptr (sdhci_brcm_of_match), }, .probe = sdhci_brcmstb_probe,
Signature · 1 line
2.39.5
Re: [PATCH 5.15 253/279] mmc: sdhci-brcmstb: Add ability to increase max clock rate for 72116b0
Hi Greg,
Quoted 17 lines · Greg Kroah-Hartman
5.15-stable review patch. If anyone has any objections, please let me know.
------------------
From: Kamal Dasu <[email protected]>
[ Upstream commit
97904a59855c7ac7c613085bc6bdc550d48524ff]The 72116B0 has improved SDIO controllers that allow the max clock rate to be increased from a max of 100MHz to a max of 150MHz. The driver will need to get the clock and increase it's default rate and override the caps register, that still indicates a max of 100MHz. The new clock will be named "
sdio_freq" in the DT node's "clock-names" list. The driver will use a DT property, "clock-frequency", to enable this functionality and will get the actual rate in MHz from the property to allow various speeds to be requested.
Quoted 7 lines
Signed-off-by Al Cooper <[email protected]>Signed-off-by Kamal Dasu <[email protected]>Acked-by Florian Fainelli <[email protected]>Signed-off-by Ulf Hansson <[email protected]>Stable-dep-of:
723ef0e20dbb("mmc: sdhci-brcmstb: add cqhci suspend/resume to PM ops")Signed-off-by Sasha Levin <[email protected]>
This change needs a fix for a clang -Wsometimes-uninitialized warning, commit c3c0ed75ffbf ("mmc: sdhci-brcmstb: Initialize base_clk to NULL in sdhci_brcmstb_probe()"), as pointed out by KernelCI.
https://lore.kernel.org/CACo-S-297JUFPCNaeSoA0WHSP=sC+QquSZaX=rQto=JZzi1PUA@mail.gmail.com/
Not exactly your fault, I had a Fixes tag on the original patch but it seems like it got stripped during application :/
https://lore.kernel.org/[email protected]/
Cheers,
Nathan
Greg Kroah-Hartman
maintainerRe: [PATCH 5.15 253/279] mmc: sdhci-brcmstb: Add ability to increase max clock rate for 72116b0
Quoted 32 lines · Nathan Chancellor
Hi Greg,
Quoted 17 lines · Greg Kroah-Hartman
5.15-stable review patch. If anyone has any objections, please let me know.
------------------
From: Kamal Dasu <[email protected]>
[ Upstream commit
97904a59855c7ac7c613085bc6bdc550d48524ff]The 72116B0 has improved SDIO controllers that allow the max clock rate to be increased from a max of 100MHz to a max of 150MHz. The driver will need to get the clock and increase it's default rate and override the caps register, that still indicates a max of 100MHz. The new clock will be named "
sdio_freq" in the DT node's "clock-names" list. The driver will use a DT property, "clock-frequency", to enable this functionality and will get the actual rate in MHz from the property to allow various speeds to be requested.Quoted 7 lines
Signed-off-by Al Cooper <[email protected]>Signed-off-by Kamal Dasu <[email protected]>Acked-by Florian Fainelli <[email protected]>Signed-off-by Ulf Hansson <[email protected]>Stable-dep-of:
723ef0e20dbb("mmc: sdhci-brcmstb: add cqhci suspend/resume to PM ops")Signed-off-by Sasha Levin <[email protected]>This change needs a fix for a clang -Wsometimes-uninitialized warning, commit
c3c0ed75ffbf("mmc: sdhci-brcmstb: Initializebase_clkto NULL insdhci_brcmstb_probe()"), as pointed out by KernelCI.
Quoted 6 lines
https://lore.kernel.org/CACo-S-297JUFPCNaeSoA0WHSP=sC+QquSZaX=rQto=JZzi1PUA@mail.gmail.com/
Not exactly your fault, I had a Fixes tag on the original patch but it seems like it got stripped during application :/
Thanks, I'll go queue that up now.
greg k-h
Greg Kroah-Hartman
maintainerPATCH 254/279 mmc: sdhci-brcmstb: add cqhci suspend/resume to PM ops
In reply to Greg Kroah-Hartman5.15-stable review patch. If anyone has any objections, please let me know.
------------------
From: Kamal Dasu <[email protected]>
[ Upstream commit 723ef0e20dbb2aa1b5406d2bb75374fc48187daa ]
cqhci timeouts observed on brcmstb platforms during suspend:
...
[ 164.832853] mmc0: cqhci: timeout for tag 18 ...
Adding cqhci_suspend()/resume() calls to disable cqe in sdhci_brcmstb_suspend()/resume() respectively to fix CQE timeouts seen on PM suspend.
--- drivers/mmc/host/sdhci-brcmstb.c | 10 ++++++++++ 1 file changed, 10 insertions(+)
drivers/mmc/host/sdhci-brcmstb.c +10 -0
@@ -392,8 +392,15 @@ static int sdhci_brcmstb_suspend(struct device *dev)struct sdhci_host *host =dev_get_drvdata (dev);struct sdhci_pltfm_host *pltfm_host =sdhci_priv (host);struct sdhci_brcmstb_priv *priv =sdhci_pltfm_priv (pltfm_host); +int ret;clk_disable_unprepare (priv->base_clk); +if (host->mmc->caps2 &MMC_CAP2_CQE ) { + ret =cqhci_suspend (host->mmc); +if (ret) +return ret; + } +return sdhci_pltfm_suspend (dev); }
@@ -411,6 +418,9 @@ static int sdhci_brcmstb_resume(struct device *dev) ret = clk_set_rate(priv->base_clk, priv->base_freq_hz); } +if (host->mmc->caps2 &MMC_CAP2_CQE ) + ret =cqhci_resume (host->mmc); +return ret; }#endif
Signature · 1 line
2.39.5
Greg Kroah-Hartman
maintainerPATCH 255/279 tty: serial: fsl_lpuart: use UARTMODIR register bits for lpuart32 platform
In reply to Greg Kroah-Hartman5.15-stable review patch. If anyone has any objections, please let me know.
------------------
From: Sherry Sun <[email protected]>
[ Upstream commit d57d56e4dddfb5c92cd81abf8922055bf0fb85a4 ]
For lpuart32 platforms, UARTMODIR register is used instead of UARTMODEM. So here should configure the corresponding UARTMODIR register bits to avoid confusion.
Stable-dep-of: f5cb528d6441 ("tty: serial: fsl_lpuart: disable transmitter before changing RS485 related registers")
--- drivers/tty/serial/fsl_lpuart.c | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-)
drivers/tty/serial/fsl_lpuart.c +4 -4
@@ -1396,7 +1396,7 @@ static int lpuart32_config_rs485(struct uart_port *port, struct lpuart_port, port);unsigned long modem =lpuart32_read (&sport->port,UARTMODIR ) - & ~(UARTMODEM_TXRTSPOL |UARTMODEM_TXRTSE ); + & ~(UARTMODIR_TXRTSPOL |UARTMODIR_TXRTSE );lpuart32_write (&sport->port, modem,UARTMODIR );/* clear unsupported configurations */
@@ -1406,7 +1406,7 @@ static int lpuart32_config_rs485(struct uart_port *port,if (rs485->flags &SER_RS485_ENABLED ) {/* Enable auto RS-485 RTS mode */ - modem |=UARTMODEM_TXRTSE ; + modem |=UARTMODIR_TXRTSE ;/* * RTS needs to be logic HIGH either during transfer _or_ after
@@ -1428,9 +1428,9 @@ static int lpuart32_config_rs485(struct uart_port *port,* Note: UART is assumed to be active high. */ if (rs485->flags &SER_RS485_RTS_ON_SEND ) - modem |=UARTMODEM_TXRTSPOL ; + modem |=UARTMODIR_TXRTSPOL ;else if (rs485->flags &SER_RS485_RTS_AFTER_SEND ) - modem &= ~UARTMODEM_TXRTSPOL ; + modem &= ~UARTMODIR_TXRTSPOL ; }/* Store the new configuration */
Signature · 1 line
2.39.5
Greg Kroah-Hartman
maintainerPATCH 256/279 tty: serial: fsl_lpuart: disable transmitter before changing RS485 related registers
In reply to Greg Kroah-Hartman5.15-stable review patch. If anyone has any objections, please let me know.
------------------
From: Sherry Sun <[email protected]>
[ Upstream commit f5cb528d6441eb860250a2f085773aac4f44085e ]
According to the LPUART reference manual, TXRTSE and TXRTSPOL of MODIR register only can be changed when the transmitter is disabled. So disable the transmitter before changing RS485 related registers and re-enable it after the change is done.
--- drivers/tty/serial/fsl_lpuart.c | 17 +++++++++++++++++ 1 file changed, 17 insertions(+)
drivers/tty/serial/fsl_lpuart.c +17 -0
@@ -1397,6 +1397,19 @@ static int lpuart32_config_rs485(struct uart_port *port,unsigned long modem =lpuart32_read (&sport->port,UARTMODIR ) & ~(UARTMODIR_TXRTSPOL |UARTMODIR_TXRTSE ); +u32 ctrl; + +/* TXRTSE and TXRTSPOL only can be changed when transmitter is disabled. */ + ctrl =lpuart32_read (&sport->port,UARTCTRL ); +if (ctrl &UARTCTRL_TE ) { +/* wait for the transmit engine to complete */ +lpuart32_wait_bit_set (&sport->port,UARTSTAT ,UARTSTAT_TC ); +lpuart32_write (&sport->port, ctrl & ~UARTCTRL_TE ,UARTCTRL ); + +while (lpuart32_read (&sport->port,UARTCTRL ) &UARTCTRL_TE ) +cpu_relax (); + } +lpuart32_write (&sport->port, modem,UARTMODIR );/* clear unsupported configurations */
@@ -1437,6 +1450,10 @@ static int lpuart32_config_rs485(struct uart_port *port, sport->port.rs485 = *rs485;lpuart32_write (&sport->port, modem,UARTMODIR ); + +if (ctrl &UARTCTRL_TE ) +lpuart32_write (&sport->port, ctrl,UARTCTRL ); +return 0 ; }
Signature · 1 line
2.39.5
Greg Kroah-Hartman
maintainerPATCH 257/279 drm/amd/pm: Fix negative array index read
In reply to Greg Kroah-Hartman5.15-stable review patch. If anyone has any objections, please let me know.
------------------
From: Jesse Zhang <[email protected]>
commit c8c19ebf7c0b202a6a2d37a52ca112432723db5f upstream.
Avoid using the negative values
for clk_idex as an index into an array pptable->DpmDescriptor.
V2: fix clk_index return check (Tim Huang)
--- drivers/gpu/drm/amd/pm/swsmu/smu11/navi10_ppt.c | 21 ++++++++++++++++----- 1 file changed, 16 insertions(+), 5 deletions(-)
drivers/gpu/drm/amd/pm/swsmu/smu11/navi10_ppt.c +16 -5
@@ -1231,19 +1231,22 @@ static int navi10_get_current_clk_freq_b value); } -static bool navi10_is_support_fine_grained_dpm (struct smu_context *smu,enum smu_clk_type clk_type) +static int navi10_is_support_fine_grained_dpm (struct smu_context *smu,enum smu_clk_type clk_type) {PPTable_t *pptable = smu->smu_table.driver_pptable;DpmDescriptor_t *dpm_desc =NULL ; -uint32_t clk_index =0 ; +int clk_index =0 ; clk_index =smu_cmn_to_asic_specific_index (smu,CMN2ASIC_MAPPING_CLK , clk_type); +if (clk_index <0 ) +return clk_index; + dpm_desc = &pptable->DpmDescriptor[clk_index];/* 0 - Fine grained DPM, 1 - Discrete DPM */ -return dpm_desc->SnapToDiscrete ==0 ; +return dpm_desc->SnapToDiscrete ==0 ?1 :0 ; }static inline bool navi10_od_feature_is_supported (struct smu_11_0_overdrive_table *od_table,enum SMU_11_0_ODFEATURE_CAP cap)
@@ -1299,7 +1302,11 @@ static int navi10_print_clk_levels(strucif (ret)return size; -if (!navi10_is_support_fine_grained_dpm (smu, clk_type)) { + ret =navi10_is_support_fine_grained_dpm (smu, clk_type); +if (ret <0 ) +return ret; + +if (!ret) {for (i =0 ; i < count; i++) { ret =smu_v11_0_get_dpm_freq_by_index (smu, clk_type, i, &value);if (ret)
@@ -1468,7 +1475,11 @@ static int navi10_force_clk_levels(struccase SMU_UCLK :case SMU_FCLK :/* There is only 2 levels for fine grained DPM */ -if (navi10_is_support_fine_grained_dpm (smu, clk_type)) { + ret =navi10_is_support_fine_grained_dpm (smu, clk_type); +if (ret <0 ) +return ret; + +if (ret) { soft_max_level = (soft_max_level >=1 ?1 :0 ); soft_min_level = (soft_min_level >=1 ?1 :0 ); }
Greg Kroah-Hartman
maintainerPATCH 258/279 drm/amd/display: Skip inactive planes within ModeSupportAndSystemConfiguration
In reply to Greg Kroah-Hartman5.15-stable review patch. If anyone has any objections, please let me know.
------------------
From: Hersen Wu <[email protected]>
commit a54f7e866cc73a4cb71b8b24bb568ba35c8969df upstream.
[Why]
Coverity reports Memory - illegal accesses.
[How]
Skip inactive planes.
[get_pipe_idx() was introduced as a helper by dda4fb85e433 ("drm/amd/display: DML changes for DCN32/321") in v6.0. This patch backports it to make code clearer. And minor conflict is resolved due to code context change.]
--- drivers/gpu/drm/amd/display/dc/dml/display_mode_vba.c | 24 ++++++++++++++++++ 1 file changed, 24 insertions(+)
drivers/gpu/drm/amd/display/dc/dml/display_mode_vba.c +24 -0
@@ -867,11 +867,30 @@ static unsigned int CursorBppEnumToBits( } } +static unsigned int get_pipe_idx (struct display_mode_lib *mode_lib,unsigned int plane_idx) +{ +int pipe_idx =-1 ; +int i; + +ASSERT (plane_idx <DC__NUM_DPP__MAX ); + +for (i =0 ; i <DC__NUM_DPP__MAX ; i++) { +if (plane_idx == mode_lib->vba.pipe_plane[i]) { + pipe_idx = i; +break ; + } + } +ASSERT (pipe_idx >=0 ); + +return pipe_idx; +} +void ModeSupportAndSystemConfiguration (struct display_mode_lib *mode_lib) {soc_bounding_box_st *soc = &mode_lib->vba.soc;unsigned int k;unsigned int total_pipes =0 ; +unsigned int pipe_idx =0 ; mode_lib->vba.VoltageLevel = mode_lib->vba.cache_pipes[0 ].clks_cfg.voltage; mode_lib->vba.ReturnBW = mode_lib->vba.ReturnBWPerState[mode_lib->vba.VoltageLevel][mode_lib->vba.maxMpcComb];
@@ -892,6 +911,11 @@ void ModeSupportAndSystemConfiguration(s// Total Available Pipes Support Check for (k =0 ; k < mode_lib->vba.NumberOfActivePlanes; ++k) { + pipe_idx =get_pipe_idx (mode_lib, k); +if (pipe_idx ==-1 ) { +ASSERT (0 ); +continue ;// skip inactive planes + } total_pipes += mode_lib->vba.DPPPerPlane[k]; }ASSERT (total_pipes <=DC__NUM_DPP__MAX );
Greg Kroah-Hartman
maintainerPATCH 259/279 usbnet:fix NPE during rx_complete
In reply to Greg Kroah-Hartman5.15-stable review patch. If anyone has any objections, please let me know.
------------------
From: Ying Lu <[email protected]>
commit 51de3600093429e3b712e5f091d767babc5dd6df upstream.
Missing usbnet_going_away Check in Critical Path. The usb_submit_urb function lacks a usbnet_going_away validation, whereas __usbnet_queue_skb includes this check.
This inconsistency creates a race condition where:
A URB request may succeed, but the corresponding SKB data fails to be queued.
Subsequent processes:
(e.g., rx_complete → defer_bh → __skb_unlink(skb, list)) attempt to access skb->next, triggering a NULL pointer dereference (Kernel Panic).
--- drivers/net/usb/usbnet.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-)
drivers/net/usb/usbnet.c +3 -3
@@ -533,7 +533,8 @@ static int rx_submit (struct usbnet *devnetif_device_present (dev->net) &&test_bit (EVENT_DEV_OPEN , &dev->flags) && !test_bit (EVENT_RX_HALT , &dev->flags) && - !test_bit (EVENT_DEV_ASLEEP, &dev->flags)) { + !test_bit (EVENT_DEV_ASLEEP , &dev->flags) && + !usbnet_going_away(dev)) { switch (retval = usb_submit_urb (urb, GFP_ATOMIC)) {case -EPIPE :usbnet_defer_kevent (dev,EVENT_RX_HALT );
@@ -554,8 +555,7 @@ static int rx_submit (struct usbnet *devtasklet_schedule (&dev->bh);break ;case 0 : -if (!usbnet_going_away (dev)) -__usbnet_queue_skb (&dev->rxq, skb, rx_start); +__usbnet_queue_skb (&dev->rxq, skb, rx_start); } }else {netif_dbg (dev, ifdown, dev->net,"rx: stopped\n" );
Greg Kroah-Hartman
maintainerPATCH 260/279 platform/x86: ISST: Correct command storage data length
In reply to Greg Kroah-Hartman5.15-stable review patch. If anyone has any objections, please let me know.
------------------
From: Srinivas Pandruvada <[email protected]>
commit 9462e74c5c983cce34019bfb27f734552bebe59f upstream.
After resume/online turbo limit ratio (TRL) is restored partially if the admin explicitly changed TRL from user space.
A hash table is used to store SST mail box and MSR settings when modified to restore those settings after resume or online. This uses a struct isst_cmd field "data" to store these settings. This is a 64 bit field. But isst_store_new_cmd() is only assigning as u32. This results in truncation of 32 bits.
Change the argument to u64 from u32.
--- drivers/platform/x86/intel/speed_select_if/isst_if_common.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/platform/x86/intel/speed_select_if/isst_if_common.c +1 -1
@@ -77,7 +77,7 @@ static DECLARE_HASHTABLE(isst_hash, 8);static DEFINE_MUTEX (isst_hash_lock);static int isst_store_new_cmd (int cmd,u32 cpu,int mbox_cmd_type,u32 param, -u32 data) +u64 data) {struct isst_cmd *sst_cmd;
Greg Kroah-Hartman
maintainerPATCH 261/279 ntb_perf: Delete duplicate dmaengine_unmap_put() call in perf_copy_chunk()
In reply to Greg Kroah-Hartman5.15-stable review patch. If anyone has any objections, please let me know.
------------------
From: Markus Elfring <[email protected]>
commit 4279e72cab31dd3eb8c89591eb9d2affa90ab6aa upstream.
The function call “dmaengine_unmap_put(unmap)” was used in an if branch. The same call was immediately triggered by a subsequent goto statement. Thus avoid such a call repetition.
This issue was detected by using the Coccinelle software.
--- drivers/ntb/test/ntb_perf.c | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-)
drivers/ntb/test/ntb_perf.c +1 -3
@@ -839,10 +839,8 @@ static int perf_copy_chunk(struct perf_tdma_set_unmap (tx, unmap); ret =dma_submit_error (dmaengine_submit (tx)); -if (ret) { -dmaengine_unmap_put (unmap); +if (ret) goto err_free_resource; - }dmaengine_unmap_put (unmap);
Greg Kroah-Hartman
maintainerPATCH 262/279 btrfs: handle errors from btrfs_dec_ref() properly
In reply to Greg Kroah-Hartman5.15-stable review patch. If anyone has any objections, please let me know.
------------------
From: Josef Bacik <[email protected]>
commit 5eb178f373b4f16f3b42d55ff88fc94dd95b93b1 upstream.
In walk_up_proc() we BUG_ON(ret) from btrfs_dec_ref(). This is incorrect, we have proper error handling here, return the error.
--- fs/btrfs/extent-tree.c | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-)
fs/btrfs/extent-tree.c +4 -1
@@ -5461,7 +5461,10 @@ static noinline int walk_up_proc(struct ret =btrfs_dec_ref (trans, root, eb,1 ); else ret =btrfs_dec_ref (trans, root, eb,0 ); -BUG_ON (ret);/* -ENOMEM */ +if (ret) { +btrfs_abort_transaction (trans, ret); +return ret; + }if (is_fstree (root->root_key.objectid)) { ret =btrfs_qgroup_trace_leaf_items (trans, eb);if (ret) {
Greg Kroah-Hartman
maintainerPATCH 263/279 x86/tsc: Always save/restore TSC sched_clock() on suspend/resume
In reply to Greg Kroah-Hartman5.15-stable review patch. If anyone has any objections, please let me know.
------------------
From: Guilherme G. Piccoli <[email protected]>
commit d90c9de9de2f1712df56de6e4f7d6982d358cabe upstream.
TSC could be reset in deep ACPI sleep states, even with invariant TSC.
That's the reason we have sched_clock() save/restore functions, to deal with this situation. But what happens is that such functions are guarded with a check for the stability of sched_clock - if not considered stable, the save/restore routines aren't executed.
On top of that, we have a clear comment in native_sched_clock() saying that *even* with TSC unstable, we continue using TSC for sched_clock due to its speed.
In other words, if we have a situation of TSC getting detected as unstable, it marks the sched_clock as unstable as well, so subsequent S3 sleep cycles could bring bogus sched_clock values due to the lack of the save/restore mechanism, causing warnings like this:
[22.954918] ------------[ cut here ]------------ [22.954923] Delta way too big! 18446743750843854390 ts=18446744072977390405 before=322133536015 after=322133536015 write stamp=18446744072977390405 [22.954923] If you just came from a suspend/resume, [22.954923] please switch to the trace global clock: [22.954923] echo global > /sys/kernel/tracing/trace_clock [22.954923] or add trace_clock=global to the kernel command line [22.954937] WARNING: CPU: 2 PID: 5728 at kernel/trace/ring_buffer.c:2890 rb_add_timestamp+0x193/0x1c0
Notice that the above was reproduced even with "trace_clock=global".
The fix for that is to _always_ save/restore the sched_clock on suspend cycle _if TSC is used_ as sched_clock - only if we fallback to jiffies the sched_clock_stable() check becomes relevant to save/restore the sched_clock.
--- arch/x86/kernel/tsc.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
arch/x86/kernel/tsc.c +2 -2
@@ -920,7 +920,7 @@ static unsigned long long cyc2ns_suspendvoid tsc_save_sched_clock_state (void ) { -if (!sched_clock_stable ()) +if (!static_branch_likely (&__use_tsc) && !sched_clock_stable ())return ; cyc2ns_suspend =sched_clock ();
@@ -940,7 +940,7 @@ void tsc_restore_sched_clock_state(void)unsigned long flags;int cpu; -if (!sched_clock_stable ()) +if (!static_branch_likely (&__use_tsc) && !sched_clock_stable ())return ;local_irq_save (flags);
Greg Kroah-Hartman
maintainerPATCH 264/279 x86/mm: Fix flush_tlb_range() when used for zapping normal PMDs
In reply to Greg Kroah-Hartman5.15-stable review patch. If anyone has any objections, please let me know.
------------------
From: Jann Horn <[email protected]>
commit 3ef938c3503563bfc2ac15083557f880d29c2e64 upstream.
On the following path, flush_tlb_range() can be used for zapping normal PMD entries (PMD entries that point to page tables) together with the PTE entries in the pointed-to page table:
collapse_pte_mapped_thp
pmdp_collapse_flush
flush_tlb_range
The arm64 version of flush_tlb_range() has a comment describing that it can be used for page table removal, and does not use any last-level invalidation optimizations. Fix the X86 version by making it behave the same way.
Currently, X86 only uses this information for the following two purposes, which I think means the issue doesn't have much impact:
- In native_flush_tlb_multi() for checking if lazy TLB CPUs need to be IPI'd to avoid issues with speculative page table walks.
- In Hyper-V TLB paravirtualization, again for lazy TLB stuff.
The patch "x86/mm: only invalidate final translations with INVLPGB" which is currently under review (see
<https://lore.kernel.org/all/[email protected]/>)
would probably be making the impact of this a lot worse.
--- arch/x86/include/asm/tlbflush.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
arch/x86/include/asm/tlbflush.h +1 -1
@@ -227,7 +227,7 @@ void flush_tlb_multi(const struct cpumasflush_tlb_mm_range ((vma)->vm_mm, start, end, \ ((vma)->vm_flags &VM_HUGETLB ) \ ?huge_page_shift (hstate_vma (vma)) \ - : PAGE_SHIFT, false) + : PAGE_SHIFT, true)extern void flush_tlb_all (void ); extern void flush_tlb_mm_range(struct mm_struct *mm, unsigned long start,
Greg Kroah-Hartman
maintainerPATCH 265/279 acpi: nfit: fix narrowing conversion in acpi_nfit_ctl
In reply to Greg Kroah-Hartman5.15-stable review patch. If anyone has any objections, please let me know.
------------------
From: Murad Masimov <[email protected]>
commit 2ff0e408db36c21ed3fa5e3c1e0e687c82cf132f upstream.
Syzkaller has reported a warning in to_nfit_bus_uuid(): "only secondary bus families can be translated". This warning is emited if the argument is equal to NVDIMM_BUS_FAMILY_NFIT == 0. Function acpi_nfit_ctl() first verifies that a user-provided value call_pkg->nd_family of type u64 is not equal to 0. Then the value is converted to int, and only after that is compared to NVDIMM_BUS_FAMILY_MAX. This can lead to passing an invalid argument to acpi_nfit_ctl(), if call_pkg->nd_family is non-zero, while the lower 32 bits are zero.
Furthermore, it is best to return EINVAL immediately upon seeing the invalid user input. The WARNING is insufficient to prevent further undefined behavior based on other invalid user input.
All checks of the input value should be applied to the original variable call_pkg->nd_family.
[iweiny: update commit message]
--- drivers/acpi/nfit/core.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/acpi/nfit/core.c +1 -1
@@ -485,7 +485,7 @@ int acpi_nfit_ctl(struct nvdimm_bus_desc cmd_mask = nd_desc->cmd_mask;if (cmd ==ND_CMD_CALL && call_pkg->nd_family) { family = call_pkg->nd_family; -if (family >NVDIMM_BUS_FAMILY_MAX || +if (call_pkg->nd_family >NVDIMM_BUS_FAMILY_MAX || !test_bit (family, &nd_desc->bus_family_mask))return -EINVAL ; family = array_index_nospec(family,
Greg Kroah-Hartman
maintainerPATCH 266/279 ACPI: resource: Skip IRQ override on ASUS Vivobook 14 X1404VAP
In reply to Greg Kroah-Hartman5.15-stable review patch. If anyone has any objections, please let me know.
------------------
From: Paul Menzel <[email protected]>
commit 2da31ea2a085cd189857f2db0f7b78d0162db87a upstream.
Like the ASUS Vivobook X1504VAP and Vivobook X1704VAP, the ASUS Vivobook 14 X1404VAP has its keyboard IRQ (1) described as ActiveLow in the DSDT, which the kernel overrides to EdgeHigh breaking the keyboard.
$ sudo dmidecode
[…]
System Information
Manufacturer: ASUSTeK COMPUTER INC.
Product Name: ASUS Vivobook 14 X1404VAP_X1404VA
[…]
$ grep -A 30 PS2K dsdt.dsl | grep IRQ -A 1
IRQ (Level, ActiveLow, Exclusive, )
{1}Add the X1404VAP to the irq1_level_low_skip_override[] quirk table to fix this.
--- drivers/acpi/resource.c | 7 +++++++ 1 file changed, 7 insertions(+)
drivers/acpi/resource.c +7 -0
@@ -443,6 +443,13 @@ static const struct dmi_system_id asus_l }, }, { +/* Asus Vivobook X1404VAP */ + .matches = { +DMI_MATCH (DMI_SYS_VENDOR ,"ASUSTeK COMPUTER INC." ), + DMI_MATCH(DMI_BOARD_NAME, "X1404VAP"), + }, + }, + {/* Asus Vivobook X1504VAP */ .matches = { DMI_MATCH(DMI_SYS_VENDOR, "ASUSTeK COMPUTER INC."),
Greg Kroah-Hartman
maintainerPATCH 267/279 mmc: sdhci-pxav3: set NEED_RSP_BUSY capability
In reply to Greg Kroah-Hartman5.15-stable review patch. If anyone has any objections, please let me know.
------------------
From: Karel Balej <[email protected]>
commit a41fcca4b342811b473bbaa4b44f1d34d87fcce6 upstream.
Set the MMC_CAP_NEED_RSP_BUSY capability for the sdhci-pxav3 host to prevent conversion of R1B responses to R1. Without this, the eMMC card in the samsung,coreprimevelte smartphone using the Marvell PXA1908 SoC with this mmc host doesn't probe with the ETIMEDOUT error originating in __mmc_poll_for_busy.
Note that the other issues reported for this phone and host, namely floods of "Tuning failed, falling back to fixed sampling clock" dmesg messages for the eMMC and unstable SDIO are not mitigated by this change.
--- drivers/mmc/host/sdhci-pxav3.c | 1 + 1 file changed, 1 insertion(+)
drivers/mmc/host/sdhci-pxav3.c +1 -0
@@ -401,6 +401,7 @@ static int sdhci_pxav3_probe(struct platif (!IS_ERR (pxa->clk_core))clk_prepare_enable (pxa->clk_core); + host->mmc->caps |=MMC_CAP_NEED_RSP_BUSY ;/* enable 1/8V DDR capable */ host->mmc->caps |=MMC_CAP_1_8V_DDR ;
Greg Kroah-Hartman
maintainerPATCH 268/279 tracing: Fix use-after-free in print_graph_function_flags during tracer switching
In reply to Greg Kroah-Hartman5.15-stable review patch. If anyone has any objections, please let me know.
------------------
From: Tengda Wu <[email protected]>
commit 7f81f27b1093e4895e87b74143c59c055c3b1906 upstream.
Kairui reported a UAF issue in print_graph_function_flags() during ftrace stress testing [1]. This issue can be reproduced if puting a 'mdelay(10)' after 'mutex_unlock(&trace_types_lock)' in s_start(), and executing the following script:
$ echo function_graph > current_tracer $ cat trace > /dev/null & $ sleep 5 # Ensure the 'cat' reaches the 'mdelay(10)' point $ echo timerlat > current_tracer
The root cause lies in the two calls to print_graph_function_flags within print_trace_line during each s_show():
* One through 'iter->trace->print_line()';
* Another through 'event->funcs->trace()', which is hidden in print_trace_fmt() before print_trace_line returns.
Tracer switching only updates the former, while the latter continues to use the print_line function of the old tracer, which in the script above is print_graph_function_flags.
Moreover, when switching from the 'function_graph' tracer to the 'timerlat' tracer, s_start only calls graph_trace_close of the 'function_graph' tracer to free 'iter->private', but does not set it to NULL. This provides an opportunity for 'event->funcs->trace()' to use an invalid 'iter->private'.
To fix this issue, set 'iter->private' to NULL immediately after freeing it in graph_trace_close(), ensuring that an invalid pointer is not passed to other tracers. Additionally, clean up the unnecessary 'iter->private = NULL' during each 'cat trace' when using wakeup and irqsoff tracers.
[1] https://lore.kernel.org/all/[email protected]/
--- kernel/trace/trace_functions_graph.c | 1 + kernel/trace/trace_irqsoff.c | 2 -- kernel/trace/trace_sched_wakeup.c | 2 -- 3 files changed, 1 insertion(+), 4 deletions(-)
kernel/trace/trace_functions_graph.c +1 -0
@@ -1244,6 +1244,7 @@ void graph_trace_close(struct trace_iterif (data) {free_percpu (data->cpu_data);kfree (data); + iter->private =NULL ; } }
kernel/trace/trace_irqsoff.c +0 -2
@@ -231,8 +231,6 @@ static void irqsoff_trace_open(struct tr {if (is_graph (iter->tr))graph_trace_open (iter); -else - iter->private =NULL ; }static void irqsoff_trace_close (struct trace_iterator *iter)
kernel/trace/trace_sched_wakeup.c +0 -2
@@ -168,8 +168,6 @@ static void wakeup_trace_open(struct tra {if (is_graph (iter->tr))graph_trace_open (iter); -else - iter->private =NULL ; }static void wakeup_trace_close (struct trace_iterator *iter)
Greg Kroah-Hartman
maintainerPATCH 269/279 tracing: Ensure module defining synth event cannot be unloaded while tracing
In reply to Greg Kroah-Hartman5.15-stable review patch. If anyone has any objections, please let me know.
------------------
From: Douglas Raillard <[email protected]>
commit 21581dd4e7ff6c07d0ab577e3c32b13a74b31522 upstream.
Currently, using synth_event_delete() will fail if the event is being used (tracing in progress), but that is normally done in the module exit function. At that stage, failing is problematic as returning a non-zero status means the module will become locked (impossible to unload or reload again).
Instead, ensure the module exit function does not get called in the first place by increasing the module refcnt when the event is enabled.
--- kernel/trace/trace_events_synth.c | 31 ++++++++++++++++++++++++++++++- 1 file changed, 30 insertions(+), 1 deletion(-)
kernel/trace/trace_events_synth.c +30 -1
@@ -856,6 +856,35 @@ static struct trace_event_fields synth_e {} }; +static int synth_event_reg (struct trace_event_call *call, +enum trace_reg type,void *data) +{ + struct synth_event *event = container_of(call, struct synth_event, call); +int ret; + +switch (type) { +case TRACE_REG_REGISTER : +case TRACE_REG_PERF_REGISTER : +if (!try_module_get (event->mod)) +return -EBUSY ; +break ; +default : +break ; + } + + ret =trace_event_reg (call, type, data); + +switch (type) { +case TRACE_REG_UNREGISTER : +case TRACE_REG_PERF_UNREGISTER : +module_put (event->mod); +break ; +default : +break ; + } +return ret; +} +static int register_synth_event (struct synth_event *event) {struct trace_event_call *call = &event->call;
@@ -885,7 +914,7 @@ static int register_synth_event(struct s goto out; } call->flags =TRACE_EVENT_FL_TRACEPOINT ; - call->class->reg = trace_event_reg; + call->class->reg = synth_event_reg; call->class->probe = trace_event_raw_event_synth; call->data = event; call->tp = event->tp;
Greg Kroah-Hartman
maintainerPATCH 270/279 tracing: Fix synth event printk format for str fields
In reply to Greg Kroah-Hartman5.15-stable review patch. If anyone has any objections, please let me know.
------------------
From: Douglas Raillard <[email protected]>
commit 4d38328eb442dc06aec4350fd9594ffa6488af02 upstream.
The printk format for synth event uses "%.*s" to print string fields, but then only passes the pointer part as var arg.
Replace %.*s with %s as the C string is guaranteed to be null-terminated.
The output in print fmt should never have been updated as __get_str() handles the string limit because it can access the length of the string in the string meta data that is saved in the ring buffer.
--- kernel/trace/trace_events_synth.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
kernel/trace/trace_events_synth.c +1 -1
@@ -293,7 +293,7 @@ static const char *synth_field_fmt(charelse if (strcmp (type,"gfp_t" ) ==0 ) fmt ="%x" ;else if (synth_field_is_string (type)) - fmt ="%.*s" ; + fmt ="%s" ;else if (synth_field_is_stack (type)) fmt ="%s" ;
Greg Kroah-Hartman
maintainerPATCH 271/279 tracing/osnoise: Fix possible recursive locking for cpus_read_lock()
In reply to Greg Kroah-Hartman5.15-stable review patch. If anyone has any objections, please let me know.
------------------
From: Ran Xiaokai <[email protected]>
commit 7e6b3fcc9c5294aeafed0dbe1a09a1bc899bd0f2 upstream.
Lockdep reports this deadlock log:
osnoise: could not start sampling thread
============================================
WARNING: possible recursive locking detected
--------------------------------------------
CPU0
---- lock(cpu_hotplug_lock);
lock(cpu_hotplug_lock);
Call Trace: <TASK> print_deadlock_bug+0x282/0x3c0 __lock_acquire+0x1610/0x29a0 lock_acquire+0xcb/0x2d0 cpus_read_lock+0x49/0x120 stop_per_cpu_kthreads+0x7/0x60 start_kthread+0x103/0x120 osnoise_hotplug_workfn+0x5e/0x90 process_one_work+0x44f/0xb30 worker_thread+0x33e/0x5e0 kthread+0x206/0x3b0 ret_from_fork+0x31/0x50 ret_from_fork_asm+0x11/0x20 </TASK>
This is the deadlock scenario:osnoise_hotplug_workfn()
guard(cpus_read_lock)(); // first lock call
start_kthread(cpu)
if (IS_ERR(kthread)) {
stop_per_cpu_kthreads(); {
cpus_read_lock(); // second lock call. Cause the AA deadlock
}
}It is not necessary to call stop_per_cpu_kthreads() which stops osnoise kthread for every other CPUs in the system if a failure occurs during hotplug of a certain CPU.
For start_per_cpu_kthreads(), if the start_kthread() call fails, this function calls stop_per_cpu_kthreads() to handle the error. Therefore, similarly, there is no need to call stop_per_cpu_kthreads() again within start_kthread().
So just remove stop_per_cpu_kthreads() from start_kthread to solve this issue.
--- kernel/trace/trace_osnoise.c | 1 - 1 file changed, 1 deletion(-)
kernel/trace/trace_osnoise.c +0 -1
@@ -1560,7 +1560,6 @@ static int start_kthread(unsigned int cpif (IS_ERR (kthread)) {pr_err (BANNER "could not start sampling thread\n" ); -stop_per_cpu_kthreads ();return -ENOMEM ; }
Greg Kroah-Hartman
maintainerPATCH 272/279 ext4: dont over-report free space or inodes in statvfs
In reply to Greg Kroah-Hartman5.15-stable review patch. If anyone has any objections, please let me know.
------------------
From: Theodore Ts'o <[email protected]>
commit f87d3af7419307ae26e705a2b2db36140db367a2 upstream.
This fixes an analogus bug that was fixed in xfs in commit 4b8d867ca6e2 ("xfs: don't over-report free space or inodes in statvfs") where statfs can report misleading / incorrect information where project quota is enabled, and the free space is less than the remaining quota.
This commit will resolve a test failure in generic/762 which tests for this bug.
--- fs/ext4/super.c | 27 +++++++++++++++++---------- 1 file changed, 17 insertions(+), 10 deletions(-)
fs/ext4/super.c +17 -10
@@ -6087,22 +6087,29 @@ static int ext4_statfs_project(struct su dquot->dq_dqb.dqb_bhardlimit); limit >>= sb->s_blocksize_bits; -if (limit && buf->f_blocks > limit) { +if (limit) { +uint64_t remaining =0 ; + curblock = (dquot->dq_dqb.dqb_curspace + dquot->dq_dqb.dqb_rsvspace) >> sb->s_blocksize_bits; - buf->f_blocks = limit; - buf->f_bfree = buf->f_bavail = - (buf->f_blocks > curblock) ? - (buf->f_blocks - curblock) :0 ; +if (limit > curblock) + remaining = limit - curblock; + + buf->f_blocks =min (buf->f_blocks, limit); + buf->f_bfree =min (buf->f_bfree, remaining); + buf->f_bavail =min (buf->f_bavail, remaining); } limit =min_not_zero (dquot->dq_dqb.dqb_isoftlimit, dquot->dq_dqb.dqb_ihardlimit); -if (limit && buf->f_files > limit) { - buf->f_files = limit; - buf->f_ffree = - (buf->f_files > dquot->dq_dqb.dqb_curinodes) ? - (buf->f_files - dquot->dq_dqb.dqb_curinodes) :0 ; +if (limit) { +uint64_t remaining =0 ; + +if (limit > dquot->dq_dqb.dqb_curinodes) + remaining = limit - dquot->dq_dqb.dqb_curinodes; + + buf->f_files =min (buf->f_files, limit); + buf->f_ffree =min (buf->f_ffree, remaining); }spin_unlock (&dquot->dq_dqb_lock);
Greg Kroah-Hartman
maintainerPATCH 273/279 ext4: fix OOB read when checking dotdot dir
In reply to Greg Kroah-Hartman5.15-stable review patch. If anyone has any objections, please let me know.
------------------
From: Acs, Jakub <[email protected]>
commit d5e206778e96e8667d3bde695ad372c296dc9353 upstream.
Mounting a corrupted filesystem with directory which contains '.' dir entry with rec_len == block size results in out-of-bounds read (later on, when the corrupted directory is removed).
ext4_empty_dir() assumes every ext4 directory contains at least '.' and '..' as directory entries in the first data block. It first loads the '.' dir entry, performs sanity checks by calling ext4_check_dir_entry() and then uses its rec_len member to compute the location of '..' dir entry (in ext4_next_entry). It assumes the '..' dir entry fits into the same data block.
If the rec_len of '.' is precisely one block (4KB), it slips through the sanity checks (it is considered the last directory entry in the data block) and leaves "struct ext4_dir_entry_2 *de" point exactly past the memory slot allocated to the data block. The following call to ext4_check_dir_entry() on new value of de then dereferences this pointer which results in out-of-bounds mem access.
Fix this by extending __ext4_check_dir_entry() to check for '.' dir entries that reach the end of data block. Make sure to ignore the phony dir entries for checksum (by checking name_len for non-zero).
Note: This is reported by KASAN as use-after-free in case another structure was recently freed from the slot past the bound, but it is really an OOB read.
This issue was found by syzkaller tool.
Call Trace: [ 38.594108] BUG: KASAN: slab-use-after-free in __ext4_check_dir_entry+0x67e/0x710 [ 38.594649] Read of size 2 at addr ffff88802b41a004 by task syz-executor/5375 [ 38.595158] [ 38.595288] CPU: 0 UID: 0 PID: 5375 Comm: syz-executor Not tainted 6.14.0-rc7 #1 [ 38.595298] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.3-0-ga6ed6b701f0a-prebuilt.qemu.org 04/01/2014 [ 38.595304] Call Trace: [ 38.595308] <TASK> [ 38.595311] dump_stack_lvl+0xa7/0xd0 [ 38.595325] print_address_description.constprop.0+0x2c/0x3f0 [ 38.595339] ? __ext4_check_dir_entry+0x67e/0x710 [ 38.595349] print_report+0xaa/0x250 [ 38.595359] ? __ext4_check_dir_entry+0x67e/0x710 [ 38.595368] ? kasan_addr_to_slab+0x9/0x90 [ 38.595378] kasan_report+0xab/0xe0 [ 38.595389] ? __ext4_check_dir_entry+0x67e/0x710 [ 38.595400] __ext4_check_dir_entry+0x67e/0x710 [ 38.595410] ext4_empty_dir+0x465/0x990 [ 38.595421] ? __pfx_ext4_empty_dir+0x10/0x10 [ 38.595432] ext4_rmdir.part.0+0x29a/0xd10 [ 38.595441] ? __dquot_initialize+0x2a7/0xbf0 [ 38.595455] ? __pfx_ext4_rmdir.part.0+0x10/0x10 [ 38.595464] ? __pfx___dquot_initialize+0x10/0x10 [ 38.595478] ? down_write+0xdb/0x140 [ 38.595487] ? __pfx_down_write+0x10/0x10 [ 38.595497] ext4_rmdir+0xee/0x140 [ 38.595506] vfs_rmdir+0x209/0x670 [ 38.595517] ? lookup_one_qstr_excl+0x3b/0x190 [ 38.595529] do_rmdir+0x363/0x3c0 [ 38.595537] ? __pfx_do_rmdir+0x10/0x10 [ 38.595544] ? strncpy_from_user+0x1ff/0x2e0 [ 38.595561] __x64_sys_unlinkat+0xf0/0x130 [ 38.595570] do_syscall_64+0x5b/0x180 [ 38.595583] entry_SYSCALL_64_after_hwframe+0x76/0x7e
--- fs/ext4/dir.c | 3 +++ 1 file changed, 3 insertions(+)
fs/ext4/dir.c +3 -0
@@ -104,6 +104,9 @@ int __ext4_check_dir_entry(const char *felse if (unlikely (le32_to_cpu (de->inode) >le32_to_cpu (EXT4_SB (dir->i_sb)->s_es->s_inodes_count))) error_msg ="inode out of bounds" ; +else if (unlikely (next_offset == size && de->name_len ==1 && + de->name[0 ] =='.' )) + error_msg ="'.' directory cannot be the last in data block" ;else return 0 ;
Greg Kroah-Hartman
maintainerPATCH 274/279 jfs: fix slab-out-of-bounds read in ea_get()
In reply to Greg Kroah-Hartman5.15-stable review patch. If anyone has any objections, please let me know.
------------------
From: Qasim Ijaz <[email protected]>
commit fdf480da5837c23b146c4743c18de97202fcab37 upstream.
During the "size_check" label in ea_get(), the code checks if the extended attribute list (xattr) size matches ea_size. If not, it logs "ea_get: invalid extended attribute" and calls print_hex_dump().
Here, EALIST_SIZE(ea_buf->xattr) returns 4110417968, which exceeds INT_MAX (2,147,483,647). Then ea_size is clamped:
int size = clamp_t(int, ea_size, 0, EALIST_SIZE(ea_buf->xattr));
Although clamp_t aims to bound ea_size between 0 and 4110417968, the upper limit is treated as an int, causing an overflow above 2^31 - 1. This leads "size" to wrap around and become negative (-184549328).
The "size" is then passed to print_hex_dump() (called "len" in print_hex_dump()), it is passed as type size_t (an unsigned type), this is then stored inside a variable called "int remaining", which is then assigned to "int linelen" which is then passed to hex_dump_to_buffer(). In print_hex_dump() the for loop, iterates through 0 to len-1, where len is 18446744073525002176, calling hex_dump_to_buffer() on each iteration:
for (i = 0; i < len; i += rowsize) {
linelen = min(remaining, rowsize);
remaining -= rowsize;
hex_dump_to_buffer(ptr + i, linelen, rowsize, groupsize,
linebuf, sizeof(linebuf), ascii);
...
}The expected stopping condition (i < len) is effectively broken since len is corrupted and very large. This eventually leads to the "ptr+i" being passed to hex_dump_to_buffer() to get closer to the end of the actual bounds of "ptr", eventually an out of bounds access is done in hex_dump_to_buffer() in the following for loop:
for (j = 0; j < len; j++) {
if (linebuflen < lx + 2)
goto overflow2;
ch = ptr[j];
...
}To fix this we should validate "EALIST_SIZE(ea_buf->xattr)" before it is utilised.
--- fs/jfs/xattr.c | 13 +++++++++---- 1 file changed, 9 insertions(+), 4 deletions(-)
fs/jfs/xattr.c +9 -4
@@ -559,11 +559,16 @@ static int ea_get(struct inode *inode, s size_check:if (EALIST_SIZE (ea_buf->xattr) != ea_size) { -int size =clamp_t (int, ea_size,0 ,EALIST_SIZE (ea_buf->xattr)); +if (unlikely (EALIST_SIZE (ea_buf->xattr) >INT_MAX )) { +printk (KERN_ERR "ea_get: extended attribute size too large: %u > INT_MAX\n" , +EALIST_SIZE (ea_buf->xattr)); + }else { +int size =clamp_t (int, ea_size,0 ,EALIST_SIZE (ea_buf->xattr)); -printk (KERN_ERR "ea_get: invalid extended attribute\n" ); -print_hex_dump (KERN_ERR ,"" ,DUMP_PREFIX_ADDRESS ,16 ,1 , - ea_buf->xattr, size,1 ); +printk (KERN_ERR "ea_get: invalid extended attribute\n" ); +print_hex_dump (KERN_ERR ,"" ,DUMP_PREFIX_ADDRESS ,16 ,1 , + ea_buf->xattr, size,1 ); + }ea_release (inode, ea_buf); rc = -EIO ; goto clean_up;
Greg Kroah-Hartman
maintainerPATCH 275/279 jfs: add index corruption check to DT_GETPAGE()
In reply to Greg Kroah-Hartman5.15-stable review patch. If anyone has any objections, please let me know.
------------------
From: Roman Smirnov <[email protected]>
commit a8dfb2168906944ea61acfc87846b816eeab882d upstream.
If the file system is corrupted, the header.stblindex variable may become greater than 127. Because of this, an array access out of bounds may occur:
------------[ cut here ]------------ UBSAN: array-index-out-of-bounds in fs/jfs/jfs_dtree.c:3096:10 index 237 is out of range for type 'struct dtslot[128]' CPU: 0 UID: 0 PID: 5822 Comm: syz-executor740 Not tainted 6.13.0-rc4-syzkaller-00110-g4099a71718b0 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/13/2024 Call Trace: <TASK> __dump_stack lib/dump_stack.c:94 [inline] dump_stack_lvl+0x241/0x360 lib/dump_stack.c:120 ubsan_epilogue lib/ubsan.c:231 [inline] __ubsan_handle_out_of_bounds+0x121/0x150 lib/ubsan.c:429 dtReadFirst+0x622/0xc50 fs/jfs/jfs_dtree.c:3096 dtReadNext fs/jfs/jfs_dtree.c:3147 [inline] jfs_readdir+0x9aa/0x3c50 fs/jfs/jfs_dtree.c:2862 wrap_directory_iterator+0x91/0xd0 fs/readdir.c:65 iterate_dir+0x571/0x800 fs/readdir.c:108 __do_sys_getdents64 fs/readdir.c:403 [inline] __se_sys_getdents64+0x1e2/0x4b0 fs/readdir.c:389 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f </TASK> ---[ end trace ]---
Add a stblindex check for corruption.
--- fs/jfs/jfs_dtree.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-)
fs/jfs/jfs_dtree.c +2 -1
@@ -117,7 +117,8 @@ do { \if (!(RC )) { \if (((P )->header.nextindex > \ (((BN ) ==0 ) ?DTROOTMAXSLOT : (P )->header.maxslot)) || \ - ((BN ) && ((P )->header.maxslot >DTPAGEMAXSLOT ))) { \ + ((BN ) && (((P )->header.maxslot >DTPAGEMAXSLOT ) || \ + ((P )->header.stblindex >=DTPAGEMAXSLOT )))) { \BT_PUTPAGE (MP ); \jfs_error ((IP )->i_sb, \"DT_GETPAGE: dtree page corrupt\n" ); \
Greg Kroah-Hartman
maintainerPATCH 276/279 nfsd: put dl_stid if fail to queue dl_recall
In reply to Greg Kroah-Hartman5.15-stable review patch. If anyone has any objections, please let me know.
------------------
From: Li Lingfeng <[email protected]>
commit 230ca758453c63bd38e4d9f4a21db698f7abada8 upstream.
Before calling nfsd4_run_cb to queue dl_recall to the callback_wq, we increment the reference count of dl_stid.
We expect that after the corresponding work_struct is processed, the reference count of dl_stid will be decremented through the callback function nfsd4_cb_recall_release.
However, if the call to nfsd4_run_cb fails, the incremented reference count of dl_stid will not be decremented correspondingly, leading to the following nfs4_stid leak:
unreferenced object 0xffff88812067b578 (size 344):
comm "nfsd", pid 2761, jiffies 4295044002 (age 5541.241s) hex dump (first 32 bytes):
01 00 00 00 6b 6b 6b 6b b8 02 c0 e2 81 88 ff ff ....kkkk........
00 6b 6b 6b 6b 6b 6b 6b 00 00 00 00 ad 4e ad de .kkkkkkk.....N..
backtrace:
kmem_cache_alloc+0x4b9/0x700
nfsd4_process_open1+0x34/0x300
nfsd4_open+0x2d1/0x9d0
nfsd4_proc_compound+0x7a2/0xe30
nfsd_dispatch+0x241/0x3e0
svc_process_common+0x5d3/0xcc0
svc_process+0x2a3/0x320
nfsd+0x180/0x2e0
kthread+0x199/0x1d0
ret_from_fork+0x30/0x50
ret_from_fork_asm+0x1b/0x30
unreferenced object 0xffff8881499f4d28 (size 368):
comm "nfsd", pid 2761, jiffies 4295044005 (age 5541.239s)
hex dump (first 32 bytes):
01 00 00 00 00 00 00 00 30 4d 9f 49 81 88 ff ff ........0M.I....
30 4d 9f 49 81 88 ff ff 20 00 00 00 01 00 00 00 0M.I.... .......
backtrace:
kmem_cache_alloc+0x4b9/0x700
nfs4_alloc_stid+0x29/0x210
alloc_init_deleg+0x92/0x2e0
nfs4_set_delegation+0x284/0xc00
nfs4_open_delegation+0x216/0x3f0
nfsd4_process_open2+0x2b3/0xee0
nfsd4_open+0x770/0x9d0
nfsd4_proc_compound+0x7a2/0xe30
nfsd_dispatch+0x241/0x3e0
svc_process_common+0x5d3/0xcc0
svc_process+0x2a3/0x320
nfsd+0x180/0x2e0
kthread+0x199/0x1d0
ret_from_fork+0x30/0x50
ret_from_fork_asm+0x1b/0x30Fix it by checking the result of nfsd4_run_cb and call nfs4_put_stid if fail to queue dl_recall.
--- fs/nfsd/nfs4state.c | 12 +++++++++++- 1 file changed, 11 insertions(+), 1 deletion(-)
fs/nfsd/nfs4state.c +11 -1
@@ -1069,6 +1069,12 @@ static struct nfs4_ol_stateid * nfs4_allreturn openlockstateid (stid); } +/* +* As the sc_free callback of deleg, this may be called by nfs4_put_stid +* in nfsd_break_one_deleg. +* Considering nfsd_break_one_deleg is called with the flc->flc_lock held, +* this function mustn't ever sleep. +*/ static void nfs4_free_deleg (struct nfs4_stid *stid) {struct nfs4_delegation *dp =delegstateid (stid);
@@ -4926,6 +4932,7 @@ static const struct nfsd4_callback_ops nstatic void nfsd_break_one_deleg (struct nfs4_delegation *dp) { +bool queued;/* * We're assuming the state code never drops its reference * without first removing the lease. Since we're in this lease
@@ -4934,7 +4941,10 @@ static void nfsd_break_one_deleg(struct* we know it's safe to take a reference. */ refcount_inc (&dp->dl_stid.sc_count); -WARN_ON_ONCE (!nfsd4_run_cb (&dp->dl_recall)); + queued =nfsd4_run_cb (&dp->dl_recall); +WARN_ON_ONCE (!queued); +if (!queued) +nfs4_put_stid (&dp->dl_stid); }/* Called from break_lease() with flc_lock held. */
Greg Kroah-Hartman
maintainerPATCH 277/279 NFSD: Skip sending CB_RECALL_ANY when the backchannel isnt up
In reply to Greg Kroah-Hartman5.15-stable review patch. If anyone has any objections, please let me know.
------------------
From: Chuck Lever <[email protected]>
commit 8a388c1fabeb6606e16467b23242416c0dbeffad upstream.
NFSD sends CB_RECALL_ANY to clients when the server is low on memory or that client has a large number of delegations outstanding.
We've seen cases where NFSD attempts to send CB_RECALL_ANY requests to disconnected clients, and gets confused. These calls never go anywhere if a backchannel transport to the target client isn't available. Before the server can send any backchannel operation, the client has to connect first and then do a BIND_CONN_TO_SESSION.
This patch doesn't address the root cause of the confusion, but there's no need to queue up these optional operations if they can't go anywhere.
--- fs/nfsd/nfs4state.c | 19 ++++++++++++------- 1 file changed, 12 insertions(+), 7 deletions(-)
fs/nfsd/nfs4state.c +12 -7
@@ -6250,14 +6250,19 @@ deleg_reaper(struct nfsd_net *nn)spin_lock (&nn->client_lock);list_for_each_safe (pos, next, &nn->client_lru) { clp = list_entry(pos, struct nfs4_client, cl_lru); -if (clp->cl_state !=NFSD4_ACTIVE || -list_empty (&clp->cl_delegations) || -atomic_read (&clp->cl_delegs_in_recall) || -test_bit (NFSD4_CLIENT_CB_RECALL_ANY , &clp->cl_flags) || - (ktime_get_boottime_seconds () - - clp->cl_ra_time <5 )) { + +if (clp->cl_state !=NFSD4_ACTIVE ) +continue ; +if (list_empty (&clp->cl_delegations)) +continue ; +if (atomic_read (&clp->cl_delegs_in_recall)) +continue ; +if (test_bit (NFSD4_CLIENT_CB_RECALL_ANY , &clp->cl_flags)) +continue ; +if (ktime_get_boottime_seconds () - clp->cl_ra_time <5 ) +continue ; +if (clp->cl_cb_state !=NFSD4_CB_UP )continue ; - }list_add (&clp->cl_ra_cblist, &cblist);/* release in nfsd4_cb_recall_any_release */
Greg Kroah-Hartman
maintainerPATCH 278/279 mmc: sdhci-brcmstb: use clk_get_rate(base_clk) in PM resume
In reply to Greg Kroah-Hartman5.15-stable review patch. If anyone has any objections, please let me know.
------------------
From: Kamal Dasu <[email protected]>
commit 886201c70a1cab34ef96f867c2b2dd6379ffa7b9 upstream.
Use clk_get_rate for base_clk on resume before setting new rate. This change ensures that the clock api returns current rate and sets the clock to the desired rate and honors CLK_GET_NO_CACHE attribute used by clock api.
--- drivers/mmc/host/sdhci-brcmstb.c | 9 ++++++++- 1 file changed, 8 insertions(+), 1 deletion(-)
drivers/mmc/host/sdhci-brcmstb.c +8 -1
@@ -414,7 +414,14 @@ static int sdhci_brcmstb_resume(struct d ret =sdhci_pltfm_resume (dev);if (!ret && priv->base_freq_hz) { ret =clk_prepare_enable (priv->base_clk); -if (!ret) +/* +* Note: using clk_get_rate() below as clk_get_rate() +* honors CLK_GET_RATE_NOCACHE attribute, but clk_set_rate() +* may do implicit get_rate() calls that do not honor +* CLK_GET_RATE_NOCACHE. +*/ +if (!ret && + (clk_get_rate (priv->base_clk) != priv->base_freq_hz)) ret =clk_set_rate (priv->base_clk, priv->base_freq_hz); }
Greg Kroah-Hartman
maintainerPATCH 279/279 mm, slab: remove duplicate kernel-doc comment for ksize()
In reply to Greg Kroah-Hartman5.15-stable review patch. If anyone has any objections, please let me know.
------------------
From: Vlastimil Babka <[email protected]>
commit c18c20f16219516b12a4f2fd29c25e06be97e064 upstream.
Akira reports:
Quoted 8 lines
"make htmldocs" reports duplicate C declaration of
ksize()as follows:/linux/Documentation/core-api/mm-api:43:
./mm/slab_common.c:1428: WARNING: Duplicate C declaration, also defined at core-api/mm-api:212. Declaration is '.. c:function::size_tksize (const void *objp)'.This is due to the kernel-doc comment for
ksize()declaration added ininclude/linux/slab.hby commit05a940656e1e("slab: Introducekmalloc_size_roundup()").
There is an older kernel-doc comment for ksize() definition in mm/slab_common.c, which is not only duplicated, but also contradicts the new one - the additional storage discovered by ksize() should not be used by callers anymore. Delete the old kernel-doc.
--- mm/slab_common.c | 14 -------------- 1 file changed, 14 deletions(-)
mm/slab_common.c +0 -14
@@ -1305,20 +1305,6 @@ void kfree_sensitive(const void *p) }EXPORT_SYMBOL (kfree_sensitive); -/** -* ksize - get the actual amount of memory allocated for a given object -* @objp: Pointer to the object -* -* kmalloc may internally round up allocations and return more memory -* than requested. ksize() can be used to determine the actual amount of -* memory allocated. The caller may use this additional memory, even though -* a smaller amount of memory was initially specified with the kmalloc call. -* The caller must guarantee that objp points to a valid object previously -* allocated with either kmalloc() or kmem_cache_alloc(). The object -* must not be freed during the duration of the call. -* -* Return: size of the actual memory used by @objp in bytes -*/ size_t ksize (const void *objp) {size_t size;
Quoted 4 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 5.15.180 release. There are 279 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.
Quoted 9 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 5.15.180 release. There are 279 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.
Responses should be made by Thu, 10 Apr 2025 10:47:53 +0000. Anything received after that time might be too late.
The whole patch series can be found in one patch at:
Quoted 8 lines
https://www.kernel.org/pub/linux/kernel/v5.x/stable-review/patch-5.15.180-rc1.gzor in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.gitlinux-5.15.y
and the diffstat can be found below.thanks,
greg k-h
On ARCH_BRCMSTB using 32-bit and 64-bit ARM kernels, build tested on BMIPS_GENERIC:
Signature · 1 line
Florian
Hello,
Quoted 7 lines · On Tue, 8 Apr 2025 12:46:23 +0200 Greg Kroah-Hartman…
This is the start of the stable review cycle for the 5.15.180 release. There are 279 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.
Responses should be made by Thu, 10 Apr 2025 10:47:53 +0000. Anything received after that time might be too late.
This rc kernel passes DAMON functionality test[1] on my test machine. Attaching the test results summary below. Please note that I retrieved the kernel from linux-stable-rc tree[2].
[1] https://github.com/damonitor/damon-tests/tree/next/corr
[2] 0b4857306c61 ("Linux 5.15.180-rc1")
Thanks,
SJ
[...]
---
ok 1 selftests: damon: debugfs_attrs.sh
ok 1 selftests: damon-tests: kunit.sh
ok 2 selftests: damon-tests: huge_count_read_write.sh
ok 3 selftests: damon-tests: buffer_overflow.sh
ok 4 selftests: damon-tests: rm_contexts.sh
ok 5 selftests: damon-tests: record_null_deref.sh
ok 6 selftests: damon-tests: dbgfs_target_ids_read_before_terminate_race.sh ok 7 selftests: damon-tests: dbgfs_target_ids_pid_leak.sh
ok 8 selftests: damon-tests: damo_tests.sh
ok 9 selftests: damon-tests: masim-record.sh
ok 10 selftests: damon-tests: build_i386.sh
ok 11 selftests: damon-tests: build_arm64.sh # SKIP
ok 12 selftests: damon-tests: build_m68k.sh # SKIP
ok 13 selftests: damon-tests: build_i386_idle_flag.sh
ok 14 selftests: damon-tests: build_i386_highpte.sh
ok 15 selftests: damon-tests: build_nomemcg.sh
[33m
[92mPASS [39m
Quoted 8 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 5.15.180 release. There are 279 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.
Responses should be made by Thu, 10 Apr 2025 10:47:53 +0000. Anything received after that time might be too late.
Quoted 7 lines
The whole patch series can be found in one patch at:
https://www.kernel.org/pub/linux/kernel/v5.x/stable-review/
patch-5.15.180-rc1.gz
or in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.gitlinux-5.15.y
and the diffstat can be found below.
No issues were seen on x86_64 and aarch64 platforms with our testing.
Quoted 3 lines
thanks,
greg k-h
thanks,
Vijay
Quoted 9 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 5.15.180 release. There are 279 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.
Responses should be made by Thu, 10 Apr 2025 10:47:53 +0000. Anything received after that time might be too late.
The whole patch series can be found in one patch at:
Quoted 8 lines
https://www.kernel.org/pub/linux/kernel/v5.x/stable-review/patch-5.15.180-rc1.gzor in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.gitlinux-5.15.y
and the diffstat can be found below.thanks,
greg k-h
Built and booted successfully on RISC-V RV64 (HiFive Unmatched).
Quoted 9 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 5.15.180 release. There are 279 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.
Responses should be made by Thu, 10 Apr 2025 10:47:53 +0000. Anything received after that time might be too late.
The whole patch series can be found in one patch at:
Quoted 8 lines
https://www.kernel.org/pub/linux/kernel/v5.x/stable-review/patch-5.15.180-rc1.gzor in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.gitlinux-5.15.y
and the diffstat can be found below.thanks,
greg k-h
All tests passing for Tegra ...
Test results for stable-v5.15:
10 builds: 10 pass, 0 fail
28 boots: 28 pass, 0 fail
101 tests: 101 pass, 0 failLinux version: 5.15.180-rc1-g0b4857306c61
Boards tested: tegra124-jetson-tk1, tegra186-p2771-0000,
tegra186-p3509-0000+p3636-0001, tegra194-p2972-0000,
tegra194-p3509-0000+p3668-0000, tegra20-ventana,
tegra210-p2371-2180, tegra210-p3450-0000,
tegra30-cardhu-a04Jon
Quoted 10 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 5.15.180 release. There are 279 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.
Responses should be made by Thu, 10 Apr 2025 10:47:53 +0000. Anything received after that time might be too late.
The whole patch series can be found in one patch at:
Quoted 8 lines
https://www.kernel.org/pub/linux/kernel/v5.x/stable-review/patch-5.15.180-rc1.gzor in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.gitlinux-5.15.y
and the diffstat can be found below.thanks,
greg k-h
Results from Linaro’s test farm.
No regressions on arm64, arm, x86_64, and i386.
## Build
* kernel: 5.15.180-rc1
* git: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git
* git commit: 0b4857306c618d2052f6455b90747ef1df364ecd
* git describe: v5.15.179-280-g0b4857306c61
* test details:
https://qa-reports.linaro.org/lkft/linux-stable-rc-linux-5.15.y/build/v5.15.179-280-g0b4857306c61
## Test Regressions (compared to v5.15.178-617-g4372970bf866)
## Metric Regressions (compared to v5.15.178-617-g4372970bf866)
## Test Fixes (compared to v5.15.178-617-g4372970bf866)
## Metric Fixes (compared to v5.15.178-617-g4372970bf866)
## Test result summary
total: 51097, pass: 36064, fail: 2716, skip: 11897, xfail: 420
## Build Summary
* arc: 5 total, 5 passed, 0 failed
* arm: 102 total, 102 passed, 0 failed
* arm64: 30 total, 30 passed, 0 failed
* i386: 22 total, 20 passed, 2 failed
* mips: 22 total, 22 passed, 0 failed
* parisc: 3 total, 3 passed, 0 failed
* powerpc: 22 total, 22 passed, 0 failed
* riscv: 8 total, 8 passed, 0 failed
* s390: 9 total, 9 passed, 0 failed
* sh: 10 total, 10 passed, 0 failed
* sparc: 6 total, 6 passed, 0 failed
* x86_64: 26 total, 26 passed, 0 failed
## Test suites summary
* boot
* kselftest-arm64
* kselftest-breakpoints
* kselftest-capabilities
* kselftest-cgroup
* kselftest-clone3
* kselftest-core
* kselftest-cpu-hotplug
* kselftest-cpufreq
* kselftest-efivarfs
* kselftest-exec
* kselftest-fpu
* kselftest-ftrace
* kselftest-futex
* kselftest-gpio
* kselftest-intel_pstate
* kselftest-ipc
* kselftest-kcmp
* kselftest-livepatch
* kselftest-membarrier
* kselftest-memfd
* kselftest-mincore
* kselftest-mqueue
* kselftest-net
* kselftest-net-mptcp
* kselftest-openat2
* kselftest-ptrace
* kselftest-rseq
* kselftest-rtc
* kselftest-seccomp
* kselftest-sigaltstack
* kselftest-size
* kselftest-tc-testing
* kselftest-timers
* kselftest-tmpfs
* kselftest-tpm2
* kselftest-user_events
* kselftest-vDSO
* kselftest-x86
* kunit
* kvm-unit-tests
* libgpiod
* libhugetlbfs
* log-parser-boot
* log-parser-build-clang
* log-parser-build-gcc
* log-parser-test
* ltp-capability
* ltp-commands
* ltp-containers
* ltp-controllers
* ltp-cpuhotplug
* ltp-crypto
* ltp-cve
* ltp-dio
* ltp-fcntl-locktests
* ltp-fs
* ltp-fs_bind
* ltp-fs_perms_simple
* ltp-hugetlb
* ltp-ipc
* ltp-math
* ltp-mm
* ltp-nptl
* ltp-pty
* ltp-sched
* ltp-smoke
* ltp-syscalls
* ltp-tracing
* perf
* rcutorture
--
Linaro LKFT
https://lkft.linaro.org