Skip to contentSkip to conversation

5.15.134-rc1 review

PATCH In review Greg Kroah-Hartman 14 participants 213 messages Oct 4, 2023 – Oct 16, 2023 Page 2 of 2

Subsystems (6)
lore
Share & tools
lore
author maintainer
#104 lore raw

PATCH 104/183 xtensa: iss/network: make functions static

In reply to Greg Kroah-Hartman

5.15-stable review patch. If anyone has any objections, please let me know.

------------------

From: Randy Dunlap <[email protected]>

[ Upstream commit 1b59efeb59851277266318f4e0132aa61ce3455e ]

Make 2 functions static to prevent build warnings:

arch/xtensa/platforms/iss/network.c:204:16: warning: no previous prototype for 'tuntap_protocol' [-Wmissing-prototypes]
204 | unsigned short tuntap_protocol(struct sk_buff *skb)
arch/xtensa/platforms/iss/network.c:444:6: warning: no previous prototype for 'iss_net_user_timer_expire' [-Wmissing-prototypes]
444 | void iss_net_user_timer_expire(struct timer_list *unused)

Fixes 7282bee78798 ("xtensa: Architecture support for Tensilica Xtensa Part 8")
Fixes d8479a21a98b ("xtensa: Convert timers to use timer_setup()")
Cc Chris Zankel <[email protected]>
Cc Max Filippov <[email protected]>

Message-Id: <[email protected]>

---
 arch/xtensa/platforms/iss/network.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)
arch/xtensa/platforms/iss/network.c +2 -2
index 1270de83435eb..e8491ac0d5b93 100644
@@ -204,7 +204,7 @@ static int tuntap_write(struct iss_net_private *lp, struct sk_buff **skb)
 	return simc_write(lp->tp.info.tuntap.fd, (*skb)->data, (*skb)->len);
 }
 
-unsigned short tuntap_protocol(struct sk_buff *skb)
+static unsigned short tuntap_protocol(struct sk_buff *skb)
 {
 	return eth_type_trans(skb, skb->dev);
 }
@@ -477,7 +477,7 @@ static int iss_net_change_mtu(struct net_device *dev, int new_mtu)
 	return -EINVAL;
 }
 
-void iss_net_user_timer_expire(struct timer_list *unused)
+static void iss_net_user_timer_expire(struct timer_list *unused)
 {
 }
 
Signature · 1 line
2.40.1
author maintainer
#105 lore raw

PATCH 105/183 xtensa: boot: dont add include-dirs

In reply to Greg Kroah-Hartman

5.15-stable review patch. If anyone has any objections, please let me know.

------------------

From: Randy Dunlap <[email protected]>

[ Upstream commit 54d3d7d363823782c3444ddc41bb8cf1edc80514 ]

Drop the -I<include-dir> options to prevent build warnings since there is not boot/include directory:

cc1: warning: arch/xtensa/boot/include: No such file or directory [-Wmissing-include-dirs]

Fixes 437374e9a950 ("restore arch/{ppc/xtensa}/boot cflags")
Fixes 4bedea945451 ("xtensa: Architecture support for Tensilica Xtensa Part 2")
Cc Chris Zankel <[email protected]>
Cc Max Filippov <[email protected]>

Message-Id: <[email protected]>

---
 arch/xtensa/boot/Makefile | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)
arch/xtensa/boot/Makefile +1 -2
index a65b7a9ebff28..d8b0fadf429a9 100644
@@ -9,8 +9,7 @@
 
 
 # KBUILD_CFLAGS used when building rest of boot (takes effect recursively)
-KBUILD_CFLAGS	+= -fno-builtin -Iarch/$(ARCH)/boot/include
-HOSTFLAGS	+= -Iarch/$(ARCH)/boot/include
+KBUILD_CFLAGS	+= -fno-builtin
 
 subdir-y	:= lib
 targets		+= vmlinux.bin vmlinux.bin.gz
Signature · 1 line
2.40.1
author maintainer
#106 lore raw

PATCH 106/183 xtensa: boot/lib: fix function prototypes

In reply to Greg Kroah-Hartman

5.15-stable review patch. If anyone has any objections, please let me know.

------------------

From: Max Filippov <[email protected]>

[ Upstream commit f54d02c8f2cc4b46ba2a3bd8252a6750453b6f2b ]

Add function prototype for gunzip() to the boot library code and make exit() and zalloc() static.

arch/xtensa/boot/lib/zmem.c:8:6: warning: no previous prototype for 'exit' [-Wmissing-prototypes]
8 | void exit (void)
arch/xtensa/boot/lib/zmem.c:13:7: warning: no previous prototype for 'zalloc' [-Wmissing-prototypes]
13 | void *zalloc(unsigned size)
arch/xtensa/boot/lib/zmem.c:35:6: warning: no previous prototype for 'gunzip' [-Wmissing-prototypes]
35 | void gunzip (void *dst, int dstlen, unsigned char *src, int *lenp)

Fixes 4bedea945451 ("xtensa: Architecture support for Tensilica Xtensa Part 2")
Fixes e7d163f76665 ("xtensa: Removed local copy of zlib and fixed O= support")
---
 arch/xtensa/boot/lib/zmem.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)
arch/xtensa/boot/lib/zmem.c +3 -2
index e3ecd743c5153..b89189355122a 100644
@@ -4,13 +4,14 @@
 /* bits taken from ppc */
 
 extern void *avail_ram, *end_avail;
+void gunzip(void *dst, int dstlen, unsigned char *src, int *lenp);
 
-void exit (void)
+static void exit(void)
 {
   for (;;);
 }
 
-void *zalloc(unsigned size)
+static void *zalloc(unsigned int size)
 {
         void *p = avail_ram;
 
Signature · 1 line
2.40.1
author maintainer
#107 lore raw

PATCH 107/183 soc: imx8m: Enable OCOTP clock for imx8mm before reading registers

In reply to Greg Kroah-Hartman

5.15-stable review patch. If anyone has any objections, please let me know.

------------------

From: Nathan Rossi <[email protected]>

[ Upstream commit 9d1e8275a28f51599d754ce661c91e0a689c0234 ]

Commit 836fb30949d9 ("soc: imx8m: Enable OCOTP clock before reading the register") added configuration to enable the OCOTP clock before attempting to read from the associated registers.

This same kexec issue is present with the imx8m SoCs that use the imx8mm_soc_uid function (e.g. imx8mp). This requires the imx8mm_soc_uid function to configure the OCOTP clock before accessing the associated registers. This change implements the same clock enable functionality that is present in the imx8mq_soc_revision function for the imx8mm_soc_uid function.

Fixes 836fb30949d9 ("soc: imx8m: Enable OCOTP clock before reading the register")
---
 drivers/soc/imx/soc-imx8m.c | 10 ++++++++++
 1 file changed, 10 insertions(+)
drivers/soc/imx/soc-imx8m.c +10 -0
index 32ed9dc88e455..08197b03955dd 100644
@@ -100,6 +100,7 @@ static void __init imx8mm_soc_uid(void)
 {
 	void __iomem *ocotp_base;
 	struct device_node *np;
+	struct clk *clk;
 	u32 offset = of_machine_is_compatible("fsl,imx8mp") ?
 		     IMX8MP_OCOTP_UID_OFFSET : 0;
 
@@ -109,11 +110,20 @@ static void __init imx8mm_soc_uid(void)
 
 	ocotp_base = of_iomap(np, 0);
 	WARN_ON(!ocotp_base);
+	clk = of_clk_get_by_name(np, NULL);
+	if (IS_ERR(clk)) {
+		WARN_ON(IS_ERR(clk));
+		return;
+	}
+
+	clk_prepare_enable(clk);
 
 	soc_uid = readl_relaxed(ocotp_base + OCOTP_UID_HIGH + offset);
 	soc_uid <<= 32;
 	soc_uid |= readl_relaxed(ocotp_base + OCOTP_UID_LOW + offset);
 
+	clk_disable_unprepare(clk);
+	clk_put(clk);
 	iounmap(ocotp_base);
 	of_node_put(np);
 }
Signature · 1 line
2.40.1
author maintainer
#108 lore raw

PATCH 108/183 gpio: pmic-eic-sprd: Add can_sleep flag for PMIC EIC chip

In reply to Greg Kroah-Hartman

5.15-stable review patch. If anyone has any objections, please let me know.

------------------

From: Wenhua Lin <[email protected]>

[ Upstream commit 26d9e5640d2130ee16df7b1fb6a908f460ab004c ]

The drivers uses a mutex and I2C bus access in its PMIC EIC chip get implementation. This means these functions can sleep and the PMIC EIC chip should set the can_sleep property to true.

This will ensure that a warning is printed when trying to get the value from a context that potentially can't sleep.

Fixes 348f3cde84ab ("gpio: Add Spreadtrum PMIC EIC driver support")
---
 drivers/gpio/gpio-pmic-eic-sprd.c | 1 +
 1 file changed, 1 insertion(+)
drivers/gpio/gpio-pmic-eic-sprd.c +1 -0
index 9382851905662..e969ce9131ddf 100644
@@ -338,6 +338,7 @@ static int sprd_pmic_eic_probe(struct platform_device *pdev)
 	pmic_eic->chip.set_config = sprd_pmic_eic_set_config;
 	pmic_eic->chip.set = sprd_pmic_eic_set;
 	pmic_eic->chip.get = sprd_pmic_eic_get;
+	pmic_eic->chip.can_sleep = true;
 
 	pmic_eic->intc.name = dev_name(&pdev->dev);
 	pmic_eic->intc.irq_mask = sprd_pmic_eic_irq_mask;
Signature · 1 line
2.40.1
author maintainer
#109 lore raw

PATCH 109/183 i2c: npcm7xx: Fix callback completion ordering

In reply to Greg Kroah-Hartman

5.15-stable review patch. If anyone has any objections, please let me know.

------------------

From: William A. Kennington III <[email protected]>

[ Upstream commit 92e73d807b68b2214fcafca4e130b5300a9d4b3c ]

Sometimes, our completions race with new master transfers and override the bus->operation and bus->master_or_slave variables. This causes transactions to timeout and kernel crashes less frequently.

To remedy this, we re-order all completions to the very end of the function.

Fixes 56a1485b102e ("i2c: npcm7xx: Add Nuvoton NPCM I2C controller driver")
---
 drivers/i2c/busses/i2c-npcm7xx.c | 17 +++++++----------
 1 file changed, 7 insertions(+), 10 deletions(-)
drivers/i2c/busses/i2c-npcm7xx.c +7 -10
index c1b6797372409..73c808ef1bfe5 100644
@@ -675,6 +675,7 @@ static void npcm_i2c_callback(struct npcm_i2c *bus,
 {
 	struct i2c_msg *msgs;
 	int msgs_num;
+	bool do_complete = false;
 
 	msgs = bus->msgs;
 	msgs_num = bus->msgs_num;
@@ -701,23 +702,17 @@ static void npcm_i2c_callback(struct npcm_i2c *bus,
 				 msgs[1].flags & I2C_M_RD)
 				msgs[1].len = info;
 		}
-		if (completion_done(&bus->cmd_complete) == false)
-			complete(&bus->cmd_complete);
-	break;
-
+		do_complete = true;
+		break;
 	case I2C_NACK_IND:
 		/* MASTER transmit got a NACK before tx all bytes */
 		bus->cmd_err = -ENXIO;
-		if (bus->master_or_slave == I2C_MASTER)
-			complete(&bus->cmd_complete);
-
+		do_complete = true;
 		break;
 	case I2C_BUS_ERR_IND:
 		/* Bus error */
 		bus->cmd_err = -EAGAIN;
-		if (bus->master_or_slave == I2C_MASTER)
-			complete(&bus->cmd_complete);
-
+		do_complete = true;
 		break;
 	case I2C_WAKE_UP_IND:
 		/* I2C wake up */
@@ -731,6 +726,8 @@ static void npcm_i2c_callback(struct npcm_i2c *bus,
 	if (bus->slave)
 		bus->master_or_slave = I2C_SLAVE;
 #endif
+	if (do_complete)
+		complete(&bus->cmd_complete);
 }
 
 static u8 npcm_i2c_fifo_usage(struct npcm_i2c *bus)
Signature · 1 line
2.40.1
author maintainer
#110 lore raw

PATCH 110/183 dma-debug: dont call __dma_entry_alloc_check_leak() under free_entries_lock

In reply to Greg Kroah-Hartman

5.15-stable review patch. If anyone has any objections, please let me know.

------------------

From: Sergey Senozhatsky <[email protected]>

[ Upstream commit fb5a4315591dae307a65fc246ca80b5159d296e1 ]

__dma_entry_alloc_check_leak() calls into printk -> serial console output (qcom geni) and grabs port->lock under free_entries_lock spin lock, which is a reverse locking dependency chain as qcom_geni IRQ handler can call into dma-debug code and grab free_entries_lock under port->lock.

Move __dma_entry_alloc_check_leak() call out of free_entries_lock scope so that we don't acquire serial console's port->lock under it.

Trimmed-down lockdep splat:

The existing dependency chain (in reverse order) is:

               -> #2 (free_entries_lock){-.-.}-{2:2}:
        _raw_spin_lock_irqsave+0x60/0x80
        dma_entry_alloc+0x38/0x110
        debug_dma_map_page+0x60/0xf8
        dma_map_page_attrs+0x1e0/0x230
        dma_map_single_attrs.constprop.0+0x6c/0xc8
        geni_se_rx_dma_prep+0x40/0xcc
        qcom_geni_serial_isr+0x310/0x510
        __handle_irq_event_percpu+0x110/0x244
        handle_irq_event_percpu+0x20/0x54
        handle_irq_event+0x50/0x88
        handle_fasteoi_irq+0xa4/0xcc
        handle_irq_desc+0x28/0x40
        generic_handle_domain_irq+0x24/0x30
        gic_handle_irq+0xc4/0x148
        do_interrupt_handler+0xa4/0xb0
        el1_interrupt+0x34/0x64
        el1h_64_irq_handler+0x18/0x24
        el1h_64_irq+0x64/0x68
        arch_local_irq_enable+0x4/0x8
        ____do_softirq+0x18/0x24
        ...

               -> #1 (&port_lock_key){-.-.}-{2:2}:
        _raw_spin_lock_irqsave+0x60/0x80
        qcom_geni_serial_console_write+0x184/0x1dc
        console_flush_all+0x344/0x454
        console_unlock+0x94/0xf0
        vprintk_emit+0x238/0x24c
        vprintk_default+0x3c/0x48
        vprintk+0xb4/0xbc
        _printk+0x68/0x90
        register_console+0x230/0x38c
        uart_add_one_port+0x338/0x494
        qcom_geni_serial_probe+0x390/0x424
        platform_probe+0x70/0xc0
        really_probe+0x148/0x280
        __driver_probe_device+0xfc/0x114
        driver_probe_device+0x44/0x100
        __device_attach_driver+0x64/0xdc
        bus_for_each_drv+0xb0/0xd8
        __device_attach+0xe4/0x140
        device_initial_probe+0x1c/0x28
        bus_probe_device+0x44/0xb0
        device_add+0x538/0x668
        of_device_add+0x44/0x50
        of_platform_device_create_pdata+0x94/0xc8
        of_platform_bus_create+0x270/0x304
        of_platform_populate+0xac/0xc4
        devm_of_platform_populate+0x60/0xac
        geni_se_probe+0x154/0x160
        platform_probe+0x70/0xc0
        ...

               -> #0 (console_owner){-...}-{0:0}:
        __lock_acquire+0xdf8/0x109c
        lock_acquire+0x234/0x284
        console_flush_all+0x330/0x454
        console_unlock+0x94/0xf0
        vprintk_emit+0x238/0x24c
        vprintk_default+0x3c/0x48
        vprintk+0xb4/0xbc
        _printk+0x68/0x90
        dma_entry_alloc+0xb4/0x110
        debug_dma_map_sg+0xdc/0x2f8
        __dma_map_sg_attrs+0xac/0xe4
        dma_map_sgtable+0x30/0x4c
        get_pages+0x1d4/0x1e4 [msm]
        msm_gem_pin_pages_locked+0x38/0xac [msm]
        msm_gem_pin_vma_locked+0x58/0x88 [msm]
        msm_ioctl_gem_submit+0xde4/0x13ac [msm]
        drm_ioctl_kernel+0xe0/0x15c
        drm_ioctl+0x2e8/0x3f4
        vfs_ioctl+0x30/0x50
        ...
 Chain exists of:
   console_owner --> &port_lock_key --> free_entries_lock

  Possible unsafe locking scenario:
        CPU0                    CPU1
        ----                    ----
   lock(free_entries_lock);
                                lock(&port_lock_key);
                                lock(free_entries_lock);

lock(console_owner);

                *** DEADLOCK ***
 Call trace:
  dump_backtrace+0xb4/0xf0
  show_stack+0x20/0x30
  dump_stack_lvl+0x60/0x84
  dump_stack+0x18/0x24
  print_circular_bug+0x1cc/0x234
  check_noncircular+0x78/0xac
  __lock_acquire+0xdf8/0x109c
  lock_acquire+0x234/0x284
  console_flush_all+0x330/0x454
  console_unlock+0x94/0xf0
  vprintk_emit+0x238/0x24c
  vprintk_default+0x3c/0x48
  vprintk+0xb4/0xbc
  _printk+0x68/0x90
  dma_entry_alloc+0xb4/0x110
  debug_dma_map_sg+0xdc/0x2f8
  __dma_map_sg_attrs+0xac/0xe4
  dma_map_sgtable+0x30/0x4c
  get_pages+0x1d4/0x1e4 [msm]
  msm_gem_pin_pages_locked+0x38/0xac [msm]
  msm_gem_pin_vma_locked+0x58/0x88 [msm]
  msm_ioctl_gem_submit+0xde4/0x13ac [msm]
  drm_ioctl_kernel+0xe0/0x15c
  drm_ioctl+0x2e8/0x3f4
  vfs_ioctl+0x30/0x50
  ...
---
 kernel/dma/debug.c | 20 +++++++++++++++-----
 1 file changed, 15 insertions(+), 5 deletions(-)
kernel/dma/debug.c +15 -5
index 2caafd13f8aac..1f9a8cee42241 100644
@@ -605,15 +605,19 @@ static struct dma_debug_entry *__dma_entry_alloc(void)
 	return entry;
 }
 
-static void __dma_entry_alloc_check_leak(void)
+/*
+ * This should be called outside of free_entries_lock scope to avoid potential
+ * deadlocks with serial consoles that use DMA.
+ */
+static void __dma_entry_alloc_check_leak(u32 nr_entries)
 {
-	u32 tmp = nr_total_entries % nr_prealloc_entries;
+	u32 tmp = nr_entries % nr_prealloc_entries;
 
 	/* Shout each time we tick over some multiple of the initial pool */
 	if (tmp < DMA_DEBUG_DYNAMIC_ENTRIES) {
 		pr_info("dma_debug_entry pool grown to %u (%u00%%)\n",
-			nr_total_entries,
-			(nr_total_entries / nr_prealloc_entries));
+			nr_entries,
+			(nr_entries / nr_prealloc_entries));
 	}
 }
 
@@ -624,8 +628,10 @@ static void __dma_entry_alloc_check_leak(void)
  */
 static struct dma_debug_entry *dma_entry_alloc(void)
 {
+	bool alloc_check_leak = false;
 	struct dma_debug_entry *entry;
 	unsigned long flags;
+	u32 nr_entries;
 
 	spin_lock_irqsave(&free_entries_lock, flags);
 	if (num_free_entries == 0) {
@@ -635,13 +641,17 @@ static struct dma_debug_entry *dma_entry_alloc(void)
 			pr_err("debugging out of memory - disabling\n");
 			return NULL;
 		}
-		__dma_entry_alloc_check_leak();
+		alloc_check_leak = true;
+		nr_entries = nr_total_entries;
 	}
 
 	entry = __dma_entry_alloc();
 
 	spin_unlock_irqrestore(&free_entries_lock, flags);
 
+	if (alloc_check_leak)
+		__dma_entry_alloc_check_leak(nr_entries);
+
 #ifdef CONFIG_STACKTRACE
 	entry->stack_len = stack_trace_save(entry->stack_entries,
 					    ARRAY_SIZE(entry->stack_entries),
Signature · 1 line
2.40.1
author maintainer
#111 lore raw

PATCH 111/183 spi: sun6i: reduce DMA RX transfer width to single byte

In reply to Greg Kroah-Hartman

5.15-stable review patch. If anyone has any objections, please let me know.

------------------

From: Tobias Schramm <[email protected]>

[ Upstream commit 171f8a49f212e87a8b04087568e1b3d132e36a18 ]

Through empirical testing it has been determined that sometimes RX SPI transfers with DMA enabled return corrupted data. This is down to single or even multiple bytes lost during DMA transfer from SPI peripheral to memory. It seems the RX FIFO within the SPI peripheral can become confused when performing bus read accesses wider than a single byte to it during an active SPI transfer.

This patch reduces the width of individual DMA read accesses to the RX FIFO to a single byte to mitigate that issue.

---
 drivers/spi/spi-sun6i.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/spi/spi-sun6i.c +1 -1
index 23ad052528dbe..2bfe87873edb3 100644
@@ -200,7 +200,7 @@ static int sun6i_spi_prepare_dma(struct sun6i_spi *sspi,
 		struct dma_slave_config rxconf = {
 			.direction = DMA_DEV_TO_MEM,
 			.src_addr = sspi->dma_addr_rx,
-			.src_addr_width = DMA_SLAVE_BUSWIDTH_4_BYTES,
+			.src_addr_width = DMA_SLAVE_BUSWIDTH_1_BYTE,
 			.src_maxburst = 8,
 		};
 
Signature · 1 line
2.40.1
author maintainer
#112 lore raw

PATCH 112/183 spi: sun6i: fix race between DMA RX transfer completion and RX FIFO drain

In reply to Greg Kroah-Hartman

5.15-stable review patch. If anyone has any objections, please let me know.

------------------

From: Tobias Schramm <[email protected]>

[ Upstream commit 1f11f4202caf5710204d334fe63392052783876d ]

Previously the transfer complete IRQ immediately drained to RX FIFO to read any data remaining in FIFO to the RX buffer. This behaviour is correct when dealing with SPI in interrupt mode. However in DMA mode the transfer complete interrupt still fires as soon as all bytes to be transferred have been stored in the FIFO. At that point data in the FIFO still needs to be picked up by the DMA engine. Thus the drain procedure and DMA engine end up racing to read from RX FIFO, corrupting any data read. Additionally the RX buffer pointer is never adjusted according to DMA progress in DMA mode, thus calling the RX FIFO drain procedure in DMA mode is a bug.
Fix corruptions in DMA RX mode by draining RX FIFO only in interrupt mode. Also wait for completion of RX DMA when in DMA mode before returning to ensure all data has been copied to the supplied memory buffer.

---
 drivers/spi/spi-sun6i.c | 29 ++++++++++++++++++++++++++++-
 1 file changed, 28 insertions(+), 1 deletion(-)
drivers/spi/spi-sun6i.c +28 -1
index 2bfe87873edb3..d79853ba7792a 100644
@@ -95,6 +95,7 @@ struct sun6i_spi {
 	struct reset_control	*rstc;
 
 	struct completion	done;
+	struct completion	dma_rx_done;
 
 	const u8		*tx_buf;
 	u8			*rx_buf;
@@ -189,6 +190,13 @@ static size_t sun6i_spi_max_transfer_size(struct spi_device *spi)
 	return SUN6I_MAX_XFER_SIZE - 1;
 }
 
+static void sun6i_spi_dma_rx_cb(void *param)
+{
+	struct sun6i_spi *sspi = param;
+
+	complete(&sspi->dma_rx_done);
+}
+
 static int sun6i_spi_prepare_dma(struct sun6i_spi *sspi,
 				 struct spi_transfer *tfr)
 {
@@ -213,6 +221,8 @@ static int sun6i_spi_prepare_dma(struct sun6i_spi *sspi,
 						 DMA_PREP_INTERRUPT);
 		if (!rxdesc)
 			return -EINVAL;
+		rxdesc->callback_param = sspi;
+		rxdesc->callback = sun6i_spi_dma_rx_cb;
 	}
 
 	txdesc = NULL;
@@ -268,6 +278,7 @@ static int sun6i_spi_transfer_one(struct spi_master *master,
 		return -EINVAL;
 
 	reinit_completion(&sspi->done);
+	reinit_completion(&sspi->dma_rx_done);
 	sspi->tx_buf = tfr->tx_buf;
 	sspi->rx_buf = tfr->rx_buf;
 	sspi->len = tfr->len;
@@ -426,6 +437,22 @@ static int sun6i_spi_transfer_one(struct spi_master *master,
 	start = jiffies;
 	timeout = wait_for_completion_timeout(&sspi->done,
 					      msecs_to_jiffies(tx_time));
+
+	if (!use_dma) {
+		sun6i_spi_drain_fifo(sspi);
+	} else {
+		if (timeout && rx_len) {
+			/*
+			 * Even though RX on the peripheral side has finished
+			 * RX DMA might still be in flight
+			 */
+			timeout = wait_for_completion_timeout(&sspi->dma_rx_done,
+							      timeout);
+			if (!timeout)
+				dev_warn(&master->dev, "RX DMA timeout\n");
+		}
+	}
+
 	end = jiffies;
 	if (!timeout) {
 		dev_warn(&master->dev,
@@ -453,7 +480,6 @@ static irqreturn_t sun6i_spi_handler(int irq, void *dev_id)
 	/* Transfer complete */
 	if (status & SUN6I_INT_CTL_TC) {
 		sun6i_spi_write(sspi, SUN6I_INT_STA_REG, SUN6I_INT_CTL_TC);
-		sun6i_spi_drain_fifo(sspi);
 		complete(&sspi->done);
 		return IRQ_HANDLED;
 	}
@@ -611,6 +637,7 @@ static int sun6i_spi_probe(struct platform_device *pdev)
 	}
 
 	init_completion(&sspi->done);
+	init_completion(&sspi->dma_rx_done);
 
 	sspi->rstc = devm_reset_control_get_exclusive(&pdev->dev, NULL);
 	if (IS_ERR(sspi->rstc)) {
Signature · 1 line
2.40.1
author maintainer
#113 lore raw

PATCH 113/183 parisc: sba: Fix compile warning wrt list of SBA devices

In reply to Greg Kroah-Hartman

5.15-stable review patch. If anyone has any objections, please let me know.

------------------

From: Helge Deller <[email protected]>

[ Upstream commit eb3255ee8f6f4691471a28fbf22db5e8901116cd ]

Fix this makecheck warning:
drivers/parisc/sba_iommu.c:98:19: warning: symbol 'sba_list'
was not declared. Should it be static?

---
 arch/parisc/include/asm/ropes.h | 3 +++
 drivers/char/agp/parisc-agp.c   | 2 --
 2 files changed, 3 insertions(+), 2 deletions(-)
arch/parisc/include/asm/ropes.h +3 -0
index 8e51c775c80a6..62399c7ea94a1 100644
@@ -86,6 +86,9 @@ struct sba_device {
 	struct ioc		ioc[MAX_IOC];
 };
 
+/* list of SBA's in system, see drivers/parisc/sba_iommu.c */
+extern struct sba_device *sba_list;
+
 #define ASTRO_RUNWAY_PORT	0x582
 #define IKE_MERCED_PORT		0x803
 #define REO_MERCED_PORT		0x804
drivers/char/agp/parisc-agp.c +0 -2
index 514f9f287a781..c6f181702b9a7 100644
@@ -394,8 +394,6 @@ find_quicksilver(struct device *dev, void *data)
 static int __init
 parisc_agp_init(void)
 {
-	extern struct sba_device *sba_list;
-
 	int err = -1;
 	struct parisc_device *sba = NULL, *lba = NULL;
 	struct lba_device *lbadev = NULL;
Signature · 1 line
2.40.1
author maintainer
#114 lore raw

PATCH 114/183 parisc: iosapic.c: Fix sparse warnings

In reply to Greg Kroah-Hartman

5.15-stable review patch. If anyone has any objections, please let me know.

------------------

From: Helge Deller <[email protected]>

[ Upstream commit 927c6c8aa27c284a799b8c18784e37d3373af908 ]

---
 drivers/parisc/iosapic.c         | 4 ++--
 drivers/parisc/iosapic_private.h | 4 ++--
 2 files changed, 4 insertions(+), 4 deletions(-)
drivers/parisc/iosapic.c +2 -2
index 93ea922618c3d..56562ae99f683 100644
@@ -202,9 +202,9 @@ static inline void iosapic_write(void __iomem *iosapic, unsigned int reg, u32 va
 
 static DEFINE_SPINLOCK(iosapic_lock);
 
-static inline void iosapic_eoi(void __iomem *addr, unsigned int data)
+static inline void iosapic_eoi(__le32 __iomem *addr, __le32 data)
 {
-	__raw_writel(data, addr);
+	__raw_writel((__force u32)data, addr);
 }
 
 /*
drivers/parisc/iosapic_private.h +2 -2
index 73ecc657ad954..bd8ff40162b4b 100644
@@ -118,8 +118,8 @@ struct iosapic_irt {
 struct vector_info {
 	struct iosapic_info *iosapic;	/* I/O SAPIC this vector is on */
 	struct irt_entry *irte;		/* IRT entry */
-	u32 __iomem *eoi_addr;		/* precalculate EOI reg address */
-	u32	eoi_data;		/* IA64: ?       PA: swapped txn_data */
+	__le32 __iomem *eoi_addr;	/* precalculate EOI reg address */
+	__le32	eoi_data;		/* IA64: ?       PA: swapped txn_data */
 	int	txn_irq;		/* virtual IRQ number for processor */
 	ulong	txn_addr;		/* IA64: id_eid  PA: partial HPA */
 	u32	txn_data;		/* CPU interrupt bit */
Signature · 1 line
2.40.1
author maintainer
#115 lore raw

PATCH 115/183 parisc: drivers: Fix sparse warning

In reply to Greg Kroah-Hartman

5.15-stable review patch. If anyone has any objections, please let me know.

------------------

From: Helge Deller <[email protected]>

[ Upstream commit b137b9d60b8add5620a06c687a71ce18776730b0 ]

Fix "warning: directive in macro's argument list" warning.

---
 arch/parisc/kernel/drivers.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
arch/parisc/kernel/drivers.c +1 -1
index e7ee0c0c91d35..8f12b9f318ae6 100644
@@ -924,9 +924,9 @@ static __init void qemu_header(void)
 	pr_info("#define PARISC_MODEL \"%s\"\n\n",
 			boot_cpu_data.pdc.sys_model_name);
 
+	#define p ((unsigned long *)&boot_cpu_data.pdc.model)
 	pr_info("#define PARISC_PDC_MODEL 0x%lx, 0x%lx, 0x%lx, "
 		"0x%lx, 0x%lx, 0x%lx, 0x%lx, 0x%lx, 0x%lx\n\n",
-	#define p ((unsigned long *)&boot_cpu_data.pdc.model)
 		p[0], p[1], p[2], p[3], p[4], p[5], p[6], p[7], p[8]);
 	#undef p
 
Signature · 1 line
2.40.1
author maintainer
#116 lore raw

PATCH 116/183 parisc: irq: Make irq_stack_union static to avoid sparse warning

In reply to Greg Kroah-Hartman

5.15-stable review patch. If anyone has any objections, please let me know.

------------------

From: Helge Deller <[email protected]>

[ Upstream commit b1bef1388c427cdad7331a9c8eb4ebbbe5b954b0 ]

---
 arch/parisc/kernel/irq.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
arch/parisc/kernel/irq.c +1 -1
index e6cc38ef69458..5d9044e65a1a6 100644
@@ -386,7 +386,7 @@ union irq_stack_union {
 	volatile unsigned int lock[1];
 };
 
-DEFINE_PER_CPU(union irq_stack_union, irq_stack_union) = {
+static DEFINE_PER_CPU(union irq_stack_union, irq_stack_union) = {
 		.slock = { 1,1,1,1 },
 	};
 #endif
Signature · 1 line
2.40.1
author maintainer
#117 lore raw

PATCH 117/183 scsi: qedf: Add synchronization between I/O completions and abort

In reply to Greg Kroah-Hartman

5.15-stable review patch. If anyone has any objections, please let me know.

------------------

From: Javed Hasan <[email protected]>

[ Upstream commit 7df0b2605489bef3f4223ad66f1f9bb8d50d4cd2 ]

Avoid race condition between I/O completion and abort processing by protecting the cmd_type with the rport lock.

---
 drivers/scsi/qedf/qedf_io.c   | 10 ++++++++--
 drivers/scsi/qedf/qedf_main.c |  7 ++++++-
 2 files changed, 14 insertions(+), 3 deletions(-)
drivers/scsi/qedf/qedf_io.c +8 -2
index bb5761ed3f511..a1a1f4e466609 100644
@@ -1913,6 +1913,7 @@ int qedf_initiate_abts(struct qedf_ioreq *io_req, bool return_scsi_cmd_on_abts)
 		goto drop_rdata_kref;
 	}
 
+	spin_lock_irqsave(&fcport->rport_lock, flags);
 	if (!test_bit(QEDF_CMD_OUTSTANDING, &io_req->flags) ||
 	    test_bit(QEDF_CMD_IN_CLEANUP, &io_req->flags) ||
 	    test_bit(QEDF_CMD_IN_ABORT, &io_req->flags)) {
@@ -1920,17 +1921,20 @@ int qedf_initiate_abts(struct qedf_ioreq *io_req, bool return_scsi_cmd_on_abts)
 			 "io_req xid=0x%x sc_cmd=%p already in cleanup or abort processing or already completed.\n",
 			 io_req->xid, io_req->sc_cmd);
 		rc = 1;
+		spin_unlock_irqrestore(&fcport->rport_lock, flags);
 		goto drop_rdata_kref;
 	}
 
+	/* Set the command type to abort */
+	io_req->cmd_type = QEDF_ABTS;
+	spin_unlock_irqrestore(&fcport->rport_lock, flags);
+
 	kref_get(&io_req->refcount);
 
 	xid = io_req->xid;
 	qedf->control_requests++;
 	qedf->packet_aborts++;
 
-	/* Set the command type to abort */
-	io_req->cmd_type = QEDF_ABTS;
 	io_req->return_scsi_cmd_on_abts = return_scsi_cmd_on_abts;
 
 	set_bit(QEDF_CMD_IN_ABORT, &io_req->flags);
@@ -2219,7 +2223,9 @@ int qedf_initiate_cleanup(struct qedf_ioreq *io_req,
 		  refcount, fcport, fcport->rdata->ids.port_id);
 
 	/* Cleanup cmds re-use the same TID as the original I/O */
+	spin_lock_irqsave(&fcport->rport_lock, flags);
 	io_req->cmd_type = QEDF_CLEANUP;
+	spin_unlock_irqrestore(&fcport->rport_lock, flags);
 	io_req->return_scsi_cmd_on_abts = return_scsi_cmd_on_abts;
 
 	init_completion(&io_req->cleanup_done);
drivers/scsi/qedf/qedf_main.c +6 -1
index 61959dd2237fc..18380a932ab61 100644
@@ -2807,6 +2807,8 @@ void qedf_process_cqe(struct qedf_ctx *qedf, struct fcoe_cqe *cqe)
 	struct qedf_ioreq *io_req;
 	struct qedf_rport *fcport;
 	u32 comp_type;
+	u8 io_comp_type;
+	unsigned long flags;
 
 	comp_type = (cqe->cqe_data >> FCOE_CQE_CQE_TYPE_SHIFT) &
 	    FCOE_CQE_CQE_TYPE_MASK;
@@ -2840,11 +2842,14 @@ void qedf_process_cqe(struct qedf_ctx *qedf, struct fcoe_cqe *cqe)
 		return;
 	}
 
+	spin_lock_irqsave(&fcport->rport_lock, flags);
+	io_comp_type = io_req->cmd_type;
+	spin_unlock_irqrestore(&fcport->rport_lock, flags);
 
 	switch (comp_type) {
 	case FCOE_GOOD_COMPLETION_CQE_TYPE:
 		atomic_inc(&fcport->free_sqes);
-		switch (io_req->cmd_type) {
+		switch (io_comp_type) {
 		case QEDF_SCSI_CMD:
 			qedf_scsi_completion(qedf, cqe, io_req);
 			break;
Signature · 1 line
2.40.1
author maintainer
#118 lore raw

PATCH 118/183 scsi: ufs: core: Move __ufshcd_send_uic_cmd() outside host_lock

In reply to Greg Kroah-Hartman

5.15-stable review patch. If anyone has any objections, please let me know.

------------------

From: Kiwoong Kim <[email protected]>

[ Upstream commit 2d3f59cf868b4a2dd678a96cd49bdd91411bd59f ]

__ufshcd_send_uic_cmd() is wrapped by uic_cmd_mutex and its related contexts are accessed within the section wrapped by uic_cmd_mutex. Thus, wrapping with host_lock is redundant.

---
 drivers/scsi/ufs/ufshcd.c | 6 +-----
 1 file changed, 1 insertion(+), 5 deletions(-)
drivers/scsi/ufs/ufshcd.c +1 -5
index d00d263705e15..f48036f09eab5 100644
@@ -2309,7 +2309,6 @@ __ufshcd_send_uic_cmd(struct ufs_hba *hba, struct uic_command *uic_cmd,
 		      bool completion)
 {
 	lockdep_assert_held(&hba->uic_cmd_mutex);
-	lockdep_assert_held(hba->host->host_lock);
 
 	if (!ufshcd_ready_for_uic_cmd(hba)) {
 		dev_err(hba->dev,
@@ -2336,15 +2335,12 @@ __ufshcd_send_uic_cmd(struct ufs_hba *hba, struct uic_command *uic_cmd,
 int ufshcd_send_uic_cmd(struct ufs_hba *hba, struct uic_command *uic_cmd)
 {
 	int ret;
-	unsigned long flags;
 
 	ufshcd_hold(hba, false);
 	mutex_lock(&hba->uic_cmd_mutex);
 	ufshcd_add_delay_before_dme_cmd(hba);
 
-	spin_lock_irqsave(hba->host->host_lock, flags);
 	ret = __ufshcd_send_uic_cmd(hba, uic_cmd, true);
-	spin_unlock_irqrestore(hba->host->host_lock, flags);
 	if (!ret)
 		ret = ufshcd_wait_for_uic_cmd(hba, uic_cmd);
 
@@ -3967,8 +3963,8 @@ static int ufshcd_uic_pwr_ctrl(struct ufs_hba *hba, struct uic_command *cmd)
 		wmb();
 		reenable_intr = true;
 	}
-	ret = __ufshcd_send_uic_cmd(hba, cmd, false);
 	spin_unlock_irqrestore(hba->host->host_lock, flags);
+	ret = __ufshcd_send_uic_cmd(hba, cmd, false);
 	if (ret) {
 		dev_err(hba->dev,
 			"pwr ctrl cmd 0x%x with mode 0x%x uic error %d\n",
Signature · 1 line
2.40.1
author maintainer
#119 lore raw

PATCH 119/183 selftests/ftrace: Correctly enable event in instance-event.tc

In reply to Greg Kroah-Hartman

5.15-stable review patch. If anyone has any objections, please let me know.

------------------

From: Zheng Yejian <[email protected]>

[ Upstream commit f4e4ada586995b17f828c6d147d1800eb1471450 ]

Function instance_set() expects to enable event 'sched_switch', so we should set 1 to its 'enable' file.

Testcase passed after this patch:

  # ./ftracetest test.d/instances/instance-event.tc
  === Ftrace unit tests ===
  [1] Test creation and deletion of trace instances while setting an event
  [PASS]
  # of passed:  1
  # of failed:  0
  # of unresolved:  0
  # of untested:  0
  # of unsupported:  0
  # of xfailed:  0
  # of undefined(test bug):  0
---
 .../testing/selftests/ftrace/test.d/instances/instance-event.tc | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
tools/testing/selftests/ftrace/test.d/instances/instance-event.tc +1 -1
index 0eb47fbb3f44d..42422e4251078 100644
@@ -39,7 +39,7 @@ instance_read() {
 
 instance_set() {
         while :; do
-                echo 1 > foo/events/sched/sched_switch
+                echo 1 > foo/events/sched/sched_switch/enable
         done 2> /dev/null
 }
 
Signature · 1 line
2.40.1
author maintainer
#120 lore raw

PATCH 120/183 ring-buffer: Avoid softlockup in ring_buffer_resize()

In reply to Greg Kroah-Hartman

5.15-stable review patch. If anyone has any objections, please let me know.

------------------

From: Zheng Yejian <[email protected]>

[ Upstream commit f6bd2c92488c30ef53b5bd80c52f0a7eee9d545a ]

When user resize all trace ring buffer through file 'buffer_size_kb', then in ring_buffer_resize(), kernel allocates buffer pages for each cpu in a loop.

If the kernel preemption model is PREEMPT_NONE and there are many cpus and there are many buffer pages to be allocated, it may not give up cpu for a long time and finally cause a softlockup.

To avoid it, call cond_resched() after each cpu buffer allocation.

---
 kernel/trace/ring_buffer.c | 2 ++
 1 file changed, 2 insertions(+)
kernel/trace/ring_buffer.c +2 -0
index db7cefd196cec..b15d72284c7f7 100644
@@ -2176,6 +2176,8 @@ int ring_buffer_resize(struct trace_buffer *buffer, unsigned long size,
 				err = -ENOMEM;
 				goto out_err;
 			}
+
+			cond_resched();
 		}
 
 		cpus_read_lock();
Signature · 1 line
2.40.1
author maintainer
#121 lore raw

PATCH 121/183 btrfs: improve error message after failure to add delayed dir index item

In reply to Greg Kroah-Hartman

5.15-stable review patch. If anyone has any objections, please let me know.

------------------

From: Filipe Manana <[email protected]>

[ Upstream commit 91bfe3104b8db0310f76f2dcb6aacef24c889366 ]

If we fail to add a delayed dir index item because there's already another item with the same index number, we print an error message (and then BUG). However that message isn't very helpful to debug anything because we don't know what's the index number and what are the values of index counters in the inode and its delayed inode (index_cnt fields of struct btrfs_inode and struct btrfs_delayed_node).

So update the error message to include the index number and counters.

We actually had a recent case where this issue was hit by a syzbot report (see the link below).

---
 fs/btrfs/delayed-inode.c | 7 ++++---
 1 file changed, 4 insertions(+), 3 deletions(-)
fs/btrfs/delayed-inode.c +4 -3
index e6872d65c0e25..fd951aeaeac5a 100644
@@ -1401,9 +1401,10 @@ int btrfs_insert_delayed_dir_index(struct btrfs_trans_handle *trans,
 	ret = __btrfs_add_delayed_insertion_item(delayed_node, delayed_item);
 	if (unlikely(ret)) {
 		btrfs_err(trans->fs_info,
-			  "err add delayed dir index item(name: %.*s) into the insertion tree of the delayed node(root id: %llu, inode id: %llu, errno: %d)",
-			  name_len, name, delayed_node->root->root_key.objectid,
-			  delayed_node->inode_id, ret);
+"error adding delayed dir index item, name: %.*s, index: %llu, root: %llu, dir: %llu, dir->index_cnt: %llu, delayed_node->index_cnt: %llu, error: %d",
+			  name_len, name, index, btrfs_root_id(delayed_node->root),
+			  delayed_node->inode_id, dir->index_cnt,
+			  delayed_node->index_cnt, ret);
 		BUG();
 	}
 	mutex_unlock(&delayed_node->mutex);
Signature · 1 line
2.40.1
author maintainer
#122 lore raw

PATCH 122/183 selftests: fix dependency checker script

In reply to Greg Kroah-Hartman

5.15-stable review patch. If anyone has any objections, please let me know.

------------------

From: Ricardo B. Marliere <[email protected]>

[ Upstream commit 5f9dd2e896a91bfca90f8463eb6808c03d535d8a ]

This patch fixes inconsistencies in the parsing rules of the levels 1 and 2 of the kselftest_deps.sh. It was added the levels 4 and 5 to account for a few edge cases that are present in some tests, also some
minor identation styling have been fixed (s/ /\t/g).

---
 tools/testing/selftests/kselftest_deps.sh | 77 +++++++++++++++++++----
 1 file changed, 65 insertions(+), 12 deletions(-)
tools/testing/selftests/kselftest_deps.sh +65 -12
index 00e60d6eb16bc..7e51f4a373d35 100755
@@ -46,11 +46,11 @@ fi
 print_targets=0
 
 while getopts "p" arg; do
-    case $arg in
-        p)
+	case $arg in
+		p)
 		print_targets=1
 	shift;;
-    esac
+	esac
 done
 
 if [ $# -eq 0 ]
@@ -92,6 +92,10 @@ pass_cnt=0
 # Get all TARGETS from selftests Makefile
 targets=$(egrep "^TARGETS +|^TARGETS =" Makefile | cut -d "=" -f2)
 
+# Initially, in LDLIBS related lines, the dep checker needs
+# to ignore lines containing the following strings:
+filter="\$(VAR_LDLIBS)\|pkg-config\|PKG_CONFIG\|IOURING_EXTRA_LIBS"
+
 # Single test case
 if [ $# -eq 2 ]
 then
@@ -100,6 +104,8 @@ then
 	l1_test $test
 	l2_test $test
 	l3_test $test
+	l4_test $test
+	l5_test $test
 
 	print_results $1 $2
 	exit $?
@@ -113,7 +119,7 @@ fi
 # Append space at the end of the list to append more tests.
 
 l1_tests=$(grep -r --include=Makefile "^LDLIBS" | \
-		grep -v "VAR_LDLIBS" | awk -F: '{print $1}')
+		grep -v "$filter" | awk -F: '{print $1}' | uniq)
 
 # Level 2: LDLIBS set dynamically.
 #
@@ -126,7 +132,7 @@ l1_tests=$(grep -r --include=Makefile "^LDLIBS" | \
 # Append space at the end of the list to append more tests.
 
 l2_tests=$(grep -r --include=Makefile ": LDLIBS" | \
-		grep -v "VAR_LDLIBS" | awk -F: '{print $1}')
+		grep -v "$filter" | awk -F: '{print $1}' | uniq)
 
 # Level 3
 # memfd and others use pkg-config to find mount and fuse libs
@@ -138,11 +144,32 @@ l2_tests=$(grep -r --include=Makefile ": LDLIBS" | \
 #	VAR_LDLIBS := $(shell pkg-config fuse --libs 2>/dev/null)
 
 l3_tests=$(grep -r --include=Makefile "^VAR_LDLIBS" | \
-		grep -v "pkg-config" | awk -F: '{print $1}')
+		grep -v "pkg-config\|PKG_CONFIG" | awk -F: '{print $1}' | uniq)
 
-#echo $l1_tests
-#echo $l2_1_tests
-#echo $l3_tests
+# Level 4
+# some tests may fall back to default using `|| echo -l<libname>`
+# if pkg-config doesn't find the libs, instead of using VAR_LDLIBS
+# as per level 3 checks.
+# e.g:
+# netfilter/Makefile
+#	LDLIBS += $(shell $(HOSTPKG_CONFIG) --libs libmnl 2>/dev/null || echo -lmnl)
+l4_tests=$(grep -r --include=Makefile "^LDLIBS" | \
+		grep "pkg-config\|PKG_CONFIG" | awk -F: '{print $1}' | uniq)
+
+# Level 5
+# some tests may use IOURING_EXTRA_LIBS to add extra libs to LDLIBS,
+# which in turn may be defined in a sub-Makefile
+# e.g.:
+# mm/Makefile
+#	$(OUTPUT)/gup_longterm: LDLIBS += $(IOURING_EXTRA_LIBS)
+l5_tests=$(grep -r --include=Makefile "LDLIBS +=.*\$(IOURING_EXTRA_LIBS)" | \
+	awk -F: '{print $1}' | uniq)
+
+#echo l1_tests $l1_tests
+#echo l2_tests $l2_tests
+#echo l3_tests $l3_tests
+#echo l4_tests $l4_tests
+#echo l5_tests $l5_tests
 
 all_tests
 print_results $1 $2
@@ -164,24 +191,32 @@ all_tests()
 	for test in $l3_tests; do
 		l3_test $test
 	done
+
+	for test in $l4_tests; do
+		l4_test $test
+	done
+
+	for test in $l5_tests; do
+		l5_test $test
+	done
 }
 
 # Use same parsing used for l1_tests and pick libraries this time.
 l1_test()
 {
 	test_libs=$(grep --include=Makefile "^LDLIBS" $test | \
-			grep -v "VAR_LDLIBS" | \
+			grep -v "$filter" | \
 			sed -e 's/\:/ /' | \
 			sed -e 's/+/ /' | cut -d "=" -f 2)
 
 	check_libs $test $test_libs
 }
 
-# Use same parsing used for l2__tests and pick libraries this time.
+# Use same parsing used for l2_tests and pick libraries this time.
 l2_test()
 {
 	test_libs=$(grep --include=Makefile ": LDLIBS" $test | \
-			grep -v "VAR_LDLIBS" | \
+			grep -v "$filter" | \
 			sed -e 's/\:/ /' | sed -e 's/+/ /' | \
 			cut -d "=" -f 2)
 
@@ -197,6 +232,24 @@ l3_test()
 	check_libs $test $test_libs
 }
 
+l4_test()
+{
+	test_libs=$(grep --include=Makefile "^VAR_LDLIBS\|^LDLIBS" $test | \
+			grep "\(pkg-config\|PKG_CONFIG\).*|| echo " | \
+			sed -e 's/.*|| echo //' | sed -e 's/)$//')
+
+	check_libs $test $test_libs
+}
+
+l5_test()
+{
+	tests=$(find $(dirname "$test") -type f -name "*.mk")
+	test_libs=$(grep "^IOURING_EXTRA_LIBS +\?=" $tests | \
+			cut -d "=" -f 2)
+
+	check_libs $test $test_libs
+}
+
 check_libs()
 {
 
Signature · 1 line
2.40.1
author maintainer
#123 lore raw

PATCH 123/183 ring-buffer: Do not attempt to read past "commit"

In reply to Greg Kroah-Hartman

5.15-stable review patch. If anyone has any objections, please let me know.

------------------

From: Steven Rostedt (Google) <[email protected]>

[ Upstream commit 95a404bd60af6c4d9d8db01ad14fe8957ece31ca ]

When iterating over the ring buffer while the ring buffer is active, the writer can corrupt the reader. There's barriers to help detect this and handle it, but that code missed the case where the last event was at the very end of the page and has only 4 bytes left.

The checks to detect the corruption by the writer to reads needs to see the length of the event. If the length in the first 4 bytes is zero then the length is stored in the second 4 bytes. But if the writer is in the process of updating that code, there's a small window where the length in the first 4 bytes could be zero even though the length is only 4 bytes. That will cause rb_event_length() to read the next 4 bytes which could happen to be off the allocated page.

To protect against this, fail immediately if the next event pointer is less than 8 bytes from the end of the commit (last byte of data), as all events must be a minimum of 8 bytes anyway.

---
 kernel/trace/ring_buffer.c | 5 +++++
 1 file changed, 5 insertions(+)
kernel/trace/ring_buffer.c +5 -0
index b15d72284c7f7..69db849ae7dad 100644
@@ -2352,6 +2352,11 @@ rb_iter_head_event(struct ring_buffer_iter *iter)
 	 */
 	commit = rb_page_commit(iter_head_page);
 	smp_rmb();
+
+	/* An event needs to be at least 8 bytes in size */
+	if (iter->head > commit - 8)
+		goto reset;
+
 	event = __rb_page_index(iter_head_page, iter->head);
 	length = rb_event_length(event);
 
Signature · 1 line
2.40.1
author maintainer
#124 lore raw

PATCH 124/183 platform/mellanox: mlxbf-bootctl: add NET dependency into Kconfig

In reply to Greg Kroah-Hartman

5.15-stable review patch. If anyone has any objections, please let me know.

------------------

From: David Thompson <[email protected]>

[ Upstream commit c2dffda1d8f7511505bbbf16ba282f2079b30089 ]

The latest version of the mlxbf_bootctl driver utilizes "sysfs_format_mac", and this API is only available if NET is defined in the kernel configuration. This patch changes the mlxbf_bootctl Kconfig to depend on NET.

---
 drivers/platform/mellanox/Kconfig | 1 +
 1 file changed, 1 insertion(+)
drivers/platform/mellanox/Kconfig +1 -0
index edd17e1a1f88f..a57ae5cbc00a8 100644
@@ -48,6 +48,7 @@ config MLXBF_BOOTCTL
 	tristate "Mellanox BlueField Firmware Boot Control driver"
 	depends on ARM64
 	depends on ACPI
+	depends on NET
 	help
 	  The Mellanox BlueField firmware implements functionality to
 	  request swapping the primary and alternate eMMC boot partition,
Signature · 1 line
2.40.1
author maintainer
#125 lore raw

PATCH 125/183 drm/amd/display: Dont check registers, if using AUX BL control

In reply to Greg Kroah-Hartman

5.15-stable review patch. If anyone has any objections, please let me know.

------------------

From: Swapnil Patel <[email protected]>

[ Upstream commit f5b2c10b57615828b531bb0ae56bd6325a41167e ]

[Why]
Currently the driver looks DCN registers to access if BL is on or not. This check is not valid if we are using AUX based brightness control. This causes driver to not send out "backlight off" command during power off sequence as it already thinks it is off.

[How]
Only check DCN registers if we aren't using AUX based brightness control.

---
 drivers/gpu/drm/amd/display/dc/dce110/dce110_hw_sequencer.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)
drivers/gpu/drm/amd/display/dc/dce110/dce110_hw_sequencer.c +3 -1
index 52142d272c868..87825818d43ec 100644
@@ -980,7 +980,9 @@ void dce110_edp_backlight_control(
 		return;
 	}
 
-	if (link->panel_cntl) {
+	if (link->panel_cntl && !(link->dpcd_sink_ext_caps.bits.oled ||
+		link->dpcd_sink_ext_caps.bits.hdr_aux_backlight_control == 1 ||
+		link->dpcd_sink_ext_caps.bits.sdr_aux_backlight_control == 1)) {
 		bool is_backlight_on = link->panel_cntl->funcs->is_panel_backlight_on(link->panel_cntl);
 
 		if ((enable && is_backlight_on) || (!enable && !is_backlight_on)) {
Signature · 1 line
2.40.1
author maintainer
#126 lore raw

PATCH 126/183 drm/amdgpu: Handle null atom context in VBIOS info ioctl

In reply to Greg Kroah-Hartman

5.15-stable review patch. If anyone has any objections, please let me know.

------------------

From: David Francis <[email protected]>

[ Upstream commit 5e7e82254270c8cf8b107451c5de01cee2f135ae ]

On some APU systems, there is no atom context and so the atom_context struct is null.

Add a check to the VBIOS_INFO branch of amdgpu_info_ioctl to handle this case, returning all zeroes.

---
 drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c | 17 +++++++++++------
 1 file changed, 11 insertions(+), 6 deletions(-)
drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c +11 -6
index e8485b1f02ed6..70d49b998ee9e 100644
@@ -926,12 +926,17 @@ int amdgpu_info_ioctl(struct drm_device *dev, void *data, struct drm_file *filp)
 			struct atom_context *atom_context;
 
 			atom_context = adev->mode_info.atom_context;
-			memcpy(vbios_info.name, atom_context->name, sizeof(atom_context->name));
-			memcpy(vbios_info.vbios_pn, atom_context->vbios_pn, sizeof(atom_context->vbios_pn));
-			vbios_info.version = atom_context->version;
-			memcpy(vbios_info.vbios_ver_str, atom_context->vbios_ver_str,
-						sizeof(atom_context->vbios_ver_str));
-			memcpy(vbios_info.date, atom_context->date, sizeof(atom_context->date));
+			if (atom_context) {
+				memcpy(vbios_info.name, atom_context->name,
+				       sizeof(atom_context->name));
+				memcpy(vbios_info.vbios_pn, atom_context->vbios_pn,
+				       sizeof(atom_context->vbios_pn));
+				vbios_info.version = atom_context->version;
+				memcpy(vbios_info.vbios_ver_str, atom_context->vbios_ver_str,
+				       sizeof(atom_context->vbios_ver_str));
+				memcpy(vbios_info.date, atom_context->date,
+				       sizeof(atom_context->date));
+			}
 
 			return copy_to_user(out, &vbios_info,
 						min((size_t)size, sizeof(vbios_info))) ? -EFAULT : 0;
Signature · 1 line
2.40.1
author maintainer
#127 lore raw

PATCH 127/183 scsi: pm80xx: Use phy-specific SAS address when sending PHY_START command

In reply to Greg Kroah-Hartman

5.15-stable review patch. If anyone has any objections, please let me know.

------------------

From: Michal Grzedzicki <[email protected]>

[ Upstream commit 71996bb835aed58c7ec4967be1d05190a27339ec ]

Some cards have more than one SAS address. Using an incorrect address causes communication issues with some devices like expanders.

---
 drivers/scsi/pm8001/pm8001_hwi.c | 2 +-
 drivers/scsi/pm8001/pm80xx_hwi.c | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)
drivers/scsi/pm8001/pm8001_hwi.c +1 -1
index 32fc450bf84b4..352705e023c83 100644
@@ -4402,7 +4402,7 @@ pm8001_chip_phy_start_req(struct pm8001_hba_info *pm8001_ha, u8 phy_id)
 	payload.sas_identify.dev_type = SAS_END_DEVICE;
 	payload.sas_identify.initiator_bits = SAS_PROTOCOL_ALL;
 	memcpy(payload.sas_identify.sas_addr,
-		pm8001_ha->sas_addr, SAS_ADDR_SIZE);
+		&pm8001_ha->phy[phy_id].dev_sas_addr, SAS_ADDR_SIZE);
 	payload.sas_identify.phy_id = phy_id;
 	ret = pm8001_mpi_build_cmd(pm8001_ha, circularQ, opcode, &payload,
 			sizeof(payload), 0);
drivers/scsi/pm8001/pm80xx_hwi.c +1 -1
index 04746df26c6c9..ea305d093c871 100644
@@ -4814,7 +4814,7 @@ pm80xx_chip_phy_start_req(struct pm8001_hba_info *pm8001_ha, u8 phy_id)
 	payload.sas_identify.dev_type = SAS_END_DEVICE;
 	payload.sas_identify.initiator_bits = SAS_PROTOCOL_ALL;
 	memcpy(payload.sas_identify.sas_addr,
-	  &pm8001_ha->sas_addr, SAS_ADDR_SIZE);
+		&pm8001_ha->phy[phy_id].dev_sas_addr, SAS_ADDR_SIZE);
 	payload.sas_identify.phy_id = phy_id;
 	ret = pm8001_mpi_build_cmd(pm8001_ha, circularQ, opcode, &payload,
 			sizeof(payload), 0);
Signature · 1 line
2.40.1
author maintainer
#128 lore raw

PATCH 128/183 scsi: pm80xx: Avoid leaking tags when processing OPC_INB_SET_CONTROLLER_CONFIG command

In reply to Greg Kroah-Hartman

5.15-stable review patch. If anyone has any objections, please let me know.

------------------

From: Michal Grzedzicki <[email protected]>

[ Upstream commit c13e7331745852d0dd7c35eabbe181cbd5b01172 ]

Tags allocated for OPC_INB_SET_CONTROLLER_CONFIG command need to be freed when we receive the response.

---
 drivers/scsi/pm8001/pm80xx_hwi.c | 2 ++
 1 file changed, 2 insertions(+)
drivers/scsi/pm8001/pm80xx_hwi.c +2 -0
index ea305d093c871..d37b1bdb29b49 100644
@@ -3793,10 +3793,12 @@ static int mpi_set_controller_config_resp(struct pm8001_hba_info *pm8001_ha,
 			(struct set_ctrl_cfg_resp *)(piomb + 4);
 	u32 status = le32_to_cpu(pPayload->status);
 	u32 err_qlfr_pgcd = le32_to_cpu(pPayload->err_qlfr_pgcd);
+	u32 tag = le32_to_cpu(pPayload->tag);
 
 	pm8001_dbg(pm8001_ha, MSG,
 		   "SET CONTROLLER RESP: status 0x%x qlfr_pgcd 0x%x\n",
 		   status, err_qlfr_pgcd);
+	pm8001_tag_free(pm8001_ha, tag);
 
 	return 0;
 }
Signature · 1 line
2.40.1
author maintainer
#129 lore raw

PATCH 129/183 smb3: correct places where ENOTSUPP is used instead of preferred EOPNOTSUPP

In reply to Greg Kroah-Hartman

5.15-stable review patch. If anyone has any objections, please let me know.

------------------

From: Steve French <[email protected]>

[ Upstream commit ebc3d4e44a7e05457825e03d0560153687265523 ]

checkpatch flagged a few places with:
WARNING: ENOTSUPP is not a SUSV4 error code, prefer EOPNOTSUPP
Also fixed minor typo

---
 fs/cifs/inode.c   | 2 +-
 fs/cifs/smb2ops.c | 6 +++---
 2 files changed, 4 insertions(+), 4 deletions(-)
fs/cifs/inode.c +1 -1
index 82848412ad852..30a9a89c141bb 100644
@@ -2531,7 +2531,7 @@ int cifs_fiemap(struct inode *inode, struct fiemap_extent_info *fei, u64 start,
 	}
 
 	cifsFileInfo_put(cfile);
-	return -ENOTSUPP;
+	return -EOPNOTSUPP;
 }
 
 int cifs_truncate_page(struct address_space *mapping, loff_t from)
fs/cifs/smb2ops.c +3 -3
index 560c4ababfe1a..d8ce079ba9091 100644
@@ -266,7 +266,7 @@ smb2_adjust_credits(struct TCP_Server_Info *server,
 		cifs_server_dbg(VFS, "request has less credits (%d) than required (%d)",
 				credits->value, new_val);
 
-		return -ENOTSUPP;
+		return -EOPNOTSUPP;
 	}
 
 	spin_lock(&server->req_lock);
@@ -1308,7 +1308,7 @@ smb2_set_ea(const unsigned int xid, struct cifs_tcon *tcon,
 			/* Use a fudge factor of 256 bytes in case we collide
 			 * with a different set_EAs command.
 			 */
-			if(CIFSMaxBufSize - MAX_SMB2_CREATE_RESPONSE_SIZE -
+			if (CIFSMaxBufSize - MAX_SMB2_CREATE_RESPONSE_SIZE -
 			   MAX_SMB2_CLOSE_RESPONSE_SIZE - 256 <
 			   used_len + ea_name_len + ea_value_len + 1) {
 				rc = -ENOSPC;
@@ -4822,7 +4822,7 @@ handle_read_data(struct TCP_Server_Info *server, struct mid_q_entry *mid,
 
 	if (shdr->Command != SMB2_READ) {
 		cifs_server_dbg(VFS, "only big read responses are supported\n");
-		return -ENOTSUPP;
+		return -EOPNOTSUPP;
 	}
 
 	if (server->ops->is_session_expired &&
Signature · 1 line
2.40.1
author maintainer
#130 lore raw

PATCH 130/183 ata: libata-eh: do not clear ATA_PFLAG_EH_PENDING in ata_eh_reset()

In reply to Greg Kroah-Hartman

5.15-stable review patch. If anyone has any objections, please let me know.

------------------

From: Niklas Cassel <[email protected]>

[ Upstream commit 80cc944eca4f0baa9c381d0706f3160e491437f2 ]

ata_scsi_port_error_handler() starts off by clearing ATA_PFLAG_EH_PENDING, before calling ap->ops->error_handler() (without holding the ap->lock).

If an error IRQ is received while ap->ops->error_handler() is running, the irq handler will set ATA_PFLAG_EH_PENDING.

Once ap->ops->error_handler() returns, ata_scsi_port_error_handler() checks if ATA_PFLAG_EH_PENDING is set, and if it is, another iteration of ATA EH is performed.

The problem is that ATA_PFLAG_EH_PENDING is not only cleared by ata_scsi_port_error_handler(), it is also cleared by ata_eh_reset().

ata_eh_reset() is called by ap->ops->error_handler(). This additional clearing done by ata_eh_reset() breaks the whole retry logic in ata_scsi_port_error_handler(). Thus, if an error IRQ is received while ap->ops->error_handler() is running, the port will currently remain frozen and will never get re-enabled.

The additional clearing in ata_eh_reset() was introduced in commit 1e641060c4b5 ("libata: clear eh_info on reset completion").

Looking at the original error report:
https://marc.info/?l=linux-ide&m=124765325828495&w=2

We can see the following happening:

[    1.074659] ata3: XXX port freeze
[    1.074700] ata3: XXX hardresetting link, stopping engine
[    1.074746] ata3: XXX flipping SControl
[    1.411471] ata3: XXX irq_stat=400040 CONN|PHY
[    1.411475] ata3: XXX port freeze
[    1.420049] ata3: XXX starting engine
[    1.420096] ata3: XXX rc=0, class=1
[    1.420142] ata3: XXX clearing IRQs for thawing
[    1.420188] ata3: XXX port thawed
[    1.420234] ata3: SATA link up 3.0 Gbps (SStatus 123 SControl 300)

We are not supposed to be able to receive an error IRQ while the port is frozen (PxIE is set to 0, i.e. all IRQs for the port are disabled).

AHCI 1.3.1 section 10.7.1.1 First Tier (IS Register) states:
"Each bit location can be thought of as reporting a '1' if the virtual "interrupt line" for that port is indicating it wishes to generate an interrupt. That is, if a port has one or more interrupt status bit set, and the enables for those status bits are set, then this bit shall be set."

Additionally, AHCI state P:ComInit clearly shows that the state machine will only jump to P:ComInitSetIS (which sets IS.IPS(x) to '1'), if PxIE.PCE is set to '1'. In our case, PxIE is set to 0, so IS.IPS(x) won't get set.

So IS.IPS(x) only gets set if PxIS and PxIE is set.

AHCI 1.3.1 section 10.7.1.1 First Tier (IS Register) also states:
"The bits in this register are read/write clear. It is set by the level of the virtual interrupt line being a set, and cleared by a write of '1' from the software."

So if IS.IPS(x) is set, you need to explicitly clear it by writing a 1 to IS.IPS(x) for that port.

Since PxIE is cleared, the only way to get an interrupt while the port is frozen, is if IS.IPS(x) is set, and the only way IS.IPS(x) can be set when the port is frozen, is if it was set before the port was frozen.

However, since commit 737dd811a3db ("ata: libahci: clear pending interrupt status"), we clear both PxIS and IS.IPS(x) after freezing the port, but before the COMRESET, so the problem that commit 1e641060c4b5 ("libata:
clear eh_info on reset completion") fixed can no longer happen.

Thus, revert commit 1e641060c4b5 ("libata: clear eh_info on reset completion"), so that the retry logic in ata_scsi_port_error_handler() works once again. (The retry logic is still needed, since we can still get an error IRQ _after_ the port has been thawed, but before ata_scsi_port_error_handler() takes the ap->lock in order to check if ATA_PFLAG_EH_PENDING is set.)

---
 drivers/ata/libata-eh.c | 13 +++----------
 1 file changed, 3 insertions(+), 10 deletions(-)
drivers/ata/libata-eh.c +3 -10
index 8350abc172908..8444832008703 100644
@@ -2703,18 +2703,11 @@ int ata_eh_reset(struct ata_link *link, int classify,
 			postreset(slave, classes);
 	}
 
-	/*
-	 * Some controllers can't be frozen very well and may set spurious
-	 * error conditions during reset.  Clear accumulated error
-	 * information and re-thaw the port if frozen.  As reset is the
-	 * final recovery action and we cross check link onlineness against
-	 * device classification later, no hotplug event is lost by this.
-	 */
+	/* clear cached SError */
 	spin_lock_irqsave(link->ap->lock, flags);
-	memset(&link->eh_info, 0, sizeof(link->eh_info));
+	link->eh_info.serror = 0;
 	if (slave)
-		memset(&slave->eh_info, 0, sizeof(link->eh_info));
-	ap->pflags &= ~ATA_PFLAG_EH_PENDING;
+		slave->eh_info.serror = 0;
 	spin_unlock_irqrestore(link->ap->lock, flags);
 
 	if (ap->pflags & ATA_PFLAG_FROZEN)
Signature · 1 line
2.40.1
author maintainer
#131 lore raw

PATCH 131/183 spi: nxp-fspi: reset the FLSHxCR1 registers

In reply to Greg Kroah-Hartman

5.15-stable review patch. If anyone has any objections, please let me know.

------------------

From: Han Xu <[email protected]>

[ Upstream commit 18495676f7886e105133f1dc06c1d5e8d5436f32 ]

Reset the FLSHxCR1 registers to default value. ROM may set the register value and it affects the SPI NAND normal functions.

---
 drivers/spi/spi-nxp-fspi.c | 7 +++++++
 1 file changed, 7 insertions(+)
drivers/spi/spi-nxp-fspi.c +7 -0
index 2b0301fc971c6..23e4c30e6a60a 100644
@@ -1029,6 +1029,13 @@ static int nxp_fspi_default_setup(struct nxp_fspi *f)
 	fspi_writel(f, FSPI_AHBCR_PREF_EN | FSPI_AHBCR_RDADDROPT,
 		 base + FSPI_AHBCR);
 
+	/* Reset the FLSHxCR1 registers. */
+	reg = FSPI_FLSHXCR1_TCSH(0x3) | FSPI_FLSHXCR1_TCSS(0x3);
+	fspi_writel(f, reg, base + FSPI_FLSHA1CR1);
+	fspi_writel(f, reg, base + FSPI_FLSHA2CR1);
+	fspi_writel(f, reg, base + FSPI_FLSHB1CR1);
+	fspi_writel(f, reg, base + FSPI_FLSHB2CR1);
+
 	/* AHB Read - Set lut sequence ID for all CS. */
 	fspi_writel(f, SEQID_LUT, base + FSPI_FLSHA1CR2);
 	fspi_writel(f, SEQID_LUT, base + FSPI_FLSHA2CR2);
Signature · 1 line
2.40.1
author maintainer
#132 lore raw

PATCH 132/183 spi: stm32: add a delay before SPI disable

In reply to Greg Kroah-Hartman

5.15-stable review patch. If anyone has any objections, please let me know.

------------------

From: Valentin Caron <[email protected]>

[ Upstream commit 6de8a70c84ee0586fdde4e671626b9caca6aed74 ]

As explained in errata sheet, in section "2.14.5 Truncation of SPI output signals after EOT event":
On STM32MP1x, EOT interrupt can be thrown before the true end of communication.

So we add a delay of a half period to wait the real end of the transmission.

---
 drivers/spi/spi-stm32.c | 8 ++++++++
 1 file changed, 8 insertions(+)
drivers/spi/spi-stm32.c +8 -0
index 3c6f201b5dd85..191baa6e45c08 100644
@@ -268,6 +268,7 @@ struct stm32_spi_cfg {
  * @fifo_size: size of the embedded fifo in bytes
  * @cur_midi: master inter-data idleness in ns
  * @cur_speed: speed configured in Hz
+ * @cur_half_period: time of a half bit in us
  * @cur_bpw: number of bits in a single SPI data frame
  * @cur_fthlv: fifo threshold level (data frames in a single data packet)
  * @cur_comm: SPI communication mode
@@ -294,6 +295,7 @@ struct stm32_spi {
 
 	unsigned int cur_midi;
 	unsigned int cur_speed;
+	unsigned int cur_half_period;
 	unsigned int cur_bpw;
 	unsigned int cur_fthlv;
 	unsigned int cur_comm;
@@ -454,6 +456,8 @@ static int stm32_spi_prepare_mbr(struct stm32_spi *spi, u32 speed_hz,
 
 	spi->cur_speed = spi->clk_rate / (1 << mbrdiv);
 
+	spi->cur_half_period = DIV_ROUND_CLOSEST(USEC_PER_SEC, 2 * spi->cur_speed);
+
 	return mbrdiv - 1;
 }
 
@@ -695,6 +699,10 @@ static void stm32h7_spi_disable(struct stm32_spi *spi)
 		return;
 	}
 
+	/* Add a delay to make sure that transmission is ended. */
+	if (spi->cur_half_period)
+		udelay(spi->cur_half_period);
+
 	if (spi->cur_usedma && spi->dma_tx)
 		dmaengine_terminate_all(spi->dma_tx);
 	if (spi->cur_usedma && spi->dma_rx)
Signature · 1 line
2.40.1
author maintainer
#133 lore raw

PATCH 133/183 ASoC: fsl: imx-pcm-rpmsg: Add SNDRV_PCM_INFO_BATCH flag

In reply to Greg Kroah-Hartman

5.15-stable review patch. If anyone has any objections, please let me know.

------------------

From: Shengjiu Wang <[email protected]>

[ Upstream commit 2f9426905a63be7ccf8cd10109caf1848aa0993a ]

The rpmsg pcm device is a device which should support double buffering.

Found this issue with pipewire. When there is no SNDRV_PCM_INFO_BATCH flag in driver, the pipewire will set headroom to be zero, and because rpmsg pcm device don't support residue report, when the latency setting is small, the "delay" always larger than "target" in alsa-pcm.c, that reading next period data is not scheduled on time.

With SNDRV_PCM_INFO_BATCH flag in driver, the pipewire will select a smaller period size for device, then the task of reading next period data will be scheduled on time.

---
 sound/soc/fsl/imx-pcm-rpmsg.c | 1 +
 1 file changed, 1 insertion(+)
sound/soc/fsl/imx-pcm-rpmsg.c +1 -0
index 35049043e5322..933bac7ea1864 100644
@@ -19,6 +19,7 @@
 static struct snd_pcm_hardware imx_rpmsg_pcm_hardware = {
 	.info = SNDRV_PCM_INFO_INTERLEAVED |
 		SNDRV_PCM_INFO_BLOCK_TRANSFER |
+		SNDRV_PCM_INFO_BATCH |
 		SNDRV_PCM_INFO_MMAP |
 		SNDRV_PCM_INFO_MMAP_VALID |
 		SNDRV_PCM_INFO_NO_PERIOD_WAKEUP |
Signature · 1 line
2.40.1
author maintainer
#134 lore raw

PATCH 134/183 bpf: Clarify error expectations from bpf_clone_redirect

In reply to Greg Kroah-Hartman

5.15-stable review patch. If anyone has any objections, please let me know.

------------------

From: Stanislav Fomichev <[email protected]>

[ Upstream commit 7cb779a6867fea00b4209bcf6de2f178a743247d ]

Commit 151e887d8ff9 ("veth: Fixing transmit return status for dropped packets") exposed the fact that bpf_clone_redirect is capable of returning raw NET_XMIT_XXX return codes.

This is in the conflict with its UAPI doc which says the following:
"0 on success, or a negative error in case of failure."

Update the UAPI to reflect the fact that bpf_clone_redirect can return positive error numbers, but don't explicitly define their meaning.

---
 include/uapi/linux/bpf.h       | 4 +++-
 tools/include/uapi/linux/bpf.h | 4 +++-
 2 files changed, 6 insertions(+), 2 deletions(-)
include/uapi/linux/bpf.h +3 -1
index a887e582f0e78..9fb06a511250f 100644
@@ -1762,7 +1762,9 @@ union bpf_attr {
  * 		performed again, if the helper is used in combination with
  * 		direct packet access.
  * 	Return
- * 		0 on success, or a negative error in case of failure.
+ * 		0 on success, or a negative error in case of failure. Positive
+ * 		error indicates a potential drop or congestion in the target
+ * 		device. The particular positive error codes are not defined.
  *
  * u64 bpf_get_current_pid_tgid(void)
  * 	Return
tools/include/uapi/linux/bpf.h +3 -1
index 8330e3ca8fbfb..1e3e3f16eabcb 100644
@@ -1762,7 +1762,9 @@ union bpf_attr {
  * 		performed again, if the helper is used in combination with
  * 		direct packet access.
  * 	Return
- * 		0 on success, or a negative error in case of failure.
+ * 		0 on success, or a negative error in case of failure. Positive
+ * 		error indicates a potential drop or congestion in the target
+ * 		device. The particular positive error codes are not defined.
  *
  * u64 bpf_get_current_pid_tgid(void)
  * 	Return
Signature · 1 line
2.40.1
author maintainer
#135 lore raw

PATCH 135/183 ASoC: imx-rpmsg: Set ignore_pmdown_time for dai_link

In reply to Greg Kroah-Hartman

5.15-stable review patch. If anyone has any objections, please let me know.

------------------

From: Chancel Liu <[email protected]>

[ Upstream commit fac58baf8fcfcd7481e8f6d60206ce2a47c1476c ]

i.MX rpmsg sound cards work on codec slave mode. MCLK will be disabled by CPU DAI driver in hw_free(). Some codec requires MCLK present at power up/down sequence. So need to set ignore_pmdown_time to power down codec immediately before MCLK is turned off.

Take WM8962 as an example, if MCLK is disabled before DAPM power down playback stream, FIFO error will arise in WM8962 which will have bad impact on playback next.

---
 sound/soc/fsl/imx-rpmsg.c | 8 ++++++++
 1 file changed, 8 insertions(+)
sound/soc/fsl/imx-rpmsg.c +8 -0
index f96fe4ff8425b..d208b05051fd5 100644
@@ -66,6 +66,14 @@ static int imx_rpmsg_probe(struct platform_device *pdev)
 			    SND_SOC_DAIFMT_NB_NF |
 			    SND_SOC_DAIFMT_CBS_CFS;
 
+	/*
+	 * i.MX rpmsg sound cards work on codec slave mode. MCLK will be
+	 * disabled by CPU DAI driver in hw_free(). Some codec requires MCLK
+	 * present at power up/down sequence. So need to set ignore_pmdown_time
+	 * to power down codec immediately before MCLK is turned off.
+	 */
+	data->dai.ignore_pmdown_time = 1;
+
 	/* Optional codec node */
 	ret = of_parse_phandle_with_fixed_args(np, "audio-codec", 0, 0, &args);
 	if (ret) {
Signature · 1 line
2.40.1
author maintainer
#136 lore raw

PATCH 136/183 media: vb2: frame_vector.c: replace WARN_ONCE with a comment

In reply to Greg Kroah-Hartman

5.15-stable review patch. If anyone has any objections, please let me know.

------------------

From: Hans Verkuil <[email protected]>

[ Upstream commit 735de5caf79e06cc9fb96b1b4f4974674ae3e917 ]

The WARN_ONCE was issued also in cases that had nothing to do with VM_IO (e.g. if the start address was just a random value and uaccess fails with -EFAULT).

There are no reports of WARN_ONCE being issued for actual VM_IO cases, so just drop it and instead add a note to the comment before the function.

---
 drivers/media/common/videobuf2/frame_vector.c | 6 ++++--
 1 file changed, 4 insertions(+), 2 deletions(-)
drivers/media/common/videobuf2/frame_vector.c +4 -2
index 144027035892a..07ebe4424df3a 100644
@@ -30,6 +30,10 @@
  * different type underlying the specified range of virtual addresses.
  * When the function isn't able to map a single page, it returns error.
  *
+ * Note that get_vaddr_frames() cannot follow VM_IO mappings. It used
+ * to be able to do that, but that could (racily) return non-refcounted
+ * pfns.
+ *
  * This function takes care of grabbing mmap_lock as necessary.
  */
 int get_vaddr_frames(unsigned long start, unsigned int nr_frames,
@@ -55,8 +59,6 @@ int get_vaddr_frames(unsigned long start, unsigned int nr_frames,
 	if (likely(ret > 0))
 		return ret;
 
-	/* This used to (racily) return non-refcounted pfns. Let people know */
-	WARN_ONCE(1, "get_vaddr_frames() cannot follow VM_IO mapping");
 	vec->nr_frames = 0;
 	return ret ? ret : -EFAULT;
 }
Signature · 1 line
2.40.1
author maintainer
#137 lore raw

PATCH 137/183 powerpc/watchpoints: Disable preemption in thread_change_pc()

In reply to Greg Kroah-Hartman

5.15-stable review patch. If anyone has any objections, please let me know.

------------------

From: Benjamin Gray <[email protected]>

[ Upstream commit cc879ab3ce39bc39f9b1d238b283f43a5f6f957d ]

thread_change_pc() uses CPU local data, so must be protected from swapping CPUs while it is reading the breakpoint struct.

The error is more noticeable after 1e60f3564bad ("powerpc/watchpoints:
Track perf single step directly on the breakpoint"), which added an unconditional __this_cpu_read() call in thread_change_pc(). However the existing __this_cpu_read() that runs if a breakpoint does need to be re-inserted has the same issue.

---
 arch/powerpc/kernel/hw_breakpoint.c | 7 ++++++-
 1 file changed, 6 insertions(+), 1 deletion(-)
arch/powerpc/kernel/hw_breakpoint.c +6 -1
index 91a3be14808b1..63fec0602af22 100644
@@ -478,11 +478,13 @@ void thread_change_pc(struct task_struct *tsk, struct pt_regs *regs)
 	struct arch_hw_breakpoint *info;
 	int i;
 
+	preempt_disable();
+
 	for (i = 0; i < nr_wp_slots(); i++) {
 		if (unlikely(tsk->thread.last_hit_ubp[i]))
 			goto reset;
 	}
-	return;
+	goto out;
 
 reset:
 	regs_set_return_msr(regs, regs->msr & ~MSR_SE);
@@ -491,6 +493,9 @@ void thread_change_pc(struct task_struct *tsk, struct pt_regs *regs)
 		__set_breakpoint(i, info);
 		tsk->thread.last_hit_ubp[i] = NULL;
 	}
+
+out:
+	preempt_enable();
 }
 
 static bool is_larx_stcx_instr(int type)
Signature · 1 line
2.40.1
author maintainer
#138 lore raw

PATCH 138/183 powerpc/watchpoint: Disable pagefaults when getting user instruction

In reply to Greg Kroah-Hartman

5.15-stable review patch. If anyone has any objections, please let me know.

------------------

From: Benjamin Gray <[email protected]>

[ Upstream commit 3241f260eb830d27d09cc604690ec24533fdb433 ]

This is called in an atomic context, so is not allowed to sleep if a user page needs to be faulted in and has nowhere it can be deferred to. The pagefault_disabled() function is documented as preventing user access methods from sleeping.

In practice the page will be mapped in nearly always because we are reading the instruction that just triggered the watchpoint trap.

---
 arch/powerpc/kernel/hw_breakpoint_constraints.c | 7 ++++++-
 1 file changed, 6 insertions(+), 1 deletion(-)
arch/powerpc/kernel/hw_breakpoint_constraints.c +6 -1
index 675d1f66ab728..a541e3b755479 100644
@@ -140,8 +140,13 @@ void wp_get_instr_detail(struct pt_regs *regs, struct ppc_inst *instr,
 			 int *type, int *size, unsigned long *ea)
 {
 	struct instruction_op op;
+	int err;
 
-	if (__get_user_instr(*instr, (void __user *)regs->nip))
+	pagefault_disable();
+	err = __get_user_instr(*instr, (void __user *)regs->nip);
+	pagefault_enable();
+
+	if (err)
 		return;
 
 	analyse_instr(&op, regs, *instr);
Signature · 1 line
2.40.1
author maintainer
#139 lore raw

PATCH 139/183 powerpc/watchpoints: Annotate atomic context in more places

In reply to Greg Kroah-Hartman

5.15-stable review patch. If anyone has any objections, please let me know.

------------------

From: Benjamin Gray <[email protected]>

[ Upstream commit 27646b2e02b096a6936b3e3b6ba334ae20763eab ]

It can be easy to miss that the notifier mechanism invokes the callbacks in an atomic context, so add some comments to that effect on the two handlers we register here.

---
 arch/powerpc/kernel/hw_breakpoint.c | 9 +++++++++
 1 file changed, 9 insertions(+)
arch/powerpc/kernel/hw_breakpoint.c +9 -0
index 63fec0602af22..affb03f56a7e1 100644
@@ -610,6 +610,11 @@ static void handle_p10dd1_spurious_exception(struct arch_hw_breakpoint **info,
 	}
 }
 
+/*
+ * Handle a DABR or DAWR exception.
+ *
+ * Called in atomic context.
+ */
 int hw_breakpoint_handler(struct die_args *args)
 {
 	bool err = false;
@@ -736,6 +741,8 @@ NOKPROBE_SYMBOL(hw_breakpoint_handler);
 
 /*
  * Handle single-step exceptions following a DABR hit.
+ *
+ * Called in atomic context.
  */
 static int single_step_dabr_instruction(struct die_args *args)
 {
@@ -793,6 +800,8 @@ NOKPROBE_SYMBOL(single_step_dabr_instruction);
 
 /*
  * Handle debug exception notifications.
+ *
+ * Called in atomic context.
  */
 int hw_breakpoint_exceptions_notify(
 		struct notifier_block *unused, unsigned long val, void *data)
Signature · 1 line
2.40.1
author maintainer
#140 lore raw

PATCH 140/183 ncsi: Propagate carrier gain/loss events to the NCSI controller

In reply to Greg Kroah-Hartman

5.15-stable review patch. If anyone has any objections, please let me know.

------------------

From: Johnathan Mantey <[email protected]>

[ Upstream commit 3780bb29311eccb7a1c9641032a112eed237f7e3 ]

Report the carrier/no-carrier state for the network interface shared between the BMC and the passthrough channel. Without this functionality the BMC is unable to reconfigure the NIC in the event of a re-cabling to a different subnet.

---
 net/ncsi/ncsi-aen.c | 5 +++++
 1 file changed, 5 insertions(+)
net/ncsi/ncsi-aen.c +5 -0
index 62fb1031763d1..f8854bff286cb 100644
@@ -89,6 +89,11 @@ static int ncsi_aen_handler_lsc(struct ncsi_dev_priv *ndp,
 	if ((had_link == has_link) || chained)
 		return 0;
 
+	if (had_link)
+		netif_carrier_off(ndp->ndev.dev);
+	else
+		netif_carrier_on(ndp->ndev.dev);
+
 	if (!ndp->multi_package && !nc->package->multi_channel) {
 		if (had_link) {
 			ndp->flags |= NCSI_DEV_RESHUFFLE;
Signature · 1 line
2.40.1
author maintainer
#141 lore raw

PATCH 141/183 fbdev/sh7760fb: Depend on FB=y

In reply to Greg Kroah-Hartman

5.15-stable review patch. If anyone has any objections, please let me know.

------------------

From: Thomas Zimmermann <[email protected]>

[ Upstream commit f75f71b2c418a27a7c05139bb27a0c83adf88d19 ]

Fix linker error if FB=m about missing fb_io_read and fb_io_write. The linker's error message suggests that this config setting has already been broken for other symbols.

All errors (new ones prefixed by >>):

     sh4-linux-ld: drivers/video/fbdev/sh7760fb.o: in function `sh7760fb_probe':
     sh7760fb.c:(.text+0x374): undefined reference to `framebuffer_alloc'
     sh4-linux-ld: sh7760fb.c:(.text+0x394): undefined reference to `fb_videomode_to_var'
     sh4-linux-ld: sh7760fb.c:(.text+0x39c): undefined reference to `fb_alloc_cmap'
     sh4-linux-ld: sh7760fb.c:(.text+0x3a4): undefined reference to `register_framebuffer'
     sh4-linux-ld: sh7760fb.c:(.text+0x3ac): undefined reference to `fb_dealloc_cmap'
     sh4-linux-ld: sh7760fb.c:(.text+0x434): undefined reference to `framebuffer_release'
     sh4-linux-ld: drivers/video/fbdev/sh7760fb.o: in function `sh7760fb_remove':
     sh7760fb.c:(.text+0x800): undefined reference to `unregister_framebuffer'
     sh4-linux-ld: sh7760fb.c:(.text+0x804): undefined reference to `fb_dealloc_cmap'
     sh4-linux-ld: sh7760fb.c:(.text+0x814): undefined reference to `framebuffer_release'
Quoted 2 lines
Quoted 2 lines

sh4-linux-ld: drivers/video/fbdev/sh7760fb.o:(.rodata+0xc): undefined reference to `fb_io_read'
sh4-linux-ld: drivers/video/fbdev/sh7760fb.o:(.rodata+0x10): undefined reference to `fb_io_write'

     sh4-linux-ld: drivers/video/fbdev/sh7760fb.o:(.rodata+0x2c): undefined reference to `cfb_fillrect'
     sh4-linux-ld: drivers/video/fbdev/sh7760fb.o:(.rodata+0x30): undefined reference to `cfb_copyarea'
     sh4-linux-ld: drivers/video/fbdev/sh7760fb.o:(.rodata+0x34): undefined reference to `cfb_imageblit'
---
 drivers/video/fbdev/Kconfig | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/video/fbdev/Kconfig +1 -1
index 26531aa194282..662524574cc33 100644
@@ -2017,7 +2017,7 @@ config FB_COBALT
 
 config FB_SH7760
 	bool "SH7760/SH7763/SH7720/SH7721 LCDC support"
-	depends on FB && (CPU_SUBTYPE_SH7760 || CPU_SUBTYPE_SH7763 \
+	depends on FB=y && (CPU_SUBTYPE_SH7760 || CPU_SUBTYPE_SH7763 \
 		|| CPU_SUBTYPE_SH7720 || CPU_SUBTYPE_SH7721)
 	select FB_CFB_FILLRECT
 	select FB_CFB_COPYAREA
Signature · 1 line
2.40.1
author maintainer
#142 lore raw

PATCH 142/183 perf build: Define YYNOMEM as YYNOABORT for bison < 3.81

In reply to Greg Kroah-Hartman

5.15-stable review patch. If anyone has any objections, please let me know.

------------------

From: Arnaldo Carvalho de Melo <[email protected]>

[ Upstream commit 88cc47e24597971b05b6e94c28a2fc81d2a8d61a ]

YYNOMEM was introduced in bison 3.81, so define it as YYABORT for older versions, which should provide the previous perf behaviour.

---
 tools/perf/util/Build | 6 ++++++
 1 file changed, 6 insertions(+)
tools/perf/util/Build +6 -0
index f2914d5bed6e8..7d085927da413 100644
@@ -263,6 +263,12 @@ ifeq ($(BISON_GE_35),1)
 else
   bison_flags += -w
 endif
+
+BISON_LT_381 := $(shell expr $(shell $(BISON) --version | grep bison | sed -e 's/.\+ \([0-9]\+\).\([0-9]\+\).\([0-9]\+\)/\1\2\3/g') \< 381)
+ifeq ($(BISON_LT_381),1)
+  bison_flags += -DYYNOMEM=YYABORT
+endif
+
 CFLAGS_parse-events-bison.o += $(bison_flags)
 CFLAGS_pmu-bison.o          += -DYYLTYPE_IS_TRIVIAL=0 $(bison_flags)
 CFLAGS_expr-bison.o         += -DYYLTYPE_IS_TRIVIAL=0 $(bison_flags)
Signature · 1 line
2.40.1
author maintainer
#143 lore raw

PATCH 143/183 sched/cpuacct: Optimize away RCU read lock

In reply to Greg Kroah-Hartman

5.15-stable review patch. If anyone has any objections, please let me know.

------------------

From: Chengming Zhou <[email protected]>

commit dc6e0818bc9a0336d9accf3ea35d146d72aa7a18 upstream.

Since cpuacct_charge() is called from the scheduler update_curr(), we must already have rq lock held, then the RCU read lock can be optimized away.

And do the same thing in it's wrapper cgroup_account_cputime(), but we can't use lockdep_assert_rq_held() there, which defined in kernel/sched/sched.h.

---
 include/linux/cgroup.h | 2 --
 kernel/sched/cpuacct.c | 4 +---
 2 files changed, 1 insertion(+), 5 deletions(-)
include/linux/cgroup.h +0 -2
index 45cdb12243e3f..f425389ce4bb2 100644
@@ -792,11 +792,9 @@ static inline void cgroup_account_cputime(struct task_struct *task,
 
 	cpuacct_charge(task, delta_exec);
 
-	rcu_read_lock();
 	cgrp = task_dfl_cgroup(task);
 	if (cgroup_parent(cgrp))
 		__cgroup_account_cputime(cgrp, delta_exec);
-	rcu_read_unlock();
 }
 
 static inline void cgroup_account_cputime_field(struct task_struct *task,
kernel/sched/cpuacct.c +1 -3
index cacc2076ad214..f0af0fecde9d9 100644
@@ -331,12 +331,10 @@ void cpuacct_charge(struct task_struct *tsk, u64 cputime)
 	unsigned int cpu = task_cpu(tsk);
 	struct cpuacct *ca;
 
-	rcu_read_lock();
+	lockdep_assert_rq_held(cpu_rq(cpu));
 
 	for (ca = task_ca(tsk); ca; ca = parent_ca(ca))
 		*per_cpu_ptr(ca->cpuusage, cpu) += cputime;
-
-	rcu_read_unlock();
 }
 
 /*
Signature · 1 line
2.40.1
author maintainer
#144 lore raw

PATCH 144/183 cgroup: Fix suspicious rcu_dereference_check() usage warning

In reply to Greg Kroah-Hartman

5.15-stable review patch. If anyone has any objections, please let me know.

------------------

From: Chengming Zhou <[email protected]>

commit f2aa197e4794bf4c2c0c9570684f86e6fa103e8b upstream.

task_css_set_check() will use rcu_dereference_check() to check for rcu_read_lock_held() on the read-side, which is not true after commit dc6e0818bc9a ("sched/cpuacct: Optimize away RCU read lock"). This commit drop explicit rcu_read_lock(), change to RCU-sched read-side critical section. So fix the RCU warning by adding check for rcu_read_lock_sched_held().

---
 include/linux/cgroup.h | 1 +
 1 file changed, 1 insertion(+)
include/linux/cgroup.h +1 -0
index f425389ce4bb2..0d97d1cf660f7 100644
@@ -451,6 +451,7 @@ extern struct mutex cgroup_mutex;
 extern spinlock_t css_set_lock;
 #define task_css_set_check(task, __c)					\
 	rcu_dereference_check((task)->cgroups,				\
+		rcu_read_lock_sched_held() ||				\
 		lockdep_is_held(&cgroup_mutex) ||			\
 		lockdep_is_held(&css_set_lock) ||			\
 		((task)->flags & PF_EXITING) || (__c))
Signature · 1 line
2.40.1
author maintainer
#145 lore raw

PATCH 145/183 nvme-pci: factor the iod mempool creation into a helper

In reply to Greg Kroah-Hartman

5.15-stable review patch. If anyone has any objections, please let me know.

------------------

From: Christoph Hellwig <[email protected]>

[ Upstream commit 081a7d958ce4b65f9aab6e70e65b0b2e0b92297c ]

Add a helper to create the iod mempool.

Tested-by Gerd Bayer <[email protected]>
Stable-dep-of: dad651b2a44e ("nvme-pci: do not set the NUMA node of device if it has none")

---
 drivers/nvme/host/pci.c | 41 ++++++++++++++++++-----------------------
 1 file changed, 18 insertions(+), 23 deletions(-)
drivers/nvme/host/pci.c +18 -23
index bb3813e8474f4..161cc4cd41fa9 100644
@@ -384,14 +384,6 @@ static int nvme_pci_npages_sgl(void)
 			NVME_CTRL_PAGE_SIZE);
 }
 
-static size_t nvme_pci_iod_alloc_size(void)
-{
-	size_t npages = max(nvme_pci_npages_prp(), nvme_pci_npages_sgl());
-
-	return sizeof(__le64 *) * npages +
-		sizeof(struct scatterlist) * NVME_MAX_SEGS;
-}
-
 static int nvme_admin_init_hctx(struct blk_mq_hw_ctx *hctx, void *data,
 				unsigned int hctx_idx)
 {
@@ -2662,6 +2654,22 @@ static void nvme_release_prp_pools(struct nvme_dev *dev)
 	dma_pool_destroy(dev->prp_small_pool);
 }
 
+static int nvme_pci_alloc_iod_mempool(struct nvme_dev *dev)
+{
+	size_t npages = max(nvme_pci_npages_prp(), nvme_pci_npages_sgl());
+	size_t alloc_size = sizeof(__le64 *) * npages +
+			    sizeof(struct scatterlist) * NVME_MAX_SEGS;
+
+	WARN_ON_ONCE(alloc_size > PAGE_SIZE);
+	dev->iod_mempool = mempool_create_node(1,
+			mempool_kmalloc, mempool_kfree,
+			(void *)alloc_size, GFP_KERNEL,
+			dev_to_node(dev->dev));
+	if (!dev->iod_mempool)
+		return -ENOMEM;
+	return 0;
+}
+
 static void nvme_free_tagset(struct nvme_dev *dev)
 {
 	if (dev->tagset.tags)
@@ -2963,7 +2971,6 @@ static int nvme_probe(struct pci_dev *pdev, const struct pci_device_id *id)
 	int node, result = -ENOMEM;
 	struct nvme_dev *dev;
 	unsigned long quirks = id->driver_data;
-	size_t alloc_size;
 
 	node = dev_to_node(&pdev->dev);
 	if (node == NUMA_NO_NODE)
@@ -3008,21 +3015,9 @@ static int nvme_probe(struct pci_dev *pdev, const struct pci_device_id *id)
 		quirks |= NVME_QUIRK_SIMPLE_SUSPEND;
 	}
 
-	/*
-	 * Double check that our mempool alloc size will cover the biggest
-	 * command we support.
-	 */
-	alloc_size = nvme_pci_iod_alloc_size();
-	WARN_ON_ONCE(alloc_size > PAGE_SIZE);
-
-	dev->iod_mempool = mempool_create_node(1, mempool_kmalloc,
-						mempool_kfree,
-						(void *) alloc_size,
-						GFP_KERNEL, node);
-	if (!dev->iod_mempool) {
-		result = -ENOMEM;
+	result = nvme_pci_alloc_iod_mempool(dev);
+	if (result)
 		goto release_pools;
-	}
 
 	result = nvme_init_ctrl(&dev->ctrl, &pdev->dev, &nvme_pci_ctrl_ops,
 			quirks);
Signature · 1 line
2.40.1
author maintainer
#146 lore raw

PATCH 146/183 nvme-pci: factor out a nvme_pci_alloc_dev helper

In reply to Greg Kroah-Hartman

5.15-stable review patch. If anyone has any objections, please let me know.

------------------

From: Christoph Hellwig <[email protected]>

[ Upstream commit 2e87570be9d2746e7c4e7ab1cc18fd3ca7de2768 ]

Add a helper that allocates the nvme_dev structure up to the point where we can call nvme_init_ctrl. This pairs with the free_ctrl method and can thus be used to cleanup the teardown path and make it more symmetric.

Note that this now calls nvme_init_ctrl a lot earlier during probing, which also means the per-controller character device shows up earlier. Due to the controller state no commnds can be send on it, but it might make sense to delay the cdev registration until nvme_init_ctrl_finish.

Tested-by Gerd Bayer <[email protected]>
Stable-dep-of: dad651b2a44e ("nvme-pci: do not set the NUMA node of device if it has none")

---
 drivers/nvme/host/pci.c | 81 +++++++++++++++++++++++------------------
 1 file changed, 46 insertions(+), 35 deletions(-)
drivers/nvme/host/pci.c +46 -35
index 161cc4cd41fa9..0779bf2378264 100644
@@ -2677,6 +2677,7 @@ static void nvme_free_tagset(struct nvme_dev *dev)
 	dev->ctrl.tagset = NULL;
 }
 
+/* pairs with nvme_pci_alloc_dev */
 static void nvme_pci_free_ctrl(struct nvme_ctrl *ctrl)
 {
 	struct nvme_dev *dev = to_nvme_dev(ctrl);
@@ -2966,19 +2967,23 @@ static void nvme_async_probe(void *data, async_cookie_t cookie)
 	nvme_put_ctrl(&dev->ctrl);
 }
 
-static int nvme_probe(struct pci_dev *pdev, const struct pci_device_id *id)
+static struct nvme_dev *nvme_pci_alloc_dev(struct pci_dev *pdev,
+		const struct pci_device_id *id)
 {
-	int node, result = -ENOMEM;
-	struct nvme_dev *dev;
 	unsigned long quirks = id->driver_data;
+	int node = dev_to_node(&pdev->dev);
+	struct nvme_dev *dev;
+	int ret = -ENOMEM;
 
-	node = dev_to_node(&pdev->dev);
 	if (node == NUMA_NO_NODE)
 		set_dev_node(&pdev->dev, first_memory_node);
 
 	dev = kzalloc_node(sizeof(*dev), GFP_KERNEL, node);
 	if (!dev)
-		return -ENOMEM;
+		return NULL;
+	INIT_WORK(&dev->ctrl.reset_work, nvme_reset_work);
+	INIT_WORK(&dev->remove_work, nvme_remove_dead_ctrl_work);
+	mutex_init(&dev->shutdown_lock);
 
 	dev->nr_write_queues = write_queues;
 	dev->nr_poll_queues = poll_queues;
@@ -2986,25 +2991,11 @@ static int nvme_probe(struct pci_dev *pdev, const struct pci_device_id *id)
 	dev->queues = kcalloc_node(dev->nr_allocated_queues,
 			sizeof(struct nvme_queue), GFP_KERNEL, node);
 	if (!dev->queues)
-		goto free;
+		goto out_free_dev;
 
 	dev->dev = get_device(&pdev->dev);
-	pci_set_drvdata(pdev, dev);
-
-	result = nvme_dev_map(dev);
-	if (result)
-		goto put_pci;
-
-	INIT_WORK(&dev->ctrl.reset_work, nvme_reset_work);
-	INIT_WORK(&dev->remove_work, nvme_remove_dead_ctrl_work);
-	mutex_init(&dev->shutdown_lock);
-
-	result = nvme_setup_prp_pools(dev);
-	if (result)
-		goto unmap;
 
 	quirks |= check_vendor_combination_bug(pdev);
-
 	if (!noacpi && acpi_storage_d3(&pdev->dev)) {
 		/*
 		 * Some systems use a bios work around to ask for D3 on
@@ -3014,34 +3005,54 @@ static int nvme_probe(struct pci_dev *pdev, const struct pci_device_id *id)
 			 "platform quirk: setting simple suspend\n");
 		quirks |= NVME_QUIRK_SIMPLE_SUSPEND;
 	}
+	ret = nvme_init_ctrl(&dev->ctrl, &pdev->dev, &nvme_pci_ctrl_ops,
+			     quirks);
+	if (ret)
+		goto out_put_device;
+	return dev;
 
-	result = nvme_pci_alloc_iod_mempool(dev);
+out_put_device:
+	put_device(dev->dev);
+	kfree(dev->queues);
+out_free_dev:
+	kfree(dev);
+	return ERR_PTR(ret);
+}
+
+static int nvme_probe(struct pci_dev *pdev, const struct pci_device_id *id)
+{
+	struct nvme_dev *dev;
+	int result = -ENOMEM;
+
+	dev = nvme_pci_alloc_dev(pdev, id);
+	if (!dev)
+		return -ENOMEM;
+
+	result = nvme_dev_map(dev);
 	if (result)
-		goto release_pools;
+		goto out_uninit_ctrl;
 
-	result = nvme_init_ctrl(&dev->ctrl, &pdev->dev, &nvme_pci_ctrl_ops,
-			quirks);
+	result = nvme_setup_prp_pools(dev);
+	if (result)
+		goto out_dev_unmap;
+
+	result = nvme_pci_alloc_iod_mempool(dev);
 	if (result)
-		goto release_mempool;
+		goto out_release_prp_pools;
 
 	dev_info(dev->ctrl.device, "pci function %s\n", dev_name(&pdev->dev));
+	pci_set_drvdata(pdev, dev);
 
 	nvme_reset_ctrl(&dev->ctrl);
 	async_schedule(nvme_async_probe, dev);
-
 	return 0;
 
- release_mempool:
-	mempool_destroy(dev->iod_mempool);
- release_pools:
+out_release_prp_pools:
 	nvme_release_prp_pools(dev);
- unmap:
+out_dev_unmap:
 	nvme_dev_unmap(dev);
- put_pci:
-	put_device(dev->dev);
- free:
-	kfree(dev->queues);
-	kfree(dev);
+out_uninit_ctrl:
+	nvme_uninit_ctrl(&dev->ctrl);
 	return result;
 }
 
Signature · 1 line
2.40.1
author maintainer
#147 lore raw

PATCH 147/183 nvme-pci: do not set the NUMA node of device if it has none

In reply to Greg Kroah-Hartman

5.15-stable review patch. If anyone has any objections, please let me know.

------------------

From: Pratyush Yadav <[email protected]>

[ Upstream commit dad651b2a44eb6b201738f810254279dca29d30d ]

If a device has no NUMA node information associated with it, the driver puts the device in node first_memory_node (say node 0). Not having a NUMA node and being associated with node 0 are completely different things and it makes little sense to mix the two.

---
 drivers/nvme/host/pci.c | 3 ---
 1 file changed, 3 deletions(-)
drivers/nvme/host/pci.c +0 -3
index 0779bf2378264..e5980df2094ad 100644
@@ -2975,9 +2975,6 @@ static struct nvme_dev *nvme_pci_alloc_dev(struct pci_dev *pdev,
 	struct nvme_dev *dev;
 	int ret = -ENOMEM;
 
-	if (node == NUMA_NO_NODE)
-		set_dev_node(&pdev->dev, first_memory_node);
-
 	dev = kzalloc_node(sizeof(*dev), GFP_KERNEL, node);
 	if (!dev)
 		return NULL;
Signature · 1 line
2.40.1
author maintainer
#148 lore raw

PATCH 148/183 watchdog: iTCO_wdt: No need to stop the timer in probe

In reply to Greg Kroah-Hartman

5.15-stable review patch. If anyone has any objections, please let me know.

------------------

From: Mika Westerberg <[email protected]>

commit 1ae3e78c08209ac657c59f6f7ea21bbbd7f6a1d4 upstream.

The watchdog core can handle pinging of the watchdog before userspace opens the device. For this reason instead of stopping the timer, just mark it as running and let the watchdog core take care of it.

---
 drivers/watchdog/iTCO_wdt.c | 13 +++++++++++--
 1 file changed, 11 insertions(+), 2 deletions(-)
drivers/watchdog/iTCO_wdt.c +11 -2
index ced2fc0deb8c4..96ff06d7d735d 100644
@@ -424,6 +424,16 @@ static unsigned int iTCO_wdt_get_timeleft(struct watchdog_device *wd_dev)
 	return time_left;
 }
 
+static void iTCO_wdt_set_running(struct iTCO_wdt_private *p)
+{
+	u16 val;
+
+	/* Bit 11: TCO Timer Halt -> 0 = The TCO timer is * enabled */
+	val = inw(TCO1_CNT(p));
+	if (!(val & BIT(11)))
+		set_bit(WDOG_HW_RUNNING, &p->wddev.status);
+}
+
 /*
  *	Kernel Interfaces
  */
@@ -566,8 +576,7 @@ static int iTCO_wdt_probe(struct platform_device *pdev)
 	watchdog_set_drvdata(&p->wddev, p);
 	platform_set_drvdata(pdev, p);
 
-	/* Make sure the watchdog is not running */
-	iTCO_wdt_stop(&p->wddev);
+	iTCO_wdt_set_running(p);
 
 	/* Check that the heartbeat value is within it's range;
 	   if not reset to the default */
Signature · 1 line
2.40.1
author maintainer
#149 lore raw

PATCH 149/183 watchdog: iTCO_wdt: Set NO_REBOOT if the watchdog is not already running

In reply to Greg Kroah-Hartman

5.15-stable review patch. If anyone has any objections, please let me know.

------------------

From: Mika Westerberg <[email protected]>

commit ef9b7bf52c2f47f0a9bf988543c577b92c92d15e upstream.

Daniel reported that the commit 1ae3e78c0820 ("watchdog: iTCO_wdt: No need to stop the timer in probe") makes QEMU implementation of the iTCO watchdog not to trigger reboot anymore when NO_REBOOT flag is initially cleared using this option (in QEMU command line):

-global ICH9-LPC.noreboot=false

The problem with the commit is that it left the unconditional setting of NO_REBOOT that is not cleared anymore when the kernel keeps pinging the watchdog (as opposed to the previous code that called iTCO_wdt_stop() that cleared it).

Fix this so that we only set NO_REBOOT if the watchdog was not initially running.

---
 drivers/watchdog/iTCO_wdt.c | 21 ++++++++++++++-------
 1 file changed, 14 insertions(+), 7 deletions(-)
drivers/watchdog/iTCO_wdt.c +14 -7
index 96ff06d7d735d..a8052a3faaabb 100644
@@ -424,14 +424,18 @@ static unsigned int iTCO_wdt_get_timeleft(struct watchdog_device *wd_dev)
 	return time_left;
 }
 
-static void iTCO_wdt_set_running(struct iTCO_wdt_private *p)
+/* Returns true if the watchdog was running */
+static bool iTCO_wdt_set_running(struct iTCO_wdt_private *p)
 {
 	u16 val;
 
-	/* Bit 11: TCO Timer Halt -> 0 = The TCO timer is * enabled */
+	/* Bit 11: TCO Timer Halt -> 0 = The TCO timer is enabled */
 	val = inw(TCO1_CNT(p));
-	if (!(val & BIT(11)))
+	if (!(val & BIT(11))) {
 		set_bit(WDOG_HW_RUNNING, &p->wddev.status);
+		return true;
+	}
+	return false;
 }
 
 /*
@@ -522,9 +526,6 @@ static int iTCO_wdt_probe(struct platform_device *pdev)
 		return -ENODEV;	/* Cannot reset NO_REBOOT bit */
 	}
 
-	/* Set the NO_REBOOT bit to prevent later reboots, just for sure */
-	p->update_no_reboot_bit(p->no_reboot_priv, true);
-
 	if (turn_SMI_watchdog_clear_off >= p->iTCO_version) {
 		/*
 		 * Bit 13: TCO_EN -> 0
@@ -576,7 +577,13 @@ static int iTCO_wdt_probe(struct platform_device *pdev)
 	watchdog_set_drvdata(&p->wddev, p);
 	platform_set_drvdata(pdev, p);
 
-	iTCO_wdt_set_running(p);
+	if (!iTCO_wdt_set_running(p)) {
+		/*
+		 * If the watchdog was not running set NO_REBOOT now to
+		 * prevent later reboots.
+		 */
+		p->update_no_reboot_bit(p->no_reboot_priv, true);
+	}
 
 	/* Check that the heartbeat value is within it's range;
 	   if not reset to the default */
Signature · 1 line
2.40.1
author maintainer
#150 lore raw

PATCH 150/183 i40e: fix potential NULL pointer dereferencing of pf->vf i40e_sync_vsi_filters()

In reply to Greg Kroah-Hartman

5.15-stable review patch. If anyone has any objections, please let me know.

------------------

From: Andrii Staikov <[email protected]>

[ Upstream commit 9525a3c38accd2e186f52443e35e633e296cc7f5 ]

Add check for pf->vf not being NULL before dereferencing pf->vf[vsi->vf_id] in updating VSI filter sync.
Add a similar check before dereferencing !pf->vf[vsi->vf_id].trusted in the condition for clearing promisc mode bit.

---
 drivers/net/ethernet/intel/i40e/i40e_main.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)
drivers/net/ethernet/intel/i40e/i40e_main.c +3 -2
index 76bb1d0de8d1c..539bb69548f23 100644
@@ -2595,7 +2595,7 @@ int i40e_sync_vsi_filters(struct i40e_vsi *vsi)
 			retval = i40e_correct_mac_vlan_filters
 				(vsi, &tmp_add_list, &tmp_del_list,
 				 vlan_filters);
-		else
+		else if (pf->vf)
 			retval = i40e_correct_vf_mac_vlan_filters
 				(vsi, &tmp_add_list, &tmp_del_list,
 				 vlan_filters, pf->vf[vsi->vf_id].trusted);
@@ -2768,7 +2768,8 @@ int i40e_sync_vsi_filters(struct i40e_vsi *vsi)
 	}
 
 	/* if the VF is not trusted do not do promisc */
-	if ((vsi->type == I40E_VSI_SRIOV) && !pf->vf[vsi->vf_id].trusted) {
+	if (vsi->type == I40E_VSI_SRIOV && pf->vf &&
+	    !pf->vf[vsi->vf_id].trusted) {
 		clear_bit(__I40E_VSI_OVERFLOW_PROMISC, vsi->state);
 		goto out;
 	}
Signature · 1 line
2.40.1
author maintainer
#151 lore raw

PATCH 151/183 perf metric: Return early if no CPU PMU table exists

In reply to Greg Kroah-Hartman

5.15-stable review patch. If anyone has any objections, please let me know.

------------------

From: Ian Rogers <[email protected]>

[ Upstream commit 3f5df3ac646e21a79a421ae4037c4ef0632bcaa9 ]

Previous behavior is to segfault if there is no CPU PMU table and a metric is sought. To reproduce compile with NO_JEVENTS=1 then request a metric, for example, "perf stat -M IPC true".

Committer testing:

Before:

  $ make -k NO_JEVENTS=1 BUILD_BPF_SKEL=1 O=/tmp/build/perf-urgent -C tools/perf install-bin
  $ perf stat -M IPC true
  Segmentation fault (core dumped)
  $

After:

  $ perf stat -M IPC true

Usage: perf stat [<options>] [<command>]

-M, --metrics <metric/metric group list>
monitor specified metrics or metric groups (separated by ,)
$

Fixes 00facc760903be66 ("perf jevents: Switch build to use jevents.py")
Cc Alexander Shishkin <[email protected]>
Cc Andi Kleen <[email protected]>
Cc Caleb Biggers <[email protected]>
Cc Florian Fischer <[email protected]>
Cc Ian Rogers <[email protected]>
Cc Ingo Molnar <[email protected]>
Cc James Clark <[email protected]>
Cc Jiri Olsa <[email protected]>
Cc John Garry <[email protected]>
Cc Kan Liang <[email protected]>
Cc Kshipra Bopardikar <[email protected]>
Cc Mark Rutland <[email protected]>
Cc Miaoqian Lin <[email protected]>
Cc Namhyung Kim <[email protected]>
Cc Perry Taylor <[email protected]>
Cc Peter Zijlstra <[email protected]>
Cc Stephane Eranian <[email protected]>
Cc Thomas Richter <[email protected]>
Cc Xing Zhengjun <[email protected]>
---
 tools/perf/util/metricgroup.c | 3 +++
 1 file changed, 3 insertions(+)
tools/perf/util/metricgroup.c +3 -0
index 29b747ac31c12..ee6c5582681bd 100644
@@ -1258,6 +1258,9 @@ int metricgroup__parse_groups(const struct option *opt,
 	struct evlist *perf_evlist = *(struct evlist **)opt->value;
 	struct pmu_events_map *map = pmu_events_map__find();
 
+	if (!table)
+		return -EINVAL;
+
 	return parse_groups(perf_evlist, str, metric_no_group,
 			    metric_no_merge, NULL, metric_events, map);
 }
Signature · 1 line
2.40.1
author maintainer
#152 lore raw

PATCH 152/183 scsi: qla2xxx: Fix NULL pointer dereference in target mode

In reply to Greg Kroah-Hartman

5.15-stable review patch. If anyone has any objections, please let me know.

------------------

From: Gleb Chesnokov <[email protected]>

[ Upstream commit d54820b22e404b06b2b65877ff802cc7b31688bc ]

When target mode is enabled, the pci_irq_get_affinity() function may return a NULL value in qla_mapq_init_qp_cpu_map() due to the qla24xx_enable_msix() code that handles IRQ settings for target mode. This leads to a crash due to a NULL pointer dereference.

This patch fixes the issue by adding a check for the NULL value returned by pci_irq_get_affinity() and introducing a 'cpu_mapped' boolean flag to the qla_qpair structure, ensuring that the qpair's CPU affinity is updated when it has not been mapped to a CPU.

Fixes 1d201c81d4cc ("scsi: qla2xxx: Select qpair depending on which CPU post_cmd() gets called")
---
 drivers/scsi/qla2xxx/qla_def.h    | 1 +
 drivers/scsi/qla2xxx/qla_init.c   | 3 +++
 drivers/scsi/qla2xxx/qla_inline.h | 3 +++
 drivers/scsi/qla2xxx/qla_isr.c    | 3 +++
 4 files changed, 10 insertions(+)
drivers/scsi/qla2xxx/qla_def.h +1 -0
index 723f9953ad701..3c876967e8b16 100644
@@ -3791,6 +3791,7 @@ struct qla_qpair {
 	uint64_t retry_term_jiff;
 	struct qla_tgt_counters tgt_counters;
 	uint16_t cpuid;
+	bool cpu_mapped;
 	struct qla_fw_resources fwres ____cacheline_aligned;
 	u32	cmd_cnt;
 	u32	cmd_completion_cnt;
drivers/scsi/qla2xxx/qla_init.c +3 -0
index d259f6727cf74..b59d5b560a278 100644
@@ -9780,6 +9780,9 @@ struct qla_qpair *qla2xxx_create_qpair(struct scsi_qla_host *vha, int qos,
 		qpair->rsp->req = qpair->req;
 		qpair->rsp->qpair = qpair;
 
+		if (!qpair->cpu_mapped)
+			qla_cpu_update(qpair, raw_smp_processor_id());
+
 		if (IS_T10_PI_CAPABLE(ha) && ql2xenabledif) {
 			if (ha->fw_attributes & BIT_4)
 				qpair->difdix_supported = 1;
drivers/scsi/qla2xxx/qla_inline.h +3 -0
index e66441355f7ae..a4a56ab0ba747 100644
@@ -597,11 +597,14 @@ qla_mapq_init_qp_cpu_map(struct qla_hw_data *ha,
 	if (!ha->qp_cpu_map)
 		return;
 	mask = pci_irq_get_affinity(ha->pdev, msix->vector_base0);
+	if (!mask)
+		return;
 	qpair->cpuid = cpumask_first(mask);
 	for_each_cpu(cpu, mask) {
 		ha->qp_cpu_map[cpu] = qpair;
 	}
 	msix->cpuid = qpair->cpuid;
+	qpair->cpu_mapped = true;
 }
 
 static inline void
drivers/scsi/qla2xxx/qla_isr.c +3 -0
index 4f6aab2599350..51e906fa8694e 100644
@@ -3782,6 +3782,9 @@ void qla24xx_process_response_queue(struct scsi_qla_host *vha,
 
 	if (rsp->qpair->cpuid != raw_smp_processor_id() || !rsp->qpair->rcv_intr) {
 		rsp->qpair->rcv_intr = 1;
+
+		if (!rsp->qpair->cpu_mapped)
+			qla_cpu_update(rsp->qpair, raw_smp_processor_id());
 	}
 
 #define __update_rsp_in(_update, _is_shadow_hba, _rsp, _rsp_in)		\
Signature · 1 line
2.40.1
author maintainer
#153 lore raw

PATCH 153/183 nvme-pci: always return an ERR_PTR from nvme_pci_alloc_dev

In reply to Greg Kroah-Hartman

5.15-stable review patch. If anyone has any objections, please let me know.

------------------

From: Irvin Cote <[email protected]>

[ Upstream commit dc785d69d753a3894c93afc23b91404652382ead ]

Don't mix NULL and ERR_PTR returns.

Fixes 2e87570be9d2 ("nvme-pci: factor out a nvme_pci_alloc_dev helper")
---
 drivers/nvme/host/pci.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)
drivers/nvme/host/pci.c +3 -3
index e5980df2094ad..65172a654a198 100644
@@ -2977,7 +2977,7 @@ static struct nvme_dev *nvme_pci_alloc_dev(struct pci_dev *pdev,
 
 	dev = kzalloc_node(sizeof(*dev), GFP_KERNEL, node);
 	if (!dev)
-		return NULL;
+		return ERR_PTR(-ENOMEM);
 	INIT_WORK(&dev->ctrl.reset_work, nvme_reset_work);
 	INIT_WORK(&dev->remove_work, nvme_remove_dead_ctrl_work);
 	mutex_init(&dev->shutdown_lock);
@@ -3022,8 +3022,8 @@ static int nvme_probe(struct pci_dev *pdev, const struct pci_device_id *id)
 	int result = -ENOMEM;
 
 	dev = nvme_pci_alloc_dev(pdev, id);
-	if (!dev)
-		return -ENOMEM;
+	if (IS_ERR(dev))
+		return PTR_ERR(dev);
 
 	result = nvme_dev_map(dev);
 	if (result)
Signature · 1 line
2.40.1
author maintainer
#154 lore raw

PATCH 154/183 smack: Record transmuting in smk_transmuted

In reply to Greg Kroah-Hartman

5.15-stable review patch. If anyone has any objections, please let me know.

------------------

From: Roberto Sassu <[email protected]>

[ Upstream commit 2c085f3a8f23c9b444e8b99d93c15d7ce870fc4e ]

smack_dentry_create_files_as() determines whether transmuting should occur based on the label of the parent directory the new inode will be added to, and not the label of the directory where it is created.

This helps for example to do transmuting on overlayfs, since the latter first creates the inode in the working directory, and then moves it to the correct destination.

However, despite smack_dentry_create_files_as() provides the correct label, smack_inode_init_security() does not know from passed information whether or not transmuting occurred. Without this information, smack_inode_init_security() cannot set SMK_INODE_CHANGED in smk_flags, which will result in the SMACK64TRANSMUTE xattr not being set in smack_d_instantiate().

Thus, add the smk_transmuted field to the task_smack structure, and set it in smack_dentry_create_files_as() to smk_task if transmuting occurred. If smk_task is equal to smk_transmuted in smack_inode_init_security(), act as if transmuting was successful but without taking the label from the parent directory (the inode label was already set correctly from the current credentials in smack_inode_alloc_security()).

---
 security/smack/smack.h     |  1 +
 security/smack/smack_lsm.c | 41 +++++++++++++++++++++++++++-----------
 2 files changed, 30 insertions(+), 12 deletions(-)
security/smack/smack.h +1 -0
index 99c3422596ab9..a71b7a1ca24c2 100644
@@ -120,6 +120,7 @@ struct inode_smack {
 struct task_smack {
 	struct smack_known	*smk_task;	/* label for access control */
 	struct smack_known	*smk_forked;	/* label when forked */
+	struct smack_known	*smk_transmuted;/* label when transmuted */
 	struct list_head	smk_rules;	/* per task access rules */
 	struct mutex		smk_rules_lock;	/* lock for the rules */
 	struct list_head	smk_relabel;	/* transit allowed labels */
security/smack/smack_lsm.c +29 -12

65 lines not on this page · raw message

Signature · 1 line
2.40.1
author maintainer
#155 lore raw

PATCH 155/183 smack: Retrieve transmuting information in smack_inode_getsecurity()

In reply to Greg Kroah-Hartman

5.15-stable review patch. If anyone has any objections, please let me know.

------------------

From: Roberto Sassu <[email protected]>

[ Upstream commit 3a3d8fce31a49363cc31880dce5e3b0617c9c38b ]

Enhance smack_inode_getsecurity() to retrieve the value for SMACK64TRANSMUTE from the inode security blob, similarly to SMACK64.

This helps to display accurate values in the situation where the security labels come from mount options and not from xattrs.

---
 security/smack/smack_lsm.c | 22 ++++++++++++++++++----
 1 file changed, 18 insertions(+), 4 deletions(-)
security/smack/smack_lsm.c +18 -4
index 84df97d0d3c58..f8c40c49d860c 100644
@@ -1429,10 +1429,19 @@ static int smack_inode_getsecurity(struct user_namespace *mnt_userns,
 	struct super_block *sbp;
 	struct inode *ip = (struct inode *)inode;
 	struct smack_known *isp;
+	struct inode_smack *ispp;
+	size_t label_len;
+	char *label = NULL;
 
-	if (strcmp(name, XATTR_SMACK_SUFFIX) == 0)
+	if (strcmp(name, XATTR_SMACK_SUFFIX) == 0) {
 		isp = smk_of_inode(inode);
-	else {
+	} else if (strcmp(name, XATTR_SMACK_TRANSMUTE) == 0) {
+		ispp = smack_inode(inode);
+		if (ispp->smk_flags & SMK_INODE_TRANSMUTE)
+			label = TRANS_TRUE;
+		else
+			label = "";
+	} else {
 		/*
 		 * The rest of the Smack xattrs are only on sockets.
 		 */
@@ -1454,13 +1463,18 @@ static int smack_inode_getsecurity(struct user_namespace *mnt_userns,
 			return -EOPNOTSUPP;
 	}
 
+	if (!label)
+		label = isp->smk_known;
+
+	label_len = strlen(label);
+
 	if (alloc) {
-		*buffer = kstrdup(isp->smk_known, GFP_KERNEL);
+		*buffer = kstrdup(label, GFP_KERNEL);
 		if (*buffer == NULL)
 			return -ENOMEM;
 	}
 
-	return strlen(isp->smk_known);
+	return label_len;
 }
 
 
Signature · 1 line
2.40.1
author maintainer
#156 lore raw

PATCH 156/183 Smack:- Use overlay inode label in smack_inode_copy_up()

In reply to Greg Kroah-Hartman

5.15-stable review patch. If anyone has any objections, please let me know.

------------------

From: Vishal Goel <[email protected]>

[ Upstream commit 387ef964460f14fe1c1ea29aba70e22731ea7cf7 ]

Currently in "smack_inode_copy_up()" function, process label is changed with the label on parent inode. Due to which, process is assigned directory label and whatever file or directory created by the process are also getting directory label which is wrong label.

Changes has been done to use label of overlay inode instead of parent inode.

---
 security/smack/smack_lsm.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
security/smack/smack_lsm.c +1 -1
index f8c40c49d860c..39f564f47fea5 100644
@@ -4663,7 +4663,7 @@ static int smack_inode_copy_up(struct dentry *dentry, struct cred **new)
 	/*
 	 * Get label from overlay inode and set it in create_sid
 	 */
-	isp = smack_inode(d_inode(dentry->d_parent));
+	isp = smack_inode(d_inode(dentry));
 	skp = isp->smk_inode;
 	tsp->smk_task = skp;
 	*new = new_creds;
Signature · 1 line
2.40.1
author maintainer
#157 lore raw

PATCH 157/183 iommu/arm-smmu-v3: Fix soft lockup triggered by arm_smmu_mm_invalidate_range

In reply to Greg Kroah-Hartman

5.15-stable review patch. If anyone has any objections, please let me know.

------------------

From: Nicolin Chen <[email protected]>

commit d5afb4b47e13161b3f33904d45110f9e6463bad6 upstream.

When running an SVA case, the following soft lockup is triggered:
--------------------------------------------------------------------

watchdog: BUG: soft lockup - CPU#244 stuck for 26s!
pstate: 83400009 (Nzcv daif +PAN -UAO +TCO +DIT -SSBS BTYPE=--)
pc : arm_smmu_cmdq_issue_cmdlist+0x178/0xa50
lr : arm_smmu_cmdq_issue_cmdlist+0x150/0xa50

sp : ffff8000d83ef290
x29: ffff8000d83ef290 x28: 000000003b9aca00 x27: 0000000000000000
x26: ffff8000d83ef3c0 x25: da86c0812194a0e8 x24: 0000000000000000
x23: 0000000000000040 x22: ffff8000d83ef340 x21: ffff0000c63980c0
x20: 0000000000000001 x19: ffff0000c6398080 x18: 0000000000000000
x17: 0000000000000000 x16: 0000000000000000 x15: ffff3000b4a3bbb0
x14: ffff3000b4a30888 x13: ffff3000b4a3cf60 x12: 0000000000000000
x11: 0000000000000000 x10: 0000000000000000 x9 : ffffc08120e4d6bc x8 : 0000000000000000 x7 : 0000000000000000 x6 : 0000000000048cfa x5 : 0000000000000000 x4 : 0000000000000001 x3 : 000000000000000a x2 : 0000000080000000 x1 : 0000000000000000 x0 : 0000000000000001

Call trace:
 arm_smmu_cmdq_issue_cmdlist+0x178/0xa50
 __arm_smmu_tlb_inv_range+0x118/0x254
 arm_smmu_tlb_inv_range_asid+0x6c/0x130
 arm_smmu_mm_invalidate_range+0xa0/0xa4
 __mmu_notifier_invalidate_range_end+0x88/0x120
 unmap_vmas+0x194/0x1e0
 unmap_region+0xb4/0x144
 do_mas_align_munmap+0x290/0x490
 do_mas_munmap+0xbc/0x124
 __vm_munmap+0xa8/0x19c
 __arm64_sys_munmap+0x28/0x50
 invoke_syscall+0x78/0x11c
 el0_svc_common.constprop.0+0x58/0x1c0
 do_el0_svc+0x34/0x60
 el0_svc+0x2c/0xd4
 el0t_64_sync_handler+0x114/0x140
 el0t_64_sync+0x1a4/0x1a8
--------------------------------------------------------------------

The commit 06ff87bae8d3 ("arm64: mm: remove unused functions and variable protoypes") fixed a similar lockup on the CPU MMU side. Yet, it can occur to SMMU too since arm_smmu_mm_invalidate_range() is typically called next to MMU tlb flush function, e.g.

	tlb_flush_mmu_tlbonly {
		tlb_flush {
			__flush_tlb_range {
				// check MAX_TLBI_OPS
			}
		}
		mmu_notifier_invalidate_range {
			arm_smmu_mm_invalidate_range {
				// does not check MAX_TLBI_OPS
			}
		}
	}

Clone a CMDQ_MAX_TLBI_OPS from the MAX_TLBI_OPS in tlbflush.h, since in an SVA case SMMU uses the CPU page table, so it makes sense to align with the tlbflush code. Then, replace per-page TLBI commands with a single per-asid TLBI command, if the request size hits this threshold.

---
 .../iommu/arm/arm-smmu-v3/arm-smmu-v3-sva.c   | 27 ++++++++++++++++---
 1 file changed, 24 insertions(+), 3 deletions(-)
drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3-sva.c +24 -3
index e2e80eb2840ca..01748742c6842 100644
@@ -186,6 +186,15 @@ static void arm_smmu_free_shared_cd(struct arm_smmu_ctx_desc *cd)
 	}
 }
 
+/*
+ * Cloned from the MAX_TLBI_OPS in arch/arm64/include/asm/tlbflush.h, this
+ * is used as a threshold to replace per-page TLBI commands to issue in the
+ * command queue with an address-space TLBI command, when SMMU w/o a range
+ * invalidation feature handles too many per-page TLBI commands, which will
+ * otherwise result in a soft lockup.
+ */
+#define CMDQ_MAX_TLBI_OPS		(1 << (PAGE_SHIFT - 3))
+
 static void arm_smmu_mm_invalidate_range(struct mmu_notifier *mn,
 					 struct mm_struct *mm,
 					 unsigned long start, unsigned long end)
@@ -200,10 +209,22 @@ static void arm_smmu_mm_invalidate_range(struct mmu_notifier *mn,
 	 * range. So do a simple translation here by calculating size correctly.
 	 */
 	size = end - start;
+	if (!(smmu_domain->smmu->features & ARM_SMMU_FEAT_RANGE_INV)) {
+		if (size >= CMDQ_MAX_TLBI_OPS * PAGE_SIZE)
+			size = 0;
+	}
+
+	if (!(smmu_domain->smmu->features & ARM_SMMU_FEAT_BTM)) {
+		if (!size)
+			arm_smmu_tlb_inv_asid(smmu_domain->smmu,
+					      smmu_mn->cd->asid);
+		else
+			arm_smmu_tlb_inv_range_asid(start, size,
+						    smmu_mn->cd->asid,
+						    PAGE_SIZE, false,
+						    smmu_domain);
+	}
 
-	if (!(smmu_domain->smmu->features & ARM_SMMU_FEAT_BTM))
-		arm_smmu_tlb_inv_range_asid(start, size, smmu_mn->cd->asid,
-					    PAGE_SIZE, false, smmu_domain);
 	arm_smmu_atc_inv_domain(smmu_domain, mm->pasid, start, size);
 }
 
Signature · 1 line
2.40.1
author maintainer
#158 lore raw

PATCH 158/183 x86/srso: Add SRSO mitigation for Hygon processors

In reply to Greg Kroah-Hartman

5.15-stable review patch. If anyone has any objections, please let me know.

------------------

From: Pu Wen <[email protected]>

commit a5ef7d68cea1344cf524f04981c2b3f80bedbb0d upstream.

Add mitigation for the speculative return stack overflow vulnerability which exists on Hygon processors too.

---
 arch/x86/kernel/cpu/common.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
arch/x86/kernel/cpu/common.c +1 -1
@@ -1172,7 +1172,7 @@ static const struct x86_cpu_id cpu_vuln_
 	VULNBL_AMD(0x15, RETBLEED),
 	VULNBL_AMD(0x16, RETBLEED),
 	VULNBL_AMD(0x17, RETBLEED | SMT_RSB | SRSO),
-	VULNBL_HYGON(0x18, RETBLEED | SMT_RSB),
+	VULNBL_HYGON(0x18, RETBLEED | SMT_RSB | SRSO),
 	VULNBL_AMD(0x19, SRSO),
 	{}
 };
author maintainer
#159 lore raw

PATCH 159/183 misc: rtsx: Fix some platforms can not boot and move the l1ss judgment to probe

In reply to Greg Kroah-Hartman

5.15-stable review patch. If anyone has any objections, please let me know.

------------------

From: Ricky WU <[email protected]>

commit 0e4cac557531a4c93de108d9ff11329fcad482ff upstream.

commit 101bd907b424 ("misc: rtsx: judge ASPM Mode to set PETXCFG Reg") some readers no longer force #CLKREQ to low
when the system need to enter ASPM.
But some platform maybe not implement complete ASPM?
it causes some platforms can not boot

Like in the past only the platform support L1ss we release the #CLKREQ. Move the judgment (L1ss) to probe,
we think read config space one time when the driver start is enough

---
 drivers/misc/cardreader/rts5227.c  |   55 +++--------------------------------
 drivers/misc/cardreader/rts5228.c  |   57 +++++++++++--------------------------
 drivers/misc/cardreader/rts5249.c  |   56 ++++--------------------------------
 drivers/misc/cardreader/rts5260.c  |   43 ++++++++-------------------
 drivers/misc/cardreader/rts5261.c  |   52 ++++++++-------------------------
 drivers/misc/cardreader/rtsx_pcr.c |   51 +++++++++++++++++++++++++++++----
 6 files changed, 102 insertions(+), 212 deletions(-)
drivers/misc/cardreader/rts5227.c +6 -49
@@ -81,63 +81,20 @@ static void rts5227_fetch_vendor_setting
 
 static void rts5227_init_from_cfg(struct rtsx_pcr *pcr)
 {
-	struct pci_dev *pdev = pcr->pci;
-	int l1ss;
-	u32 lval;
 	struct rtsx_cr_option *option = &pcr->option;
 
-	l1ss = pci_find_ext_capability(pdev, PCI_EXT_CAP_ID_L1SS);
-	if (!l1ss)
-		return;
-
-	pci_read_config_dword(pdev, l1ss + PCI_L1SS_CTL1, &lval);
-
 	if (CHK_PCI_PID(pcr, 0x522A)) {
-		if (0 == (lval & 0x0F))
-			rtsx_pci_enable_oobs_polling(pcr);
-		else
+		if (rtsx_check_dev_flag(pcr, ASPM_L1_1_EN | ASPM_L1_2_EN
+				| PM_L1_1_EN | PM_L1_2_EN))
 			rtsx_pci_disable_oobs_polling(pcr);
+		else
+			rtsx_pci_enable_oobs_polling(pcr);
 	}
 
-	if (lval & PCI_L1SS_CTL1_ASPM_L1_1)
-		rtsx_set_dev_flag(pcr, ASPM_L1_1_EN);
-	else
-		rtsx_clear_dev_flag(pcr, ASPM_L1_1_EN);
-
-	if (lval & PCI_L1SS_CTL1_ASPM_L1_2)
-		rtsx_set_dev_flag(pcr, ASPM_L1_2_EN);
-	else
-		rtsx_clear_dev_flag(pcr, ASPM_L1_2_EN);
-
-	if (lval & PCI_L1SS_CTL1_PCIPM_L1_1)
-		rtsx_set_dev_flag(pcr, PM_L1_1_EN);
-	else
-		rtsx_clear_dev_flag(pcr, PM_L1_1_EN);
-
-	if (lval & PCI_L1SS_CTL1_PCIPM_L1_2)
-		rtsx_set_dev_flag(pcr, PM_L1_2_EN);
-	else
-		rtsx_clear_dev_flag(pcr, PM_L1_2_EN);
-
 	if (option->ltr_en) {
-		u16 val;
-
-		pcie_capability_read_word(pcr->pci, PCI_EXP_DEVCTL2, &val);
-		if (val & PCI_EXP_DEVCTL2_LTR_EN) {
-			option->ltr_enabled = true;
-			option->ltr_active = true;
+		if (option->ltr_enabled)
 			rtsx_set_ltr_latency(pcr, option->ltr_active_latency);
-		} else {
-			option->ltr_enabled = false;
-		}
 	}
-
-	if (rtsx_check_dev_flag(pcr, ASPM_L1_1_EN | ASPM_L1_2_EN
-				| PM_L1_1_EN | PM_L1_2_EN))
-		option->force_clkreq_0 = false;
-	else
-		option->force_clkreq_0 = true;
-
 }
 
 static int rts5227_extra_init_hw(struct rtsx_pcr *pcr)
@@ -171,7 +128,7 @@ static int rts5227_extra_init_hw(struct
 	else
 		rtsx_pci_add_cmd(pcr, WRITE_REG_CMD, PETXCFG, 0x30, 0x00);
 
-	if (option->force_clkreq_0 && pcr->aspm_mode == ASPM_MODE_CFG)
+	if (option->force_clkreq_0)
 		rtsx_pci_add_cmd(pcr, WRITE_REG_CMD, PETXCFG,
 				FORCE_CLKREQ_DELINK_MASK, FORCE_CLKREQ_LOW);
 	else
drivers/misc/cardreader/rts5228.c +17 -40

82 lines not on this page · raw message

drivers/misc/cardreader/rts5249.c +7 -49

89 lines not on this page · raw message

drivers/misc/cardreader/rts5260.c +13 -30

66 lines not on this page · raw message

drivers/misc/cardreader/rts5261.c +13 -39

73 lines not on this page · raw message

drivers/misc/cardreader/rtsx_pcr.c +46 -5

70 lines not on this page · raw message

author maintainer
#160 lore raw

PATCH 160/183 Revert "tty: n_gsm: fix UAF in gsm_cleanup_mux"

In reply to Greg Kroah-Hartman

5.15-stable review patch. If anyone has any objections, please let me know.

------------------

From: Daniel Starke <[email protected]>

commit 29346e217b8ab8a52889b88f00b268278d6b7668 upstream.

This reverts commit 9b9c8195f3f0d74a826077fc1c01b9ee74907239.

The commit above is reverted as it did not solve the original issue.

gsm_cleanup_mux() tries to free up the virtual ttys by calling gsm_dlci_release() for each available DLCI. There, dlci_put() is called to decrease the reference counter for the DLCI via tty_port_put() which finally calls gsm_dlci_free(). This already clears the pointer which is being checked in gsm_cleanup_mux() before calling gsm_dlci_release(). Therefore, it is not necessary to clear this pointer in gsm_cleanup_mux() as done in the reverted commit. The commit introduces a null pointer dereference:

 <TASK>
 ? __die+0x1f/0x70
 ? page_fault_oops+0x156/0x420
 ? search_exception_tables+0x37/0x50
 ? fixup_exception+0x21/0x310
 ? exc_page_fault+0x69/0x150
 ? asm_exc_page_fault+0x26/0x30
 ? tty_port_put+0x19/0xa0
 gsmtty_cleanup+0x29/0x80 [n_gsm]
 release_one_tty+0x37/0xe0
 process_one_work+0x1e6/0x3e0
 worker_thread+0x4c/0x3d0
 ? __pfx_worker_thread+0x10/0x10
 kthread+0xe1/0x110
 ? __pfx_kthread+0x10/0x10
 ret_from_fork+0x2f/0x50
 ? __pfx_kthread+0x10/0x10
 ret_from_fork_asm+0x1b/0x30
 </TASK>

The actual issue is that nothing guards dlci_put() from being called multiple times while the tty driver was triggered but did not yet finished calling gsm_dlci_free().

Fixes 9b9c8195f3f0 ("tty: n_gsm: fix UAF in gsm_cleanup_mux")
Cc stable <[email protected]>
---
 drivers/tty/n_gsm.c |    4 +---
 1 file changed, 1 insertion(+), 3 deletions(-)
drivers/tty/n_gsm.c +1 -3
@@ -2412,10 +2412,8 @@ static void gsm_cleanup_mux(struct gsm_m
 		gsm->has_devices = false;
 	}
 	for (i = NUM_DLCI - 1; i >= 0; i--)
-		if (gsm->dlci[i]) {
+		if (gsm->dlci[i])
 			gsm_dlci_release(gsm->dlci[i]);
-			gsm->dlci[i] = NULL;
-		}
 	mutex_unlock(&gsm->mutex);
 	/* Now wipe the queues */
 	tty_ldisc_flush(gsm->tty);
author maintainer
#161 lore raw

PATCH 161/183 serial: 8250_port: Check IRQ data before use

In reply to Greg Kroah-Hartman

5.15-stable review patch. If anyone has any objections, please let me know.

------------------

From: Andy Shevchenko <[email protected]>

commit cce7fc8b29961b64fadb1ce398dc5ff32a79643b upstream.

In case the leaf driver wants to use IRQ polling (irq = 0) and IIR register shows that an interrupt happened in the 8250 hardware the IRQ data can be NULL. In such a case we need to skip the wake event as we came to this path from the timer interrupt and quite likely system is already awake.

Without this fix we have got an Oops:

    serial8250: ttyS0 at I/O 0x3f8 (irq = 0, base_baud = 115200) is a 16550A
    ...
    BUG: kernel NULL pointer dereference, address: 0000000000000010
    RIP: 0010:serial8250_handle_irq+0x7c/0x240
    Call Trace:
     ? serial8250_handle_irq+0x7c/0x240
     ? __pfx_serial8250_timeout+0x10/0x10
Fixes 0ba9e3a13c6a ("serial: 8250: Add missing wakeup event reporting")
Cc stable <[email protected]>
---
 drivers/tty/serial/8250/8250_port.c |    5 ++++-
 1 file changed, 4 insertions(+), 1 deletion(-)
drivers/tty/serial/8250/8250_port.c +4 -1
@@ -1930,7 +1930,10 @@ int serial8250_handle_irq(struct uart_po
 		skip_rx = true;
 
 	if (status & (UART_LSR_DR | UART_LSR_BI) && !skip_rx) {
-		if (irqd_is_wakeup_set(irq_get_irq_data(port->irq)))
+		struct irq_data *d;
+
+		d = irq_get_irq_data(port->irq);
+		if (d && irqd_is_wakeup_set(d))
 			pm_wakeup_event(tport->tty->dev, 0);
 		if (!up->dma || handle_rx_dma(up, iir))
 			status = serial8250_rx_chars(up, status);
author maintainer
#162 lore raw

PATCH 162/183 nilfs2: fix potential use after free in nilfs_gccache_submit_read_data()

In reply to Greg Kroah-Hartman

5.15-stable review patch. If anyone has any objections, please let me know.

------------------

From: Pan Bian <[email protected]>

commit 7ee29facd8a9c5a26079148e36bcf07141b3a6bc upstream.

In nilfs_gccache_submit_read_data(), brelse(bh) is called to drop the reference count of bh when the call to nilfs_dat_translate() fails. If the reference count hits 0 and its owner page gets unlocked, bh may be freed. However, bh->b_page is dereferenced to put the page after that, which may result in a use-after-free bug. This patch moves the release operation after unlocking and putting the page.

NOTE: The function in question is only called in GC, and in combination with current userland tools, address translation using DAT does not occur in that function, so the code path that causes this issue will not be executed. However, it is possible to run that code path by intentionally modifying the userland GC library or by calling the GC ioctl directly.

---
 fs/nilfs2/gcinode.c |    6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)
fs/nilfs2/gcinode.c +3 -3
@@ -73,10 +73,8 @@ int nilfs_gccache_submit_read_data(struc
 		struct the_nilfs *nilfs = inode->i_sb->s_fs_info;
 
 		err = nilfs_dat_translate(nilfs->ns_dat, vbn, &pbn);
-		if (unlikely(err)) { /* -EIO, -ENOMEM, -ENOENT */
-			brelse(bh);
+		if (unlikely(err)) /* -EIO, -ENOMEM, -ENOENT */
 			goto failed;
-		}
 	}
 
 	lock_buffer(bh);
@@ -102,6 +100,8 @@ int nilfs_gccache_submit_read_data(struc
  failed:
 	unlock_page(bh->b_page);
 	put_page(bh->b_page);
+	if (unlikely(err))
+		brelse(bh);
 	return err;
 }
 
author maintainer
#163 lore raw

PATCH 163/183 netfilter: nf_tables: disallow rule removal from chain binding

In reply to Greg Kroah-Hartman

5.15-stable review patch. If anyone has any objections, please let me know.

------------------

From: Pablo Neira Ayuso <[email protected]>

[ Upstream commit f15f29fd4779be8a418b66e9d52979bb6d6c2325 ]

Chain binding only requires the rule addition/insertion command within the same transaction. Removal of rules from chain bindings within the same transaction makes no sense, userspace does not utilize this feature. Replace nft_chain_is_bound() check to nft_chain_binding() in rule deletion commands. Replace command implies a rule deletion, reject this command too.

Rule flush command can also safely rely on this nft_chain_binding() check because unbound chains are not allowed since 62e1e94b246e ("netfilter: nf_tables: reject unbound chain set before commit phase").

Fixes d0e2c7de92c7 ("netfilter: nf_tables: add NFT_CHAIN_BINDING")
---
 net/netfilter/nf_tables_api.c | 18 +++++++++++++-----
 1 file changed, 13 insertions(+), 5 deletions(-)
net/netfilter/nf_tables_api.c +13 -5
index 2f7d8e0e47de8..8a4cd1c16e0e4 100644
@@ -1348,7 +1348,7 @@ static int nft_flush_table(struct nft_ctx *ctx)
 		if (!nft_is_active_next(ctx->net, chain))
 			continue;
 
-		if (nft_chain_is_bound(chain))
+		if (nft_chain_binding(chain))
 			continue;
 
 		ctx->chain = chain;
@@ -1392,7 +1392,7 @@ static int nft_flush_table(struct nft_ctx *ctx)
 		if (!nft_is_active_next(ctx->net, chain))
 			continue;
 
-		if (nft_chain_is_bound(chain))
+		if (nft_chain_binding(chain))
 			continue;
 
 		ctx->chain = chain;
@@ -2697,6 +2697,9 @@ static int nf_tables_delchain(struct sk_buff *skb, const struct nfnl_info *info,
 		return PTR_ERR(chain);
 	}
 
+	if (nft_chain_binding(chain))
+		return -EOPNOTSUPP;
+
 	if (info->nlh->nlmsg_flags & NLM_F_NONREC &&
 	    chain->use > 0)
 		return -EBUSY;
@@ -3674,6 +3677,11 @@ static int nf_tables_newrule(struct sk_buff *skb, const struct nfnl_info *info,
 	}
 
 	if (info->nlh->nlmsg_flags & NLM_F_REPLACE) {
+		if (nft_chain_binding(chain)) {
+			err = -EOPNOTSUPP;
+			goto err_destroy_flow_rule;
+		}
+
 		err = nft_delrule(&ctx, old_rule);
 		if (err < 0)
 			goto err_destroy_flow_rule;
@@ -3777,7 +3785,7 @@ static int nf_tables_delrule(struct sk_buff *skb, const struct nfnl_info *info,
 			NL_SET_BAD_ATTR(extack, nla[NFTA_RULE_CHAIN]);
 			return PTR_ERR(chain);
 		}
-		if (nft_chain_is_bound(chain))
+		if (nft_chain_binding(chain))
 			return -EOPNOTSUPP;
 	}
 
@@ -3807,7 +3815,7 @@ static int nf_tables_delrule(struct sk_buff *skb, const struct nfnl_info *info,
 		list_for_each_entry(chain, &table->chains, list) {
 			if (!nft_is_active_next(net, chain))
 				continue;
-			if (nft_chain_is_bound(chain))
+			if (nft_chain_binding(chain))
 				continue;
 
 			ctx.chain = chain;
@@ -10458,7 +10466,7 @@ static void __nft_release_table(struct net *net, struct nft_table *table)
 	ctx.family = table->family;
 	ctx.table = table;
 	list_for_each_entry(chain, &table->chains, list) {
-		if (nft_chain_is_bound(chain))
+		if (nft_chain_binding(chain))
 			continue;
 
 		ctx.chain = chain;
Signature · 1 line
2.40.1
author maintainer
#164 lore raw

PATCH 164/183 ALSA: hda: Disable power save for solving pop issue on Lenovo ThinkCentre M70q

In reply to Greg Kroah-Hartman

5.15-stable review patch. If anyone has any objections, please let me know.

------------------

From: Kailang Yang <[email protected]>

commit 057a28ef93bdbe84326d34cdb5543afdaab49fe1 upstream.

Lenovo ThinkCentre M70q had boot up pop noise.
Disable power save will solve pop issue.

---
 sound/pci/hda/hda_intel.c |    1 +
 1 file changed, 1 insertion(+)
sound/pci/hda/hda_intel.c +1 -0
@@ -2203,6 +2203,7 @@ static const struct snd_pci_quirk power_
 	SND_PCI_QUIRK(0x8086, 0x2068, "Intel NUC7i3BNB", 0),
 	/* https://bugzilla.kernel.org/show_bug.cgi?id=198611 */
 	SND_PCI_QUIRK(0x17aa, 0x2227, "Lenovo X1 Carbon 3rd Gen", 0),
+	SND_PCI_QUIRK(0x17aa, 0x316e, "Lenovo ThinkCentre M70q", 0),
 	/* https://bugzilla.redhat.com/show_bug.cgi?id=1689623 */
 	SND_PCI_QUIRK(0x17aa, 0x367b, "Lenovo IdeaCentre B550", 0),
 	/* https://bugzilla.redhat.com/show_bug.cgi?id=1572975 */
author maintainer
#165 lore raw

PATCH 165/183 ata: libata-scsi: ignore reserved bits for REPORT SUPPORTED OPERATION CODES

In reply to Greg Kroah-Hartman

5.15-stable review patch. If anyone has any objections, please let me know.

------------------

From: Niklas Cassel <[email protected]>

commit 3ef600923521616ebe192c893468ad0424de2afb upstream.

For REPORT SUPPORTED OPERATION CODES command, the service action field is defined as bits 0-4 in the second byte in the CDB. Bits 5-7 in the second byte are reserved.

Only look at the service action field in the second byte when determining if the MAINTENANCE IN opcode is a REPORT SUPPORTED OPERATION CODES command.

This matches how we only look at the service action field in the second byte when determining if the SERVICE ACTION IN(16) opcode is a READ CAPACITY(16) command (reserved bits 5-7 in the second byte are ignored).

Fixes 7b2030942859 ("libata: Add support for SCT Write Same")
---
 drivers/ata/libata-scsi.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/ata/libata-scsi.c +1 -1
@@ -4214,7 +4214,7 @@ void ata_scsi_simulate(struct ata_device
 		break;
 
 	case MAINTENANCE_IN:
-		if (scsicmd[1] == MI_REPORT_SUPPORTED_OPERATION_CODES)
+		if ((scsicmd[1] & 0x1f) == MI_REPORT_SUPPORTED_OPERATION_CODES)
 			ata_scsi_rbuf_fill(&args, ata_scsiop_maint_in);
 		else
 			ata_scsi_set_invalid_field(dev, cmd, 1, 0xff);
author maintainer
#166 lore raw

PATCH 166/183 i2c: i801: unregister tco_pdev in i801_probe() error path

In reply to Greg Kroah-Hartman

5.15-stable review patch. If anyone has any objections, please let me know.

------------------

From: Heiner Kallweit <[email protected]>

commit 3914784553f68c931fc666dbe7e86fe881aada38 upstream.

We have to unregister tco_pdev also if i2c_add_adapter() fails.

Fixes 9424693035a5 ("i2c: i801: Create iTCO device on newer Intel PCHs")
---
 drivers/i2c/busses/i2c-i801.c |    1 +
 1 file changed, 1 insertion(+)
drivers/i2c/busses/i2c-i801.c +1 -0
@@ -1861,6 +1861,7 @@ static int i801_probe(struct pci_dev *de
 		"SMBus I801 adapter at %04lx", priv->smba);
 	err = i2c_add_adapter(&priv->adapter);
 	if (err) {
+		platform_device_unregister(priv->tco_pdev);
 		i801_acpi_remove(priv);
 		return err;
 	}
author maintainer
#167 lore raw

PATCH 167/183 kernel/sched: Modify initial boot task idle setup

In reply to Greg Kroah-Hartman

5.15-stable review patch. If anyone has any objections, please let me know.

------------------

From: Liam R. Howlett <[email protected]>

commit cff9b2332ab762b7e0586c793c431a8f2ea4db04 upstream.

Initial booting is setting the task flag to idle (PF_IDLE) by the call path sched_init() -> init_idle(). Having the task idle and calling call_rcu() in kernel/rcu/tiny.c means that TIF_NEED_RESCHED will be set. Subsequent calls to any cond_resched() will enable IRQs, potentially earlier than the IRQ setup has completed. Recent changes have caused just this scenario and IRQs have been enabled early.

This causes a warning later in start_kernel() as interrupts are enabled before they are fully set up.

Fix this issue by setting the PF_IDLE flag later in the boot sequence.

Although the boot task was marked as idle since (at least) d80e4fda576d, I am not sure that it is wrong to do so. The forced context-switch on idle task was introduced in the tiny_rcu update, so I'm going to claim this fixes 5f6130fa52ee.

---
 kernel/sched/core.c |    2 +-
 kernel/sched/idle.c |    1 +
 2 files changed, 2 insertions(+), 1 deletion(-)
kernel/sched/core.c +1 -1
@@ -8725,7 +8725,7 @@ void __init init_idle(struct task_struct
 	 * PF_KTHREAD should already be set at this point; regardless, make it
 	 * look like a proper per-CPU kthread.
 	 */
-	idle->flags |= PF_IDLE | PF_KTHREAD | PF_NO_SETAFFINITY;
+	idle->flags |= PF_KTHREAD | PF_NO_SETAFFINITY;
 	kthread_set_per_cpu(idle, cpu);
 
 #ifdef CONFIG_SMP
kernel/sched/idle.c +1 -0
@@ -397,6 +397,7 @@ EXPORT_SYMBOL_GPL(play_idle_precise);
 
 void cpu_startup_entry(enum cpuhp_state state)
 {
+	current->flags |= PF_IDLE;
 	arch_cpu_idle_prepare();
 	cpuhp_online_idle(state);
 	while (1)
author maintainer
#168 lore raw

PATCH 168/183 sched/rt: Fix live lock between select_fallback_rq() and RT push

In reply to Greg Kroah-Hartman

5.15-stable review patch. If anyone has any objections, please let me know.

------------------

From: Joel Fernandes (Google) <[email protected]>

commit fc09027786c900368de98d03d40af058bcb01ad9 upstream.

During RCU-boost testing with the TREE03 rcutorture config, I found that after a few hours, the machine locks up.

On tracing, I found that there is a live lock happening between 2 CPUs. One CPU has an RT task running, while another CPU is being offlined which also has an RT task running. During this offlining, all threads are migrated. The migration thread is repeatedly scheduled to migrate actively running tasks on the CPU being offlined. This results in a live lock because select_fallback_rq() keeps picking the CPU that an RT task is already running on only to get pushed back to the CPU being offlined.

It is anyway pointless to pick CPUs for pushing tasks to if they are being offlined only to get migrated away to somewhere else. This could also add unwanted latency to this task.

Fix these issues by not selecting CPUs in RT if they are not 'active' for scheduling, using the cpu_active_mask. Other parts in core.c already use cpu_active_mask to prevent tasks from being put on CPUs going offline.

With this fix I ran the tests for days and could not reproduce the hang. Without the patch, I hit it in a few hours.

---
 kernel/sched/cpupri.c |    1 +
 1 file changed, 1 insertion(+)
kernel/sched/cpupri.c +1 -0
@@ -102,6 +102,7 @@ static inline int __cpupri_find(struct c
 
 	if (lowest_mask) {
 		cpumask_and(lowest_mask, &p->cpus_mask, vec->mask);
+		cpumask_and(lowest_mask, lowest_mask, cpu_active_mask);
 
 		/*
 		 * We have to ensure that we have at least one bit
author maintainer
#169 lore raw

PATCH 169/183 io_uring/fs: remove sqe->rw_flags checking from LINKAT

In reply to Greg Kroah-Hartman

5.15-stable review patch. If anyone has any objections, please let me know.

------------------

From: Jens Axboe <[email protected]>

commit a52d4f657568d6458e873f74a9602e022afe666f upstream.

This is unionized with the actual link flags, so they can of course be set and they will be evaluated further down. If not we fail any LINKAT that has to set option flags.

Fixes cf30da90bc3a ("io_uring: add support for IORING_OP_LINKAT")
---
 io_uring/io_uring.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
io_uring/io_uring.c +1 -1
@@ -4038,7 +4038,7 @@ static int io_linkat_prep(struct io_kioc
 
 	if (unlikely(req->ctx->flags & IORING_SETUP_IOPOLL))
 		return -EINVAL;
-	if (sqe->ioprio || sqe->rw_flags || sqe->buf_index || sqe->splice_fd_in)
+	if (sqe->ioprio || sqe->buf_index || sqe->splice_fd_in)
 		return -EINVAL;
 	if (unlikely(req->flags & REQ_F_FIXED_FILE))
 		return -EBADF;
author maintainer
#170 lore raw

PATCH 170/183 Revert "SUNRPC dont update timeout value on connection reset"

In reply to Greg Kroah-Hartman

5.15-stable review patch. If anyone has any objections, please let me know.

------------------

From: Trond Myklebust <[email protected]>

commit a275ab62606bcd894ddff09460f7d253828313dc upstream.

This reverts commit 88428cc4ae7abcc879295fbb19373dd76aad2bdd.

The problem this commit is intended to fix was comprehensively fixed in commit 7de62bc09fe6 ("SUNRPC dont update timeout value on connection reset").
Since then, this commit has been preventing the correct timeout of soft mounted requests.

Cc [email protected] # 5.9.x: 09252177d5f9: SUNRPC: Handle major timeout in xprt_adjust_timeout()
Cc [email protected] # 5.9.x: 7de62bc09fe6: SUNRPC dont update timeout value on connection reset
---
 net/sunrpc/clnt.c |    3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)
net/sunrpc/clnt.c +1 -2
@@ -2392,8 +2392,7 @@ call_status(struct rpc_task *task)
 		goto out_exit;
 	}
 	task->tk_action = call_encode;
-	if (status != -ECONNRESET && status != -ECONNABORTED)
-		rpc_check_timeout(task);
+	rpc_check_timeout(task);
 	return;
 out_exit:
 	rpc_call_rpcerror(task, status);
author maintainer
#171 lore raw

PATCH 171/183 proc: nommu: /proc/<pid>/maps: release mmap read lock

In reply to Greg Kroah-Hartman

5.15-stable review patch. If anyone has any objections, please let me know.

------------------

From: Ben Wolsieffer <[email protected]>

commit 578d7699e5c2add8c2e9549d9d75dfb56c460cb3 upstream.

The no-MMU implementation of /proc/<pid>/map doesn't normally release the mmap read lock, because it uses !IS_ERR_OR_NULL(_vml) to determine whether to release the lock. Since _vml is NULL when the end of the mappings is reached, the lock is not released.

Reading /proc/1/maps twice doesn't cause a hang because it only takes the read lock, which can be taken multiple times and therefore doesn't show any problem if the lock isn't released. Instead, you need to perform some operation that attempts to take the write lock after reading /proc/<pid>/maps. To actually reproduce the bug, compile the following code as 'proc_maps_bug':

#include <stdio.h>
#include <unistd.h>
#include <sys/mman.h>

int main(int argc, char *argv[]) {
        void *buf;
        sleep(1);
        buf = mmap(NULL, 4096, PROT_READ | PROT_WRITE, MAP_PRIVATE | MAP_ANONYMOUS, -1, 0);
        puts("mmap returned");
        return 0;
}

Then, run:

./proc_maps_bug &; cat /proc/$!/maps; fg

Without this patch, mmap() will hang and the command will never complete.

This code was incorrectly adapted from the MMU implementation, which at the time released the lock in m_next() before returning the last entry.

The MMU implementation has diverged further from the no-MMU version since then, so this patch brings their locking and error handling into sync, fixing the bug and hopefully avoiding similar issues in the future.

Fixes 47fecca15c09 ("fs/proc/task_nommu.c: don't use priv->task->mm")
Cc Giulio Benetti <[email protected]>
Cc Greg Ungerer <[email protected]>
---
 fs/proc/task_nommu.c |   27 +++++++++++++++------------
 1 file changed, 15 insertions(+), 12 deletions(-)
fs/proc/task_nommu.c +15 -12
@@ -208,11 +208,16 @@ static void *m_start(struct seq_file *m,
 		return ERR_PTR(-ESRCH);
 
 	mm = priv->mm;
-	if (!mm || !mmget_not_zero(mm))
+	if (!mm || !mmget_not_zero(mm)) {
+		put_task_struct(priv->task);
+		priv->task = NULL;
 		return NULL;
+	}
 
 	if (mmap_read_lock_killable(mm)) {
 		mmput(mm);
+		put_task_struct(priv->task);
+		priv->task = NULL;
 		return ERR_PTR(-EINTR);
 	}
 
@@ -221,23 +226,21 @@ static void *m_start(struct seq_file *m,
 		if (n-- == 0)
 			return p;
 
-	mmap_read_unlock(mm);
-	mmput(mm);
 	return NULL;
 }
 
-static void m_stop(struct seq_file *m, void *_vml)
+static void m_stop(struct seq_file *m, void *v)
 {
 	struct proc_maps_private *priv = m->private;
+	struct mm_struct *mm = priv->mm;
 
-	if (!IS_ERR_OR_NULL(_vml)) {
-		mmap_read_unlock(priv->mm);
-		mmput(priv->mm);
-	}
-	if (priv->task) {
-		put_task_struct(priv->task);
-		priv->task = NULL;
-	}
+	if (!priv->task)
+		return;
+
+	mmap_read_unlock(mm);
+	mmput(mm);
+	put_task_struct(priv->task);
+	priv->task = NULL;
 }
 
 static void *m_next(struct seq_file *m, void *_p, loff_t *pos)
author maintainer
#172 lore raw

PATCH 172/183 ring-buffer: Update "shortest_full" in polling

In reply to Greg Kroah-Hartman

5.15-stable review patch. If anyone has any objections, please let me know.

------------------

From: Steven Rostedt (Google) <[email protected]>

commit 1e0cb399c7653462d9dadf8ab9425337c355d358 upstream.

It was discovered that the ring buffer polling was incorrectly stating that read would not block, but that's because polling did not take into account that reads will block if the "buffer-percent" was set. Instead, the ring buffer polling would say reads would not block if there was any data in the ring buffer. This was incorrect behavior from a user space point of view. This was fixed by commit 42fb0a1e84ff by having the polling code check if the ring buffer had more data than what the user specified "buffer percent" had.

The problem now is that the polling code did not register itself to the writer that it wanted to wait for a specific "full" value of the ring buffer. The result was that the writer would wake the polling waiter whenever there was a new event. The polling waiter would then wake up, see that there's not enough data in the ring buffer to notify user space and then go back to sleep. The next event would wake it up again.

Before the polling fix was added, the code would wake up around 100 times for a hackbench 30 benchmark. After the "fix", due to the constant waking of the writer, it would wake up over 11,0000 times! It would never leave the kernel, so the user space behavior was still "correct", but this definitely is not the desired effect.

To fix this, have the polling code add what it's waiting for to the "shortest_full" variable, to tell the writer not to wake it up if the buffer is not as full as it expects to be.

Note, after this fix, it appears that the waiter is now woken up around 2x the times it was before (~200). This is a tremendous improvement from the 11,000 times, but I will need to spend some time to see why polling is more aggressive in its wakeups than the read blocking code.

Cc Masami Hiramatsu <[email protected]>
Cc Mark Rutland <[email protected]>
Fixes 42fb0a1e84ff ("tracing/ring-buffer: Have polling block on watermark")
---
 kernel/trace/ring_buffer.c |    3 +++
 1 file changed, 3 insertions(+)
kernel/trace/ring_buffer.c +3 -0
@@ -1106,6 +1106,9 @@ __poll_t ring_buffer_poll_wait(struct tr
 	if (full) {
 		poll_wait(filp, &work->full_waiters, poll_table);
 		work->full_waiters_pending = true;
+		if (!cpu_buffer->shortest_full ||
+		    cpu_buffer->shortest_full > full)
+			cpu_buffer->shortest_full = full;
 	} else {
 		poll_wait(filp, &work->waiters, poll_table);
 		work->waiters_pending = true;
author maintainer
#173 lore raw

PATCH 173/183 btrfs: properly report 0 avail for very full file systems

In reply to Greg Kroah-Hartman

5.15-stable review patch. If anyone has any objections, please let me know.

------------------

From: Josef Bacik <[email protected]>

commit 58bfe2ccec5f9f137b41dd38f335290dcc13cd5c upstream.

A user reported some issues with smaller file systems that get very full. While investigating this issue I noticed that df wasn't showing 100% full, despite having 0 chunk space and having < 1MiB of available metadata space.

This turns out to be an overflow issue, we're doing:

total_available_metadata_space - SZ_4M < global_block_rsv_size

to determine if there's not enough space to make metadata allocations, which overflows if total_available_metadata_space is < 4M. Fix this by checking to see if our available space is greater than the 4M threshold. This makes df properly report 100% usage on the file system.

---
 fs/btrfs/super.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
fs/btrfs/super.c +1 -1
@@ -2364,7 +2364,7 @@ static int btrfs_statfs(struct dentry *d
 	 * calculated f_bavail.
 	 */
 	if (!mixed && block_rsv->space_info->full &&
-	    total_free_meta - thresh < block_rsv->size)
+	    (total_free_meta < thresh || total_free_meta - thresh < block_rsv->size))
 		buf->f_bavail = 0;
 
 	buf->f_type = BTRFS_SUPER_MAGIC;
author maintainer
#174 lore raw

PATCH 174/183 bpf: Fix BTF_ID symbol generation collision

In reply to Greg Kroah-Hartman

5.15-stable review patch. If anyone has any objections, please let me know.

------------------

From: Jiri Olsa <[email protected]>

commit 8f908db77782630c45ba29dac35c434b5ce0b730 upstream.

Marcus and Satya reported an issue where BTF_ID macro generates same symbol in separate objects and that breaks final vmlinux link.

ld.lld: error: ld-temp.o <inline asm>:14577:1: symbol '__BTF_ID__struct__cgroup__624' is already defined

This can be triggered under specific configs when __COUNTER__ happens to be the same for the same symbol in two different translation units, which is already quite unlikely to happen.

Add __LINE__ number suffix to make BTF_ID symbol more unique, which is not a complete fix, but it would help for now and meanwhile we can work on better solution as suggested by Andrii.

---
 include/linux/btf_ids.h |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
include/linux/btf_ids.h +1 -1
@@ -38,7 +38,7 @@ asm(							\
 	____BTF_ID(symbol)
 
 #define __ID(prefix) \
-	__PASTE(prefix, __COUNTER__)
+	__PASTE(__PASTE(prefix, __COUNTER__), __LINE__)
 
 /*
  * The BTF_ID defines unique symbol for each ID pointing
author maintainer
#175 lore raw

PATCH 175/183 bpf: Fix BTF_ID symbol generation collision in tools/

In reply to Greg Kroah-Hartman

5.15-stable review patch. If anyone has any objections, please let me know.

------------------

From: Nick Desaulniers <[email protected]>

commit c0bb9fb0e52a64601d38b3739b729d9138d4c8a1 upstream.

Marcus and Satya reported an issue where BTF_ID macro generates same symbol in separate objects and that breaks final vmlinux link.

ld.lld: error: ld-temp.o <inline asm>:14577:1: symbol '__BTF_ID__struct__cgroup__624' is already defined

This can be triggered under specific configs when __COUNTER__ happens to be the same for the same symbol in two different translation units, which is already quite unlikely to happen.

Add __LINE__ number suffix to make BTF_ID symbol more unique, which is not a complete fix, but it would help for now and meanwhile we can work on better solution as suggested by Andrii.

---
 tools/include/linux/btf_ids.h |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
tools/include/linux/btf_ids.h +1 -1
@@ -38,7 +38,7 @@ asm(							\
 	____BTF_ID(symbol)
 
 #define __ID(prefix) \
-	__PASTE(prefix, __COUNTER__)
+	__PASTE(__PASTE(prefix, __COUNTER__), __LINE__)
 
 /*
  * The BTF_ID defines unique symbol for each ID pointing
author maintainer
#176 lore raw

PATCH 176/183 net: thunderbolt: Fix TCPv6 GSO checksum calculation

In reply to Greg Kroah-Hartman

5.15-stable review patch. If anyone has any objections, please let me know.

------------------

From: Mika Westerberg <[email protected]>

commit e0b65f9b81fef180cf5f103adecbe5505c961153 upstream.

Alex reported that running ssh over IPv6 does not work with Thunderbolt/USB4 networking driver. The reason for that is that driver should call skb_is_gso() before calling skb_is_gso_v6(), and it should not return false after calculates the checksum successfully. This probably was a copy paste error from the original driver where it was done properly.

---
 drivers/net/thunderbolt.c |    3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)
drivers/net/thunderbolt.c +1 -2
@@ -993,12 +993,11 @@ static bool tbnet_xmit_csum_and_map(stru
 		*tucso = ~csum_tcpudp_magic(ip_hdr(skb)->saddr,
 					    ip_hdr(skb)->daddr, 0,
 					    ip_hdr(skb)->protocol, 0);
-	} else if (skb_is_gso_v6(skb)) {
+	} else if (skb_is_gso(skb) && skb_is_gso_v6(skb)) {
 		tucso = dest + ((void *)&(tcp_hdr(skb)->check) - data);
 		*tucso = ~csum_ipv6_magic(&ipv6_hdr(skb)->saddr,
 					  &ipv6_hdr(skb)->daddr, 0,
 					  IPPROTO_TCP, 0);
-		return false;
 	} else if (protocol == htons(ETH_P_IPV6)) {
 		tucso = dest + skb_checksum_start_offset(skb) + skb->csum_offset;
 		*tucso = ~csum_ipv6_magic(&ipv6_hdr(skb)->saddr,
author maintainer
#177 lore raw

PATCH 177/183 ata: libata-core: Fix ata_port_request_pm() locking

In reply to Greg Kroah-Hartman

5.15-stable review patch. If anyone has any objections, please let me know.

------------------

From: Damien Le Moal <[email protected]>

commit 3b8e0af4a7a331d1510e963b8fd77e2fca0a77f1 upstream.

The function ata_port_request_pm() checks the port flag ATA_PFLAG_PM_PENDING and calls ata_port_wait_eh() if this flag is set to ensure that power management operations for a port are not scheduled simultaneously. However, this flag check is done without holding the port lock.

Fix this by taking the port lock on entry to the function and checking the flag under this lock. The lock is released and re-taken if ata_port_wait_eh() needs to be called. The two WARN_ON() macros checking that the ATA_PFLAG_PM_PENDING flag was cleared are removed as the first call is racy and the second one done without holding the port lock.

---
 drivers/ata/libata-core.c |   18 +++++++++---------
 1 file changed, 9 insertions(+), 9 deletions(-)
drivers/ata/libata-core.c +9 -9
@@ -4999,17 +4999,19 @@ static void ata_port_request_pm(struct a
 	struct ata_link *link;
 	unsigned long flags;
 
-	/* Previous resume operation might still be in
-	 * progress.  Wait for PM_PENDING to clear.
+	spin_lock_irqsave(ap->lock, flags);
+
+	/*
+	 * A previous PM operation might still be in progress. Wait for
+	 * ATA_PFLAG_PM_PENDING to clear.
 	 */
 	if (ap->pflags & ATA_PFLAG_PM_PENDING) {
+		spin_unlock_irqrestore(ap->lock, flags);
 		ata_port_wait_eh(ap);
-		WARN_ON(ap->pflags & ATA_PFLAG_PM_PENDING);
+		spin_lock_irqsave(ap->lock, flags);
 	}
 
-	/* request PM ops to EH */
-	spin_lock_irqsave(ap->lock, flags);
-
+	/* Request PM operation to EH */
 	ap->pm_mesg = mesg;
 	ap->pflags |= ATA_PFLAG_PM_PENDING;
 	ata_for_each_link(link, ap, HOST_FIRST) {
@@ -5021,10 +5023,8 @@ static void ata_port_request_pm(struct a
 
 	spin_unlock_irqrestore(ap->lock, flags);
 
-	if (!async) {
+	if (!async)
 		ata_port_wait_eh(ap);
-		WARN_ON(ap->pflags & ATA_PFLAG_PM_PENDING);
-	}
 }
 
 /*
author maintainer
#178 lore raw

PATCH 178/183 ata: libata-core: Fix port and device removal

In reply to Greg Kroah-Hartman

5.15-stable review patch. If anyone has any objections, please let me know.

------------------

From: Damien Le Moal <[email protected]>

commit 84d76529c650f887f1e18caee72d6f0589e1baf9 upstream.

Whenever an ATA adapter driver is removed (e.g. rmmod), ata_port_detach() is called repeatedly for all the adapter ports to remove (unload) the devices attached to the port and delete the port device itself. Removing of devices is done using libata EH with the ATA_PFLAG_UNLOADING port flag set. This causes libata EH to execute ata_eh_unload() which disables all devices attached to the port.

ata_port_detach() finishes by calling scsi_remove_host() to remove the scsi host associated with the port. This function will trigger the removal of all scsi devices attached to the host and in the case of disks, calls to sd_shutdown() which will flush the device write cache and stop the device. However, given that the devices were already disabled by ata_eh_unload(), the synchronize write cache command and start stop unit commands fail. E.g. running "rmmod ahci" with first removing sd_mod results in error messages like:

ata13.00: disable device
sd 0:0:0:0: [sda] Synchronizing SCSI cache
sd 0:0:0:0: [sda] Synchronize Cache(10) failed: Result: hostbyte=DID_BAD_TARGET driverbyte=DRIVER_OK sd 0:0:0:0: [sda] Stopping disk
sd 0:0:0:0: [sda] Start/Stop Unit failed: Result: hostbyte=DID_BAD_TARGET driverbyte=DRIVER_OK

Fix this by removing all scsi devices of the ata devices connected to the port before scheduling libata EH to disable the ATA devices.

---
 drivers/ata/libata-core.c |   21 ++++++++++++++++++++-
 1 file changed, 20 insertions(+), 1 deletion(-)
drivers/ata/libata-core.c +20 -1
@@ -5940,11 +5940,30 @@ static void ata_port_detach(struct ata_p
 	if (!ap->ops->error_handler)
 		goto skip_eh;
 
-	/* tell EH we're leaving & flush EH */
+	/* Wait for any ongoing EH */
+	ata_port_wait_eh(ap);
+
+	mutex_lock(&ap->scsi_scan_mutex);
 	spin_lock_irqsave(ap->lock, flags);
+
+	/* Remove scsi devices */
+	ata_for_each_link(link, ap, HOST_FIRST) {
+		ata_for_each_dev(dev, link, ALL) {
+			if (dev->sdev) {
+				spin_unlock_irqrestore(ap->lock, flags);
+				scsi_remove_device(dev->sdev);
+				spin_lock_irqsave(ap->lock, flags);
+				dev->sdev = NULL;
+			}
+		}
+	}
+
+	/* Tell EH to disable all devices */
 	ap->pflags |= ATA_PFLAG_UNLOADING;
 	ata_port_schedule_eh(ap);
+
 	spin_unlock_irqrestore(ap->lock, flags);
+	mutex_unlock(&ap->scsi_scan_mutex);
 
 	/* wait till EH commits suicide */
 	ata_port_wait_eh(ap);
author maintainer
#179 lore raw

PATCH 179/183 ata: libata-core: Do not register PM operations for SAS ports

In reply to Greg Kroah-Hartman

5.15-stable review patch. If anyone has any objections, please let me know.

------------------

From: Damien Le Moal <[email protected]>

commit 75e2bd5f1ede42a2bc88aa34b431e1ace8e0bea0 upstream.

libsas does its own domain based power management of ports. For such ports, libata should not use a device type defining power management operations as executing these operations for suspend/resume in addition to libsas calls to ata_sas_port_suspend() and ata_sas_port_resume() is not necessary (and likely dangerous to do, even though problems are not seen currently).

Introduce the new ata_port_sas_type device_type for ports managed by libsas. This new device type is used in ata_tport_add() and is defined without power management operations.

---
 drivers/ata/libata-core.c      |    2 +-
 drivers/ata/libata-transport.c |    9 ++++++++-
 drivers/ata/libata.h           |    2 ++
 3 files changed, 11 insertions(+), 2 deletions(-)
drivers/ata/libata-core.c +1 -1
@@ -5192,7 +5192,7 @@ EXPORT_SYMBOL_GPL(ata_host_resume);
 #endif
 
 const struct device_type ata_port_type = {
-	.name = "ata_port",
+	.name = ATA_PORT_TYPE_NAME,
 #ifdef CONFIG_PM
 	.pm = &ata_port_pm_ops,
 #endif
drivers/ata/libata-transport.c +8 -1
@@ -266,6 +266,10 @@ void ata_tport_delete(struct ata_port *a
 	put_device(dev);
 }
 
+static const struct device_type ata_port_sas_type = {
+	.name = ATA_PORT_TYPE_NAME,
+};
+
 /** ata_tport_add - initialize a transport ATA port structure
  *
  * @parent:	parent device
@@ -283,7 +287,10 @@ int ata_tport_add(struct device *parent,
 	struct device *dev = &ap->tdev;
 
 	device_initialize(dev);
-	dev->type = &ata_port_type;
+	if (ap->flags & ATA_FLAG_SAS_HOST)
+		dev->type = &ata_port_sas_type;
+	else
+		dev->type = &ata_port_type;
 
 	dev->parent = parent;
 	ata_host_get(ap->host);
drivers/ata/libata.h +2 -0
@@ -30,6 +30,8 @@ enum {
 	ATA_DNXFER_QUIET	= (1 << 31),
 };
 
+#define ATA_PORT_TYPE_NAME	"ata_port"
+
 extern atomic_t ata_print_id;
 extern int atapi_passthru16;
 extern int libata_fua;
author maintainer
#180 lore raw

PATCH 180/183 ata: libata-sata: increase PMP SRST timeout to 10s

In reply to Greg Kroah-Hartman

5.15-stable review patch. If anyone has any objections, please let me know.

------------------

From: Matthias Schiffer <[email protected]>

commit 753a4d531bc518633ea88ac0ed02b25a16823d51 upstream.

On certain SATA controllers, softreset fails after wakeup from S2RAM with the message "softreset failed (1st FIS failed)", sometimes resulting in drives not being detected again. With the increased timeout, this issue is avoided. Instead, "softreset failed (device not ready)" is now logged 1-2 times; this later failure seems to cause fewer problems however, and the drives are detected reliably once they've spun up and the probe is retried.

The issue was observed with the primary SATA controller of the QNAP TS-453B, which is an "Intel Corporation Celeron/Pentium Silver Processor SATA Controller [8086:31e3] (rev 06)" integrated in the Celeron J4125 CPU, and the following drives:

- Seagate IronWolf ST12000VN0008
- Seagate IronWolf ST8000NE0004

The SATA controller seems to be more relevant to this issue than the drives, as the same drives are always detected reliably on the secondary SATA controller on the same board (an ASMedia 106x) without any "softreset failed" errors even without the increased timeout.

Fixes e7d3ef13d52a ("libata: change drive ready wait after hard reset to 5s")
---
 include/linux/libata.h |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
include/linux/libata.h +1 -1
@@ -301,7 +301,7 @@ enum {
 	 * advised to wait only for the following duration before
 	 * doing SRST.
 	 */
-	ATA_TMOUT_PMP_SRST_WAIT	= 5000,
+	ATA_TMOUT_PMP_SRST_WAIT	= 10000,
 
 	/* When the LPM policy is set to ATA_LPM_MAX_POWER, there might
 	 * be a spurious PHY event, so ignore the first PHY event that
author maintainer
#181 lore raw

PATCH 181/183 fs: binfmt_elf_efpic: fix personality for ELF-FDPIC

In reply to Greg Kroah-Hartman

5.15-stable review patch. If anyone has any objections, please let me know.

------------------

From: Greg Ungerer <[email protected]>

commit 7c3151585730b7095287be8162b846d31e6eee61 upstream.

The elf-fdpic loader hard sets the process personality to either PER_LINUX_FDPIC for true elf-fdpic binaries or to PER_LINUX for normal ELF binaries (in this case they would be constant displacement compiled with -pie for example). The problem with that is that it will lose any other bits that may be in the ELF header personality (such as the "bug emulation" bits).

On the ARM architecture the ADDR_LIMIT_32BIT flag is used to signify a normal 32bit binary - as opposed to a legacy 26bit address binary. This matters since start_thread() will set the ARM CPSR register as required based on this flag. If the elf-fdpic loader loses this bit the process will be mis-configured and crash out pretty quickly.

Modify elf-fdpic loader personality setting so that it preserves the upper three bytes by using the SET_PERSONALITY macro to set it. This macro in the generic case sets PER_LINUX and preserves the upper bytes. Architectures can override this for their specific use case, and ARM does exactly this.

The problem shows up quite easily running under qemu using the ARM architecture, but not necessarily on all types of real ARM hardware. If the underlying ARM processor does not support the legacy 26-bit addressing mode then everything will work as expected.

Fixes 1bde925d23547 ("fs/binfmt_elf_fdpic.c: provide NOMMU loader for regular ELF binaries")
Cc Al Viro <[email protected]>
Cc Christian Brauner <[email protected]>
Cc Eric W. Biederman <[email protected]>
Cc Greg Ungerer <[email protected]>
Cc Kees Cook <[email protected]>
---
 fs/binfmt_elf_fdpic.c |    5 ++---
 1 file changed, 2 insertions(+), 3 deletions(-)
fs/binfmt_elf_fdpic.c +2 -3
@@ -345,10 +345,9 @@ static int load_elf_fdpic_binary(struct
 	/* there's now no turning back... the old userspace image is dead,
 	 * defunct, deceased, etc.
 	 */
+	SET_PERSONALITY(exec_params.hdr);
 	if (elf_check_fdpic(&exec_params.hdr))
-		set_personality(PER_LINUX_FDPIC);
-	else
-		set_personality(PER_LINUX);
+		current->personality |= PER_LINUX_FDPIC;
 	if (elf_read_implies_exec(&exec_params.hdr, executable_stack))
 		current->personality |= READ_IMPLIES_EXEC;
 
author maintainer
#182 lore raw

PATCH 182/183 drm/meson: fix memory leak on ->hpd_notify callback

In reply to Greg Kroah-Hartman

5.15-stable review patch. If anyone has any objections, please let me know.

------------------

From: Jani Nikula <[email protected]>

commit 099f0af9d98231bb74956ce92508e87cbcb896be upstream.

The EDID returned by drm_bridge_get_edid() needs to be freed.

Fixes 0af5e0b41110 ("drm/meson: encoder_hdmi: switch to bridge DRM_BRIDGE_ATTACH_NO_CONNECTOR")
Cc Neil Armstrong <[email protected]>
Cc Sam Ravnborg <[email protected]>
Cc Martin Blumenstingl <[email protected]>
Cc Neil Armstrong <[email protected]>
Cc Kevin Hilman <[email protected]>
Cc Jerome Brunet <[email protected]>
Cc [email protected] # v5.17+
---
 drivers/gpu/drm/meson/meson_encoder_hdmi.c |    2 ++
 1 file changed, 2 insertions(+)
drivers/gpu/drm/meson/meson_encoder_hdmi.c +2 -0
@@ -326,6 +326,8 @@ static void meson_encoder_hdmi_hpd_notif
 			return;
 
 		cec_notifier_set_phys_addr_from_edid(encoder_hdmi->cec_notifier, edid);
+
+		kfree(edid);
 	} else
 		cec_notifier_phys_addr_invalidate(encoder_hdmi->cec_notifier);
 }
author maintainer
#183 lore raw

PATCH 183/183 netfilter: nf_tables: fix kdoc warnings after gc rework

In reply to Greg Kroah-Hartman

5.15-stable review patch. If anyone has any objections, please let me know.

------------------

From: Florian Westphal <[email protected]>

commit 08713cb006b6f07434f276c5ee214fb20c7fd965 upstream.

Jakub Kicinski says:
We've got some new kdoc warnings here:
net/netfilter/nft_set_pipapo.c:1557: warning: Function parameter or member '_set' not described in 'pipapo_gc' net/netfilter/nft_set_pipapo.c:1557: warning: Excess function parameter 'set' description in 'pipapo_gc' include/net/netfilter/nf_tables.h:577: warning: Function parameter or member 'dead' not described in 'nft_set'

Fixes 5f68718b34a5 ("netfilter: nf_tables: GC transaction API to avoid race with control plane")
Fixes f6c383b8c31a ("netfilter: nf_tables: adapt set backend to use GC transaction API")
---
 include/net/netfilter/nf_tables.h |    1 +
 net/netfilter/nft_set_pipapo.c    |    2 +-
 2 files changed, 2 insertions(+), 1 deletion(-)
include/net/netfilter/nf_tables.h +1 -0
@@ -499,6 +499,7 @@ struct nft_set_elem_expr {
  *	@expr: stateful expression
  * 	@ops: set ops
  * 	@flags: set flags
+ *	@dead: set will be freed, never cleared
  *	@genmask: generation mask
  * 	@klen: key length
  * 	@dlen: data length
net/netfilter/nft_set_pipapo.c +1 -1
@@ -1550,7 +1550,7 @@ static void nft_pipapo_gc_deactivate(str
 
 /**
  * pipapo_gc() - Drop expired entries from set, destroy start and end elements
- * @set:	nftables API set representation
+ * @_set:	nftables API set representation
  * @m:		Matching data
  */
 static void pipapo_gc(const struct nft_set *_set, struct nft_pipapo_match *m)
#184 lore raw
In reply to Greg Kroah-Hartman
Quoted 9 lines · Greg Kroah-Hartman

This is the start of the stable review cycle for the 5.15.134 release. There are 183 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 Fri, 06 Oct 2023 17:51:12 +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.134-rc1.gz

or in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-5.15.y
and the diffstat can be found below.

thanks,

greg k-h

perf fails to build with:

CC
/local/users/fainelli/buildroot/output/arm/build/linux-custom/tools/perf/util/metricgroup.o util/metricgroup.c: In function 'metricgroup__parse_groups':
util/metricgroup.c:1261:7: error: 'table' undeclared (first use in this function)
if (!table)

       ^~~~~

util/metricgroup.c:1261:7: note: each undeclared identifier is reported only once for each function it appears in
make[6]: *** [/local/users/fainelli/buildroot/output/arm/build/linux-custom/tools/build/Makefile.build:97: /local/users/fainelli/buildroot/output/arm/build/linux-custom/tools/perf/util/metricgroup.o] Error 1

caused by c1ef510a0f2a879bf29ddebae766ec9f0790eb8f ("perf metric: Return early if no CPU PMU table exists"). Dropping this commit allows the build to continue.

I had reported in the previous cycle that 00facc760903be66 ("perf jevents: Switch build to use jevents.py") was causing build failures:

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

do we still want these commits to be included?

Signature · 1 line
Florian
author maintainer
#185 lore raw
Quoted 36 lines · Florian Fainelli
Quoted 9 lines · Greg Kroah-Hartman

This is the start of the stable review cycle for the 5.15.134 release. There are 183 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 Fri, 06 Oct 2023 17:51:12 +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.134-rc1.gz

or in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-5.15.y
and the diffstat can be found below.

thanks,

greg k-h

perf fails to build with:

CC /local/users/fainelli/buildroot/output/arm/build/linux-custom/tools/perf/util/metricgroup.o
util/metricgroup.c: In function 'metricgroup__parse_groups':
util/metricgroup.c:1261:7: error: 'table' undeclared (first use in this function)
if (!table)

       ^~~~~

util/metricgroup.c:1261:7: note: each undeclared identifier is reported only
once for each function it appears in
make[6]: *** [/local/users/fainelli/buildroot/output/arm/build/linux-custom/tools/build/Makefile.build:97: /local/users/fainelli/buildroot/output/arm/build/linux-custom/tools/perf/util/metricgroup.o] Error 1

caused by c1ef510a0f2a879bf29ddebae766ec9f0790eb8f ("perf metric: Return early if no CPU PMU table exists"). Dropping this commit allows the build to continue.

Quoted 6 lines

I had reported in the previous cycle that 00facc760903be66 ("perf jevents:
Switch build to use jevents.py") was causing build failures:

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

do we still want these commits to be included?

No, I'll go drop them now, thanks for the report.

greg k-h

#186 lore raw
Quoted 37 lines · Greg Kroah-Hartman
Quoted 36 lines · Florian Fainelli
Quoted 9 lines · Greg Kroah-Hartman

This is the start of the stable review cycle for the 5.15.134 release. There are 183 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 Fri, 06 Oct 2023 17:51:12 +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.134-rc1.gz

or in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-5.15.y
and the diffstat can be found below.

thanks,

greg k-h

perf fails to build with:

CC /local/users/fainelli/buildroot/output/arm/build/linux-custom/tools/perf/util/metricgroup.o
util/metricgroup.c: In function 'metricgroup__parse_groups':
util/metricgroup.c:1261:7: error: 'table' undeclared (first use in this
function)
if (!table)

        ^~~~~

util/metricgroup.c:1261:7: note: each undeclared identifier is reported only
once for each function it appears in
make[6]: *** [/local/users/fainelli/buildroot/output/arm/build/linux-custom/tools/build/Makefile.build:97: /local/users/fainelli/buildroot/output/arm/build/linux-custom/tools/perf/util/metricgroup.o] Error 1

caused by c1ef510a0f2a879bf29ddebae766ec9f0790eb8f ("perf metric: Return early if no CPU PMU table exists"). Dropping this commit allows the build to continue.

Quoted 8 lines
Quoted 6 lines

I had reported in the previous cycle that 00facc760903be66 ("perf jevents:
Switch build to use jevents.py") was causing build failures:

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

do we still want these commits to be included?

No, I'll go drop them now, thanks for the report.

Thought:
It's not the first time we see build failures in tools/perf -- would it make sense to add this to your own build tests to reduce the round trip time for these errors ?

Note: After reverting three patches in perf/ the build succeeds:

Patch 151: c1ef510a0f2a perf metric: Return early if no CPU PMU table exists Patch 81: 40ddac4ffc75 perf build: Update build rule for generated files Patch 80: 8df938ed8c8a perf jevents: Switch build to use jevents.py

Thanks,
Harshit

Quoted 2 lines

greg k-h

author maintainer
#187 lore raw
Quoted 45 lines · Harshit Mogalapalli
Quoted 42 lines · Greg Kroah-Hartman
Quoted 41 lines · Florian Fainelli
Quoted 9 lines · Greg Kroah-Hartman

This is the start of the stable review cycle for the 5.15.134 release. There are 183 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 Fri, 06 Oct 2023 17:51:12 +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.134-rc1.gz

or in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-5.15.y
and the diffstat can be found below.

thanks,

greg k-h

perf fails to build with:

CC /local/users/fainelli/buildroot/output/arm/build/linux-custom/tools/perf/util/metricgroup.o
util/metricgroup.c: In function 'metricgroup__parse_groups':
util/metricgroup.c:1261:7: error: 'table' undeclared (first use in this
function)
if (!table)

        ^~~~~

util/metricgroup.c:1261:7: note: each undeclared identifier is reported only
once for each function it appears in
make[6]: *** [/local/users/fainelli/buildroot/output/arm/build/linux-custom/tools/build/Makefile.build:97: /local/users/fainelli/buildroot/output/arm/build/linux-custom/tools/perf/util/metricgroup.o] Error 1

caused by c1ef510a0f2a879bf29ddebae766ec9f0790eb8f ("perf metric: Return early if no CPU PMU table exists"). Dropping this commit allows the build to continue.

I had reported in the previous cycle that 00facc760903be66 ("perf jevents:
Switch build to use jevents.py") was causing build failures:

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

Quoted 8 lines
Quoted 3 lines
Quoted 1 line

do we still want these commits to be included?

No, I'll go drop them now, thanks for the report.

Thought:
It's not the first time we see build failures in tools/perf -- would it make sense to add this to your own build tests to reduce the round trip time for these errors ?

Last time I tried to build perf, I couldn't do it at all so I just gave up trying to test for it :)

Quoted 5 lines

Note: After reverting three patches in perf/ the build succeeds:

Patch 151: c1ef510a0f2a perf metric: Return early if no CPU PMU table exists Patch 81: 40ddac4ffc75 perf build: Update build rule for generated files Patch 80: 8df938ed8c8a perf jevents: Switch build to use jevents.py

All of these are now dropped.

thanks,

greg k-h

maintainer
#188 lore raw
Quoted 50 lines · Greg Kroah-Hartman
Quoted 49 lines · Harshit Mogalapalli
Quoted 45 lines · Greg Kroah-Hartman
Quoted 36 lines · Florian Fainelli
Quoted 9 lines · Greg Kroah-Hartman

This is the start of the stable review cycle for the 5.15.134 release. There are 183 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 Fri, 06 Oct 2023 17:51:12 +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.134-rc1.gz

or in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-5.15.y
and the diffstat can be found below.

thanks,

greg k-h

perf fails to build with:

CC /local/users/fainelli/buildroot/output/arm/build/linux-custom/tools/perf/util/metricgroup.o
util/metricgroup.c: In function 'metricgroup__parse_groups':
util/metricgroup.c:1261:7: error: 'table' undeclared (first use in this
function)
if (!table)

        ^~~~~

util/metricgroup.c:1261:7: note: each undeclared identifier is reported only
once for each function it appears in
make[6]: *** [/local/users/fainelli/buildroot/output/arm/build/linux-custom/tools/build/Makefile.build:97: /local/users/fainelli/buildroot/output/arm/build/linux-custom/tools/perf/util/metricgroup.o] Error 1

caused by c1ef510a0f2a879bf29ddebae766ec9f0790eb8f ("perf metric: Return early if no CPU PMU table exists"). Dropping this commit allows the build to continue.

Quoted 6 lines

I had reported in the previous cycle that 00facc760903be66 ("perf jevents:
Switch build to use jevents.py") was causing build failures:

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

do we still want these commits to be included?

No, I'll go drop them now, thanks for the report.

Quoted 7 lines
Quoted 4 lines

Thought:
It's not the first time we see build failures in tools/perf -- would it make sense to add this to your own build tests to reduce the round trip time for these errors ?

Last time I tried to build perf, I couldn't do it at all so I just gave up trying to test for it :)

Same... I've also removed perf from AUTOSEL for that reason.

Signature · 2 lines
Thanks,
Sasha
#189 lore raw
Quoted 69 lines · Sasha Levin
Quoted 68 lines · Greg Kroah-Hartman
Quoted 66 lines · Harshit Mogalapalli
Quoted 3 lines · Greg Kroah-Hartman
Quoted 2 lines · Florian Fainelli
Quoted 1 line · Greg Kroah-Hartman

This is the start of the stable review cycle for the 5.15.134

release.

Quoted 1 line
Quoted 1 line
Quoted 1 line

There are 183 patches in this series, all will be posted as a

response

Quoted 1 line
Quoted 1 line
Quoted 1 line

to this one.  If anyone has any issues with these being

applied, please

Quoted 7 lines
Quoted 7 lines
Quoted 7 lines

let me know.

Responses should be made by Fri, 06 Oct 2023 17:51:12 +0000. Anything received after that time might be too late.

The whole patch series can be found in one patch at:

https://www.kernel.org/pub/linux/kernel/v5.x/stable-review/patch-5.15.134-rc1.gz

Quoted 2 lines
Quoted 2 lines
Quoted 2 lines

or in the git tree and branch at:

git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-5.15.y

Quoted 9 lines
Quoted 9 lines
Quoted 5 lines

and the diffstat can be found below.

thanks,

greg k-h

perf fails to build with:

    CC

/local/users/fainelli/buildroot/output/arm/build/linux-custom/tools/perf/util/metricgroup.o

Quoted 2 lines
Quoted 2 lines

util/metricgroup.c: In function 'metricgroup__parse_groups':
util/metricgroup.c:1261:7: error: 'table' undeclared (first use

in this

Quoted 4 lines
Quoted 4 lines

function)
    if (!table)
         ^~~~~
util/metricgroup.c:1261:7: note: each undeclared identifier is

reported only

Quoted 2 lines
Quoted 2 lines

once for each function it appears in
make[6]: ***

[/local/users/fainelli/buildroot/output/arm/build/linux-custom/tools/build/Makefile.build:97: /local/users/fainelli/buildroot/output/arm/build/linux-custom/tools/perf/util/metricgroup.o]

Quoted 3 lines
Quoted 3 lines

Error 1

caused by c1ef510a0f2a879bf29ddebae766ec9f0790eb8f ("perf metric:

Return

Quoted 1 line
Quoted 1 line

early if no CPU PMU table exists"). Dropping this commit allows

the build to

Quoted 3 lines
Quoted 3 lines

continue.

I had reported in the previous cycle that 00facc760903be66 ("perf

jevents:

Quoted 3 lines
Quoted 3 lines

Switch build to use jevents.py") was causing build failures:

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

Quoted 4 lines
Quoted 2 lines

do we still want these commits to be included?

No, I'll go drop them now, thanks for the report.

Thought:
It's not the first time we see build failures in tools/perf -- would it make sense to add this to your own build tests to reduce the round trip time for these errors ?

Quoted 4 lines
Quoted 2 lines

Last time I tried to build perf, I couldn't do it at all so I just gave up trying to test for it :)

Same... I've also removed perf from AUTOSEL for that reason.

I suppose that is fair, if there is a critical bug in perf, we could submit it "manually" to ensure it reaches the stable trees. Probably better managed that way. Thanks!

Signature · 1 line
Florian
Tested-by on the v1 series
#190 lore raw
In reply to Greg Kroah-Hartman
Quoted 9 lines · Greg Kroah-Hartman

This is the start of the stable review cycle for the 5.15.134 release. There are 183 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 Fri, 06 Oct 2023 17:51:12 +0000. Anything received after that time might be too late.

The whole patch series can be found in one patch at:

Quoted 9 lines
	https://www.kernel.org/pub/linux/kernel/v5.x/stable-review/patch-5.15.134-rc1.gz

or in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-5.15.y
and the diffstat can be found below.

thanks,

greg k-h

Compiled and booted on my test system. No dmesg regressions.

thanks,
-- Shuah

maintainer Tested-by on the v1 series
#191 lore raw
In reply to Greg Kroah-Hartman

Hello,

Quoted 5 lines · On Wed, 4 Oct 2023 19:53:51 +0200 Greg Kroah-Hartman…

This is the start of the stable review cycle for the 5.15.134 release. There are 183 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 8 lines

Responses should be made by Fri, 06 Oct 2023 17:51:12 +0000. Anything received after that time might be too late.

The whole patch series can be found in one patch at:

	https://www.kernel.org/pub/linux/kernel/v5.x/stable-review/patch-5.15.134-rc1.gz

or in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-5.15.y
and the diffstat can be found below.

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/awslabs/damon-tests/tree/next/corr
[2] 6f28ecf24aef ("Linux 5.15.134-rc1")

Thanks,
SJ

[...]

---

# .config:1347:warning: override: reassigning to symbol DAMON ok 12 selftests: damon-tests: build_i386_idle_flag.sh # selftests: damon-tests: build_i386_highpte.sh
# .config:1347:warning: override: reassigning to symbol DAMON ok 13 selftests: damon-tests: build_i386_highpte.sh
# selftests: damon-tests: build_nomemcg.sh
# .config:1348:warning: override: reassigning to symbol DAMON # .config:1358:warning: override: reassigning to symbol CGROUPS ok 14 selftests: damon-tests: build_nomemcg.sh

# kselftest dir '/home/sjpark/damon-tests-cont/linux/tools/testing/selftests/damon-tests' is in dirty state.
# the log is at '/home/sjpark/log'.
 [32m
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
ok 12 selftests: damon-tests: build_i386_idle_flag.sh
ok 13 selftests: damon-tests: build_i386_highpte.sh
ok 14 selftests: damon-tests: build_nomemcg.sh
 [33m
 [92mPASS [39m
_remote_run_corr.sh SUCCESS
#192 lore raw
In reply to Greg Kroah-Hartman
Quoted 10 lines · Greg Kroah-Hartman

This is the start of the stable review cycle for the 5.15.134 release. There are 183 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 Fri, 06 Oct 2023 17:51:12 +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.134-rc1.gz

or in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-5.15.y
and the diffstat can be found below.

thanks,

greg k-h

Results from Linaro’s test farm.
Regressions on x86.

Following kernel warning noticed on x86 while booting stable-rc 5.15.134-rc1 with selftest merge config built kernel.

Anyone noticed this kernel warning ?

This is always reproducible while booting x86 with a given config.

x86 boot log:
-----

[    0.000000] Linux version 5.15.134-rc1 (tuxmake@tuxmake)
(x86_64-linux-gnu-gcc (Debian 12.2.0-14) 12.2.0, GNU ld (GNU Binutils
for Debian) 2.40) #1 SMP @1696443178
...
[    1.480701] ------------[ cut here ]------------
[    1.481296] WARNING: CPU: 0 PID: 13 at kernel/rcu/tasks.h:958
trc_inspect_reader+0x80/0xb0
[    1.481296] Modules linked in:
[    1.481296] CPU: 0 PID: 13 Comm: rcu_tasks_trace Not tainted 5.15.134-rc1 #1
[    1.481296] Hardware name: Supermicro SYS-5019S-ML/X11SSH-F, BIOS
2.5 11/26/2020
[    1.481296] RIP: 0010:trc_inspect_reader+0x80/0xb0
[    1.481296] Code: b6 83 45 04 00 00 84 c0 75 48 c6 83 45 04 00 00
01 b8 01 00 00 00 5b 41 5c 5d c3 cc cc cc cc 0f 94 c0 eb b4 f6 43 2c
02 75 02 <0f> 0b 48 83 05 36 f8 ee 02 01 b8 01 00 00 00 48 83 05 21 f8
ee 02
[    1.481296] RSP: 0000:ffffb25e000afd70 EFLAGS: 00010046
[    1.481296] RAX: 0000000000000000 RBX: ffff9b40c080d040 RCX: 0000000000000003
[    1.481296] RDX: ffff9b4427b80000 RSI: 0000000000000000 RDI: ffff9b40c080d040
[    1.481296] RBP: ffffb25e000afd80 R08: e32db91cdfdc3bef R09: 00000000035b89d4
[    1.481296] R10: 000000006a495065 R11: 0000000000000030 R12: ffffffffae692100
[    1.481296] R13: 0000000000000000 R14: ffff9b40c080d9a8 R15: 0000000000000000
[    1.481296] FS:  0000000000000000(0000) GS:ffff9b4427a00000(0000)
knlGS:0000000000000000
[    1.481296] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[    1.481296] CR2: ffff9b4297201000 CR3: 00000002d5e26001 CR4: 00000000003706f0
[    1.481296] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[    1.481296] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
[    1.481296] Call Trace:
[    1.481296]  <TASK>
[    1.481296]  ? show_regs.cold+0x1a/0x1f
[    1.481296]  ? __warn+0x88/0x120
[    1.481296]  ? trc_inspect_reader+0x80/0xb0
[    1.481296]  ? report_bug+0xa8/0xd0
[    1.481296]  ? handle_bug+0x40/0x70
[    1.481296]  ? exc_invalid_op+0x18/0x70
[    1.481296]  ? asm_exc_invalid_op+0x1b/0x20
[    1.481296]  ? rcu_tasks_kthread+0x250/0x250
[    1.481296]  ? trc_inspect_reader+0x80/0xb0
[    1.481296]  ? rcu_tasks_kthread+0x250/0x250
[    1.481296]  try_invoke_on_locked_down_task+0x109/0x120
[    1.481296]  trc_wait_for_one_reader.part.0+0x48/0x270
[    1.481296]  rcu_tasks_trace_postscan+0x76/0xb0
[    1.481296]  rcu_tasks_wait_gp+0x186/0x380
[    1.481296]  ? _raw_spin_unlock_irqrestore+0x35/0x50
[    1.481296]  rcu_tasks_kthread+0x145/0x250
[    1.481296]  ? do_wait_intr_irq+0xc0/0xc0
[    1.481296]  ? synchronize_rcu_tasks_rude+0x20/0x20
[    1.481296]  kthread+0x146/0x170
[    1.481296]  ? set_kthread_struct+0x50/0x50
[    1.481296]  ret_from_fork+0x1f/0x30
[    1.481296]  </TASK>
[    1.481296] irq event stamp: 132
[    1.481296] hardirqs last  enabled at (131): [<ffffffffaf7936a5>]
_raw_spin_unlock_irqrestore+0x35/0x50
[    1.481296] hardirqs last disabled at (132): [<ffffffffaf79345b>]
_raw_spin_lock_irqsave+0x5b/0x60
[    1.481296] softirqs last  enabled at (54): [<ffffffffae69201c>]
rcu_tasks_kthread+0x16c/0x250
[    1.481296] softirqs last disabled at (50): [<ffffffffae69201c>]
rcu_tasks_kthread+0x16c/0x250
[    1.481296] ---[ end trace 5a00c61d8412a9ac ]---

Links:
----
- https://qa-reports.linaro.org/lkft/linux-stable-rc-linux-5.15.y/build/v5.15.133-184-g6f28ecf24aef/testrun/20260259/suite/log-parser-boot/test/check-kernel-exception/log
- https://qa-reports.linaro.org/lkft/linux-stable-rc-linux-5.15.y/build/v5.15.133-184-g6f28ecf24aef/testrun/20260259/suite/log-parser-boot/tests/
Build: https://storage.tuxsuite.com/public/linaro/lkft/builds/2WJFhcfqqG69pqj6LWuI14kVoP5/

steps to reproduce:
--------
- https://storage.tuxsuite.com/public/linaro/lkft/builds/2WJFhcfqqG69pqj6LWuI14kVoP5/tuxmake_reproducer.sh

## Build
* kernel: 5.15.134-rc1
* git: https://gitlab.com/Linaro/lkft/mirrors/stable/linux-stable-rc
* git branch: linux-5.15.y
* git commit: 6f28ecf24aef2896f4071dc6268d3fb5f8259c77
* git describe: v5.15.133-184-g6f28ecf24aef
* test details:
https://qa-reports.linaro.org/lkft/linux-stable-rc-linux-5.15.y/build/v5.15.133-184-g6f28ecf24aef

## Test Regressions (compared to v5.15.133)
* x86, log-parser-boot
- check-kernel-exception
- check-kernel-warning

* x86, log-parser-test
- check-kernel-exception
- check-kernel-warning

## Metric Regressions (compared to v5.15.133)

## Test Fixes (compared to v5.15.133)

## Metric Fixes (compared to v5.15.133)

## Test result summary
total: 90392, pass: 71514, fail: 2557, skip: 16224, xfail: 97

## Build Summary
* arc: 4 total, 4 passed, 0 failed
* arm: 114 total, 114 passed, 0 failed
* arm64: 42 total, 42 passed, 0 failed
* i386: 32 total, 31 passed, 1 failed
* mips: 27 total, 26 passed, 1 failed
* parisc: 4 total, 4 passed, 0 failed
* powerpc: 26 total, 25 passed, 1 failed
* riscv: 11 total, 11 passed, 0 failed
* s390: 12 total, 11 passed, 1 failed
* sh: 13 total, 11 passed, 2 failed
* sparc: 8 total, 8 passed, 0 failed
* x86_64: 38 total, 38 passed, 0 failed

## Test suites summary
* boot
* kselftest-android
* kselftest-arm64
* kselftest-breakpoints
* kselftest-capabilities
* kselftest-cgroup
* kselftest-clone3
* kselftest-core
* kselftest-cpu-hotplug
* kselftest-cpufreq
* kselftest-drivers-dma-buf
* kselftest-efivarfs
* kselftest-exec
* kselftest-filesystems
* kselftest-filesystems-binderfs
* kselftest-filesystems-epoll
* kselftest-firmware
* kselftest-fpu
* kselftest-ftrace
* kselftest-futex
* kselftest-gpio
* kselftest-intel_pstate
* kselftest-ipc
* kselftest-ir
* kselftest-kcmp
* kselftest-kexec
* kselftest-kvm
* kselftest-lib
* kselftest-membarrier
* kselftest-memfd
* kselftest-memory-hotplug
* kselftest-mincore
* kselftest-mount
* kselftest-mqueue
* kselftest-net
* kselftest-net-forwarding
* kselftest-net-mptcp
* kselftest-netfilter
* kselftest-nsfs
* kselftest-openat2
* kselftest-pid_namespace
* kselftest-pidfd
* kselftest-proc
* kselftest-pstore
* kselftest-ptrace
* kselftest-rseq
* kselftest-rtc
* kselftest-seccomp
* kselftest-sigaltstack
* kselftest-size
* kselftest-splice
* kselftest-static_keys
* kselftest-sync
* kselftest-sysctl
* kselftest-tc-testing
* kselftest-timens
* kselftest-tmpfs
* kselftest-tpm2
* kselftest-user
* kselftest-user_events
* kselftest-vDSO
* kselftest-vm
* kselftest-watchdog
* kselftest-x86
* kselftest-zram
* kunit
* kvm-unit-tests
* libgpiod
* log-parser-boot
* log-parser-test
* ltp-cap_bounds
* ltp-commands
* ltp-containers
* ltp-controllers
* ltp-cpuhotplug
* ltp-crypto
* ltp-cve
* ltp-dio
* ltp-fcntl-locktests
* ltp-filecaps
* ltp-fs
* ltp-fs_bind
* ltp-fs_perms_simple
* ltp-fsx
* ltp-hugetlb
* ltp-io
* ltp-ipc
* ltp-math
* ltp-mm
* ltp-nptl
* ltp-pty
* ltp-sched
* ltp-securebits
* ltp-smoke
* ltp-syscalls
* ltp-tracing
* network-basic-tests
* perf
* rcutorture
* v4l2-compliance

--
Linaro LKFT
https://lkft.linaro.org

#193 lore raw
Quoted 24 lines · Naresh Kamboju
Quoted 10 lines · Greg Kroah-Hartman

This is the start of the stable review cycle for the 5.15.134 release. There are 183 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 Fri, 06 Oct 2023 17:51:12 +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.134-rc1.gz

or in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-5.15.y
and the diffstat can be found below.

thanks,

greg k-h

Results from Linaro’s test farm.
Regressions on x86.

Quoted 8 lines

Following kernel warning noticed on x86 while booting stable-rc 5.15.134-rc1 with selftest merge config built kernel.

Anyone noticed this kernel warning ?

This is always reproducible while booting x86 with a given config.

From that config:
#
# RCU Subsystem
#
CONFIG_TREE_RCU=y
# CONFIG_RCU_EXPERT is not set
CONFIG_SRCU=y
CONFIG_TREE_SRCU=y
CONFIG_TASKS_RCU_GENERIC=y
CONFIG_TASKS_RUDE_RCU=y
CONFIG_TASKS_TRACE_RCU=y
CONFIG_RCU_STALL_COMMON=y
CONFIG_RCU_NEED_SEGCBLIST=y

# end of RCU Subsystem    

#
# RCU Debugging
#
CONFIG_PROVE_RCU=y
# CONFIG_RCU_SCALE_TEST is not set
# CONFIG_RCU_TORTURE_TEST is not set
# CONFIG_RCU_REF_SCALE_TEST is not set
CONFIG_RCU_CPU_STALL_TIMEOUT=21
CONFIG_RCU_TRACE=y
# CONFIG_RCU_EQS_DEBUG is not set

# end of RCU Debugging
Quoted 15 lines

x86 boot log:
-----

[    0.000000] Linux version 5.15.134-rc1 (tuxmake@tuxmake)
(x86_64-linux-gnu-gcc (Debian 12.2.0-14) 12.2.0, GNU ld (GNU Binutils
for Debian) 2.40) #1 SMP @1696443178
...
[    1.480701] ------------[ cut here ]------------
[    1.481296] WARNING: CPU: 0 PID: 13 at kernel/rcu/tasks.h:958
trc_inspect_reader+0x80/0xb0
[    1.481296] Modules linked in:
[    1.481296] CPU: 0 PID: 13 Comm: rcu_tasks_trace Not tainted 5.15.134-rc1 #1
[    1.481296] Hardware name: Supermicro SYS-5019S-ML/X11SSH-F, BIOS
2.5 11/26/2020
[    1.481296] RIP: 0010:trc_inspect_reader+0x80/0xb0

This function has changed a lot, including the dropping of this WARN_ON_ONCE(). The warning was replaced in 897ba84dc5aa ("rcu-tasks:
Handle idle tasks for recently offlined CPUs") with something that looks equivalent so I'm not sure why it would not trigger in newer revisions.

Obviously the behaviour I changed was the test for the task being idle. I am not sure how best to short-circuit that test from happening during boot as I am not familiar with the RCU code.

It's also worth noting that the bug this fixes wasn't exposed until the maple tree (added in v6.1) was used for the IRQ descriptors (added in v6.5).

Quoted 209 lines
[    1.481296] Code: b6 83 45 04 00 00 84 c0 75 48 c6 83 45 04 00 00
01 b8 01 00 00 00 5b 41 5c 5d c3 cc cc cc cc 0f 94 c0 eb b4 f6 43 2c
02 75 02 <0f> 0b 48 83 05 36 f8 ee 02 01 b8 01 00 00 00 48 83 05 21 f8
ee 02
[    1.481296] RSP: 0000:ffffb25e000afd70 EFLAGS: 00010046
[    1.481296] RAX: 0000000000000000 RBX: ffff9b40c080d040 RCX: 0000000000000003
[    1.481296] RDX: ffff9b4427b80000 RSI: 0000000000000000 RDI: ffff9b40c080d040
[    1.481296] RBP: ffffb25e000afd80 R08: e32db91cdfdc3bef R09: 00000000035b89d4
[    1.481296] R10: 000000006a495065 R11: 0000000000000030 R12: ffffffffae692100
[    1.481296] R13: 0000000000000000 R14: ffff9b40c080d9a8 R15: 0000000000000000
[    1.481296] FS:  0000000000000000(0000) GS:ffff9b4427a00000(0000)
knlGS:0000000000000000
[    1.481296] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[    1.481296] CR2: ffff9b4297201000 CR3: 00000002d5e26001 CR4: 00000000003706f0
[    1.481296] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[    1.481296] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
[    1.481296] Call Trace:
[    1.481296]  <TASK>
[    1.481296]  ? show_regs.cold+0x1a/0x1f
[    1.481296]  ? __warn+0x88/0x120
[    1.481296]  ? trc_inspect_reader+0x80/0xb0
[    1.481296]  ? report_bug+0xa8/0xd0
[    1.481296]  ? handle_bug+0x40/0x70
[    1.481296]  ? exc_invalid_op+0x18/0x70
[    1.481296]  ? asm_exc_invalid_op+0x1b/0x20
[    1.481296]  ? rcu_tasks_kthread+0x250/0x250
[    1.481296]  ? trc_inspect_reader+0x80/0xb0
[    1.481296]  ? rcu_tasks_kthread+0x250/0x250
[    1.481296]  try_invoke_on_locked_down_task+0x109/0x120
[    1.481296]  trc_wait_for_one_reader.part.0+0x48/0x270
[    1.481296]  rcu_tasks_trace_postscan+0x76/0xb0
[    1.481296]  rcu_tasks_wait_gp+0x186/0x380
[    1.481296]  ? _raw_spin_unlock_irqrestore+0x35/0x50
[    1.481296]  rcu_tasks_kthread+0x145/0x250
[    1.481296]  ? do_wait_intr_irq+0xc0/0xc0
[    1.481296]  ? synchronize_rcu_tasks_rude+0x20/0x20
[    1.481296]  kthread+0x146/0x170
[    1.481296]  ? set_kthread_struct+0x50/0x50
[    1.481296]  ret_from_fork+0x1f/0x30
[    1.481296]  </TASK>
[    1.481296] irq event stamp: 132
[    1.481296] hardirqs last  enabled at (131): [<ffffffffaf7936a5>]
_raw_spin_unlock_irqrestore+0x35/0x50
[    1.481296] hardirqs last disabled at (132): [<ffffffffaf79345b>]
_raw_spin_lock_irqsave+0x5b/0x60
[    1.481296] softirqs last  enabled at (54): [<ffffffffae69201c>]
rcu_tasks_kthread+0x16c/0x250
[    1.481296] softirqs last disabled at (50): [<ffffffffae69201c>]
rcu_tasks_kthread+0x16c/0x250
[    1.481296] ---[ end trace 5a00c61d8412a9ac ]---

Links:
----
- https://qa-reports.linaro.org/lkft/linux-stable-rc-linux-5.15.y/build/v5.15.133-184-g6f28ecf24aef/testrun/20260259/suite/log-parser-boot/test/check-kernel-exception/log
- https://qa-reports.linaro.org/lkft/linux-stable-rc-linux-5.15.y/build/v5.15.133-184-g6f28ecf24aef/testrun/20260259/suite/log-parser-boot/tests/
Build: https://storage.tuxsuite.com/public/linaro/lkft/builds/2WJFhcfqqG69pqj6LWuI14kVoP5/

steps to reproduce:
--------
- https://storage.tuxsuite.com/public/linaro/lkft/builds/2WJFhcfqqG69pqj6LWuI14kVoP5/tuxmake_reproducer.sh

## Build
* kernel: 5.15.134-rc1
* git: https://gitlab.com/Linaro/lkft/mirrors/stable/linux-stable-rc
* git branch: linux-5.15.y
* git commit: 6f28ecf24aef2896f4071dc6268d3fb5f8259c77
* git describe: v5.15.133-184-g6f28ecf24aef
* test details:
https://qa-reports.linaro.org/lkft/linux-stable-rc-linux-5.15.y/build/v5.15.133-184-g6f28ecf24aef

## Test Regressions (compared to v5.15.133)
* x86, log-parser-boot
- check-kernel-exception
- check-kernel-warning

* x86, log-parser-test
- check-kernel-exception
- check-kernel-warning

## Metric Regressions (compared to v5.15.133)

## Test Fixes (compared to v5.15.133)

## Metric Fixes (compared to v5.15.133)

## Test result summary
total: 90392, pass: 71514, fail: 2557, skip: 16224, xfail: 97

## Build Summary
* arc: 4 total, 4 passed, 0 failed
* arm: 114 total, 114 passed, 0 failed
* arm64: 42 total, 42 passed, 0 failed
* i386: 32 total, 31 passed, 1 failed
* mips: 27 total, 26 passed, 1 failed
* parisc: 4 total, 4 passed, 0 failed
* powerpc: 26 total, 25 passed, 1 failed
* riscv: 11 total, 11 passed, 0 failed
* s390: 12 total, 11 passed, 1 failed
* sh: 13 total, 11 passed, 2 failed
* sparc: 8 total, 8 passed, 0 failed
* x86_64: 38 total, 38 passed, 0 failed

## Test suites summary
* boot
* kselftest-android
* kselftest-arm64
* kselftest-breakpoints
* kselftest-capabilities
* kselftest-cgroup
* kselftest-clone3
* kselftest-core
* kselftest-cpu-hotplug
* kselftest-cpufreq
* kselftest-drivers-dma-buf
* kselftest-efivarfs
* kselftest-exec
* kselftest-filesystems
* kselftest-filesystems-binderfs
* kselftest-filesystems-epoll
* kselftest-firmware
* kselftest-fpu
* kselftest-ftrace
* kselftest-futex
* kselftest-gpio
* kselftest-intel_pstate
* kselftest-ipc
* kselftest-ir
* kselftest-kcmp
* kselftest-kexec
* kselftest-kvm
* kselftest-lib
* kselftest-membarrier
* kselftest-memfd
* kselftest-memory-hotplug
* kselftest-mincore
* kselftest-mount
* kselftest-mqueue
* kselftest-net
* kselftest-net-forwarding
* kselftest-net-mptcp
* kselftest-netfilter
* kselftest-nsfs
* kselftest-openat2
* kselftest-pid_namespace
* kselftest-pidfd
* kselftest-proc
* kselftest-pstore
* kselftest-ptrace
* kselftest-rseq
* kselftest-rtc
* kselftest-seccomp
* kselftest-sigaltstack
* kselftest-size
* kselftest-splice
* kselftest-static_keys
* kselftest-sync
* kselftest-sysctl
* kselftest-tc-testing
* kselftest-timens
* kselftest-tmpfs
* kselftest-tpm2
* kselftest-user
* kselftest-user_events
* kselftest-vDSO
* kselftest-vm
* kselftest-watchdog
* kselftest-x86
* kselftest-zram
* kunit
* kvm-unit-tests
* libgpiod
* log-parser-boot
* log-parser-test
* ltp-cap_bounds
* ltp-commands
* ltp-containers
* ltp-controllers
* ltp-cpuhotplug
* ltp-crypto
* ltp-cve
* ltp-dio
* ltp-fcntl-locktests
* ltp-filecaps
* ltp-fs
* ltp-fs_bind
* ltp-fs_perms_simple
* ltp-fsx
* ltp-hugetlb
* ltp-io
* ltp-ipc
* ltp-math
* ltp-mm
* ltp-nptl
* ltp-pty
* ltp-sched
* ltp-securebits
* ltp-smoke
* ltp-syscalls
* ltp-tracing
* network-basic-tests
* perf
* rcutorture
* v4l2-compliance

--
Linaro LKFT
https://lkft.linaro.org

maintainer
#194 lore raw
Quoted 78 lines · Liam R. Howlett
Quoted 27 lines · Naresh Kamboju
Quoted 10 lines · Greg Kroah-Hartman

This is the start of the stable review cycle for the 5.15.134 release. There are 183 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 Fri, 06 Oct 2023 17:51:12 +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.134-rc1.gz

or in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-5.15.y
and the diffstat can be found below.

thanks,

greg k-h

Results from Linaro’s test farm.
Regressions on x86.

Following kernel warning noticed on x86 while booting stable-rc 5.15.134-rc1 with selftest merge config built kernel.

Quoted 7 lines

Anyone noticed this kernel warning ?

This is always reproducible while booting x86 with a given config.

From that config:

#
# RCU Subsystem
#
CONFIG_TREE_RCU=y
# CONFIG_RCU_EXPERT is not set
CONFIG_SRCU=y
CONFIG_TREE_SRCU=y
CONFIG_TASKS_RCU_GENERIC=y
CONFIG_TASKS_RUDE_RCU=y
CONFIG_TASKS_TRACE_RCU=y
CONFIG_RCU_STALL_COMMON=y
CONFIG_RCU_NEED_SEGCBLIST=y

# end of RCU Subsystem    

#
# RCU Debugging
#
CONFIG_PROVE_RCU=y
# CONFIG_RCU_SCALE_TEST is not set
# CONFIG_RCU_TORTURE_TEST is not set
# CONFIG_RCU_REF_SCALE_TEST is not set
CONFIG_RCU_CPU_STALL_TIMEOUT=21
CONFIG_RCU_TRACE=y
# CONFIG_RCU_EQS_DEBUG is not set

# end of RCU Debugging
Quoted 15 lines

x86 boot log:
-----

[    0.000000] Linux version 5.15.134-rc1 (tuxmake@tuxmake)
(x86_64-linux-gnu-gcc (Debian 12.2.0-14) 12.2.0, GNU ld (GNU Binutils
for Debian) 2.40) #1 SMP @1696443178
...
[    1.480701] ------------[ cut here ]------------
[    1.481296] WARNING: CPU: 0 PID: 13 at kernel/rcu/tasks.h:958
trc_inspect_reader+0x80/0xb0
[    1.481296] Modules linked in:
[    1.481296] CPU: 0 PID: 13 Comm: rcu_tasks_trace Not tainted 5.15.134-rc1 #1
[    1.481296] Hardware name: Supermicro SYS-5019S-ML/X11SSH-F, BIOS
2.5 11/26/2020
[    1.481296] RIP: 0010:trc_inspect_reader+0x80/0xb0
Quoted 8 lines

This function has changed a lot, including the dropping of this WARN_ON_ONCE(). The warning was replaced in 897ba84dc5aa ("rcu-tasks:
Handle idle tasks for recently offlined CPUs") with something that looks equivalent so I'm not sure why it would not trigger in newer revisions.

Obviously the behaviour I changed was the test for the task being idle. I am not sure how best to short-circuit that test from happening during boot as I am not familiar with the RCU code.

The usual test for RCU's notion of early boot being completed is (rcu_scheduler_active != RCU_SCHEDULER_INIT).

Except that "ofl" should always be false that early in boot, at least in mainline.

Quoted 3 lines

It's also worth noting that the bug this fixes wasn't exposed until the maple tree (added in v6.1) was used for the IRQ descriptors (added in v6.5).

Lots of latent bugs, to be sure, even with rcutorture. :-/

Thanx, Paul

Quoted 209 lines
Quoted 209 lines
[    1.481296] Code: b6 83 45 04 00 00 84 c0 75 48 c6 83 45 04 00 00
01 b8 01 00 00 00 5b 41 5c 5d c3 cc cc cc cc 0f 94 c0 eb b4 f6 43 2c
02 75 02 <0f> 0b 48 83 05 36 f8 ee 02 01 b8 01 00 00 00 48 83 05 21 f8
ee 02
[    1.481296] RSP: 0000:ffffb25e000afd70 EFLAGS: 00010046
[    1.481296] RAX: 0000000000000000 RBX: ffff9b40c080d040 RCX: 0000000000000003
[    1.481296] RDX: ffff9b4427b80000 RSI: 0000000000000000 RDI: ffff9b40c080d040
[    1.481296] RBP: ffffb25e000afd80 R08: e32db91cdfdc3bef R09: 00000000035b89d4
[    1.481296] R10: 000000006a495065 R11: 0000000000000030 R12: ffffffffae692100
[    1.481296] R13: 0000000000000000 R14: ffff9b40c080d9a8 R15: 0000000000000000
[    1.481296] FS:  0000000000000000(0000) GS:ffff9b4427a00000(0000)
knlGS:0000000000000000
[    1.481296] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[    1.481296] CR2: ffff9b4297201000 CR3: 00000002d5e26001 CR4: 00000000003706f0
[    1.481296] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[    1.481296] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
[    1.481296] Call Trace:
[    1.481296]  <TASK>
[    1.481296]  ? show_regs.cold+0x1a/0x1f
[    1.481296]  ? __warn+0x88/0x120
[    1.481296]  ? trc_inspect_reader+0x80/0xb0
[    1.481296]  ? report_bug+0xa8/0xd0
[    1.481296]  ? handle_bug+0x40/0x70
[    1.481296]  ? exc_invalid_op+0x18/0x70
[    1.481296]  ? asm_exc_invalid_op+0x1b/0x20
[    1.481296]  ? rcu_tasks_kthread+0x250/0x250
[    1.481296]  ? trc_inspect_reader+0x80/0xb0
[    1.481296]  ? rcu_tasks_kthread+0x250/0x250
[    1.481296]  try_invoke_on_locked_down_task+0x109/0x120
[    1.481296]  trc_wait_for_one_reader.part.0+0x48/0x270
[    1.481296]  rcu_tasks_trace_postscan+0x76/0xb0
[    1.481296]  rcu_tasks_wait_gp+0x186/0x380
[    1.481296]  ? _raw_spin_unlock_irqrestore+0x35/0x50
[    1.481296]  rcu_tasks_kthread+0x145/0x250
[    1.481296]  ? do_wait_intr_irq+0xc0/0xc0
[    1.481296]  ? synchronize_rcu_tasks_rude+0x20/0x20
[    1.481296]  kthread+0x146/0x170
[    1.481296]  ? set_kthread_struct+0x50/0x50
[    1.481296]  ret_from_fork+0x1f/0x30
[    1.481296]  </TASK>
[    1.481296] irq event stamp: 132
[    1.481296] hardirqs last  enabled at (131): [<ffffffffaf7936a5>]
_raw_spin_unlock_irqrestore+0x35/0x50
[    1.481296] hardirqs last disabled at (132): [<ffffffffaf79345b>]
_raw_spin_lock_irqsave+0x5b/0x60
[    1.481296] softirqs last  enabled at (54): [<ffffffffae69201c>]
rcu_tasks_kthread+0x16c/0x250
[    1.481296] softirqs last disabled at (50): [<ffffffffae69201c>]
rcu_tasks_kthread+0x16c/0x250
[    1.481296] ---[ end trace 5a00c61d8412a9ac ]---

Links:
----
- https://qa-reports.linaro.org/lkft/linux-stable-rc-linux-5.15.y/build/v5.15.133-184-g6f28ecf24aef/testrun/20260259/suite/log-parser-boot/test/check-kernel-exception/log
- https://qa-reports.linaro.org/lkft/linux-stable-rc-linux-5.15.y/build/v5.15.133-184-g6f28ecf24aef/testrun/20260259/suite/log-parser-boot/tests/
Build: https://storage.tuxsuite.com/public/linaro/lkft/builds/2WJFhcfqqG69pqj6LWuI14kVoP5/

steps to reproduce:
--------
- https://storage.tuxsuite.com/public/linaro/lkft/builds/2WJFhcfqqG69pqj6LWuI14kVoP5/tuxmake_reproducer.sh

## Build
* kernel: 5.15.134-rc1
* git: https://gitlab.com/Linaro/lkft/mirrors/stable/linux-stable-rc
* git branch: linux-5.15.y
* git commit: 6f28ecf24aef2896f4071dc6268d3fb5f8259c77
* git describe: v5.15.133-184-g6f28ecf24aef
* test details:
https://qa-reports.linaro.org/lkft/linux-stable-rc-linux-5.15.y/build/v5.15.133-184-g6f28ecf24aef

## Test Regressions (compared to v5.15.133)
* x86, log-parser-boot
- check-kernel-exception
- check-kernel-warning

* x86, log-parser-test
- check-kernel-exception
- check-kernel-warning

## Metric Regressions (compared to v5.15.133)

## Test Fixes (compared to v5.15.133)

## Metric Fixes (compared to v5.15.133)

## Test result summary
total: 90392, pass: 71514, fail: 2557, skip: 16224, xfail: 97

## Build Summary
* arc: 4 total, 4 passed, 0 failed
* arm: 114 total, 114 passed, 0 failed
* arm64: 42 total, 42 passed, 0 failed
* i386: 32 total, 31 passed, 1 failed
* mips: 27 total, 26 passed, 1 failed
* parisc: 4 total, 4 passed, 0 failed
* powerpc: 26 total, 25 passed, 1 failed
* riscv: 11 total, 11 passed, 0 failed
* s390: 12 total, 11 passed, 1 failed
* sh: 13 total, 11 passed, 2 failed
* sparc: 8 total, 8 passed, 0 failed
* x86_64: 38 total, 38 passed, 0 failed

## Test suites summary
* boot
* kselftest-android
* kselftest-arm64
* kselftest-breakpoints
* kselftest-capabilities
* kselftest-cgroup
* kselftest-clone3
* kselftest-core
* kselftest-cpu-hotplug
* kselftest-cpufreq
* kselftest-drivers-dma-buf
* kselftest-efivarfs
* kselftest-exec
* kselftest-filesystems
* kselftest-filesystems-binderfs
* kselftest-filesystems-epoll
* kselftest-firmware
* kselftest-fpu
* kselftest-ftrace
* kselftest-futex
* kselftest-gpio
* kselftest-intel_pstate
* kselftest-ipc
* kselftest-ir
* kselftest-kcmp
* kselftest-kexec
* kselftest-kvm
* kselftest-lib
* kselftest-membarrier
* kselftest-memfd
* kselftest-memory-hotplug
* kselftest-mincore
* kselftest-mount
* kselftest-mqueue
* kselftest-net
* kselftest-net-forwarding
* kselftest-net-mptcp
* kselftest-netfilter
* kselftest-nsfs
* kselftest-openat2
* kselftest-pid_namespace
* kselftest-pidfd
* kselftest-proc
* kselftest-pstore
* kselftest-ptrace
* kselftest-rseq
* kselftest-rtc
* kselftest-seccomp
* kselftest-sigaltstack
* kselftest-size
* kselftest-splice
* kselftest-static_keys
* kselftest-sync
* kselftest-sysctl
* kselftest-tc-testing
* kselftest-timens
* kselftest-tmpfs
* kselftest-tpm2
* kselftest-user
* kselftest-user_events
* kselftest-vDSO
* kselftest-vm
* kselftest-watchdog
* kselftest-x86
* kselftest-zram
* kunit
* kvm-unit-tests
* libgpiod
* log-parser-boot
* log-parser-test
* ltp-cap_bounds
* ltp-commands
* ltp-containers
* ltp-controllers
* ltp-cpuhotplug
* ltp-crypto
* ltp-cve
* ltp-dio
* ltp-fcntl-locktests
* ltp-filecaps
* ltp-fs
* ltp-fs_bind
* ltp-fs_perms_simple
* ltp-fsx
* ltp-hugetlb
* ltp-io
* ltp-ipc
* ltp-math
* ltp-mm
* ltp-nptl
* ltp-pty
* ltp-sched
* ltp-securebits
* ltp-smoke
* ltp-syscalls
* ltp-tracing
* network-basic-tests
* perf
* rcutorture
* v4l2-compliance

--
Linaro LKFT
https://lkft.linaro.org

#195 lore raw
Quoted 88 lines · Paul E. McKenney
Quoted 78 lines · Liam R. Howlett
Quoted 27 lines · Naresh Kamboju
Quoted 10 lines · Greg Kroah-Hartman

This is the start of the stable review cycle for the 5.15.134 release. There are 183 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 Fri, 06 Oct 2023 17:51:12 +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.134-rc1.gz

or in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-5.15.y
and the diffstat can be found below.

thanks,

greg k-h

Results from Linaro’s test farm.
Regressions on x86.

Following kernel warning noticed on x86 while booting stable-rc 5.15.134-rc1 with selftest merge config built kernel.

Quoted 7 lines

Anyone noticed this kernel warning ?

This is always reproducible while booting x86 with a given config.

From that config:

#
# RCU Subsystem
#
CONFIG_TREE_RCU=y
# CONFIG_RCU_EXPERT is not set
CONFIG_SRCU=y
CONFIG_TREE_SRCU=y
CONFIG_TASKS_RCU_GENERIC=y
CONFIG_TASKS_RUDE_RCU=y
CONFIG_TASKS_TRACE_RCU=y
CONFIG_RCU_STALL_COMMON=y
CONFIG_RCU_NEED_SEGCBLIST=y

# end of RCU Subsystem    

#
# RCU Debugging
#
CONFIG_PROVE_RCU=y
# CONFIG_RCU_SCALE_TEST is not set
# CONFIG_RCU_TORTURE_TEST is not set
# CONFIG_RCU_REF_SCALE_TEST is not set
CONFIG_RCU_CPU_STALL_TIMEOUT=21
CONFIG_RCU_TRACE=y
# CONFIG_RCU_EQS_DEBUG is not set

# end of RCU Debugging
Quoted 15 lines

x86 boot log:
-----

[    0.000000] Linux version 5.15.134-rc1 (tuxmake@tuxmake)
(x86_64-linux-gnu-gcc (Debian 12.2.0-14) 12.2.0, GNU ld (GNU Binutils
for Debian) 2.40) #1 SMP @1696443178
...
[    1.480701] ------------[ cut here ]------------
[    1.481296] WARNING: CPU: 0 PID: 13 at kernel/rcu/tasks.h:958
trc_inspect_reader+0x80/0xb0
[    1.481296] Modules linked in:
[    1.481296] CPU: 0 PID: 13 Comm: rcu_tasks_trace Not tainted 5.15.134-rc1 #1
[    1.481296] Hardware name: Supermicro SYS-5019S-ML/X11SSH-F, BIOS
2.5 11/26/2020
[    1.481296] RIP: 0010:trc_inspect_reader+0x80/0xb0
Quoted 8 lines

This function has changed a lot, including the dropping of this WARN_ON_ONCE(). The warning was replaced in 897ba84dc5aa ("rcu-tasks:
Handle idle tasks for recently offlined CPUs") with something that looks equivalent so I'm not sure why it would not trigger in newer revisions.

Obviously the behaviour I changed was the test for the task being idle. I am not sure how best to short-circuit that test from happening during boot as I am not familiar with the RCU code.

Quoted 5 lines

The usual test for RCU's notion of early boot being completed is (rcu_scheduler_active != RCU_SCHEDULER_INIT).

Except that "ofl" should always be false that early in boot, at least in mainline.

Is this still true in the final version of the patch where we set the boot task as !idle until just before the early boot is finished? I wouldn't think of this as 'early in boot' anymore as much as the entire kernel setup. Maybe we need to shorten the time we stay in !idle mode for earlier kernels?

How frequent is this function called? We could check something for early boot... or track down where the cpu is put online and restore idle before that happens?

Quoted 6 lines
Quoted 4 lines

It's also worth noting that the bug this fixes wasn't exposed until the maple tree (added in v6.1) was used for the IRQ descriptors (added in v6.5).

Lots of latent bugs, to be sure, even with rcutorture. :-/

The Right Thing is to fix the bug all the way back to the introduction, but what fallout makes the backport less desirable than living with the unexposed bug?

Thanks,
Liam

maintainer
#196 lore raw
Quoted 92 lines · Liam R. Howlett
Quoted 91 lines · Paul E. McKenney
Quoted 78 lines · Liam R. Howlett
Quoted 27 lines · Naresh Kamboju
Quoted 10 lines · Greg Kroah-Hartman

This is the start of the stable review cycle for the 5.15.134 release. There are 183 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 Fri, 06 Oct 2023 17:51:12 +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.134-rc1.gz

or in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-5.15.y
and the diffstat can be found below.

thanks,

greg k-h

Results from Linaro’s test farm.
Regressions on x86.

Following kernel warning noticed on x86 while booting stable-rc 5.15.134-rc1 with selftest merge config built kernel.

Quoted 7 lines

Anyone noticed this kernel warning ?

This is always reproducible while booting x86 with a given config.

From that config:

#
# RCU Subsystem
#
CONFIG_TREE_RCU=y
# CONFIG_RCU_EXPERT is not set
CONFIG_SRCU=y
CONFIG_TREE_SRCU=y
CONFIG_TASKS_RCU_GENERIC=y
CONFIG_TASKS_RUDE_RCU=y
CONFIG_TASKS_TRACE_RCU=y
CONFIG_RCU_STALL_COMMON=y
CONFIG_RCU_NEED_SEGCBLIST=y

# end of RCU Subsystem    

#
# RCU Debugging
#
CONFIG_PROVE_RCU=y
# CONFIG_RCU_SCALE_TEST is not set
# CONFIG_RCU_TORTURE_TEST is not set
# CONFIG_RCU_REF_SCALE_TEST is not set
CONFIG_RCU_CPU_STALL_TIMEOUT=21
CONFIG_RCU_TRACE=y
# CONFIG_RCU_EQS_DEBUG is not set

# end of RCU Debugging
Quoted 15 lines

x86 boot log:
-----

[    0.000000] Linux version 5.15.134-rc1 (tuxmake@tuxmake)
(x86_64-linux-gnu-gcc (Debian 12.2.0-14) 12.2.0, GNU ld (GNU Binutils
for Debian) 2.40) #1 SMP @1696443178
...
[    1.480701] ------------[ cut here ]------------
[    1.481296] WARNING: CPU: 0 PID: 13 at kernel/rcu/tasks.h:958
trc_inspect_reader+0x80/0xb0
[    1.481296] Modules linked in:
[    1.481296] CPU: 0 PID: 13 Comm: rcu_tasks_trace Not tainted 5.15.134-rc1 #1
[    1.481296] Hardware name: Supermicro SYS-5019S-ML/X11SSH-F, BIOS
2.5 11/26/2020
[    1.481296] RIP: 0010:trc_inspect_reader+0x80/0xb0
Quoted 8 lines

This function has changed a lot, including the dropping of this WARN_ON_ONCE(). The warning was replaced in 897ba84dc5aa ("rcu-tasks:
Handle idle tasks for recently offlined CPUs") with something that looks equivalent so I'm not sure why it would not trigger in newer revisions.

Obviously the behaviour I changed was the test for the task being idle. I am not sure how best to short-circuit that test from happening during boot as I am not familiar with the RCU code.

The usual test for RCU's notion of early boot being completed is (rcu_scheduler_active != RCU_SCHEDULER_INIT).

Quoted 8 lines
Quoted 2 lines

Except that "ofl" should always be false that early in boot, at least in mainline.

Is this still true in the final version of the patch where we set the boot task as !idle until just before the early boot is finished? I wouldn't think of this as 'early in boot' anymore as much as the entire kernel setup. Maybe we need to shorten the time we stay in !idle mode for earlier kernels?

In mainline, the ofl variable is defined as cpu_is_offline(cpu), and during boot, the boot CPU is guaranteed to be online. (As opposed to the boot CPU's idle-task state.)

Quoted 3 lines

How frequent is this function called? We could check something for early boot... or track down where the cpu is put online and restore idle before that happens?

Once per RCU Tasks Trace grace period per reader seen to be blocking that grace period. Its performance is as issue, but not to anywhere near the same extent as (say) rcu_read_lock_trace().

Quoted 9 lines
Quoted 5 lines
Quoted 3 lines

It's also worth noting that the bug this fixes wasn't exposed until the maple tree (added in v6.1) was used for the IRQ descriptors (added in v6.5).

Lots of latent bugs, to be sure, even with rcutorture. :-/

The Right Thing is to fix the bug all the way back to the introduction, but what fallout makes the backport less desirable than living with the unexposed bug?

You are quite right that it is possible for the risk of a backport to exceed the risk of the original bug.

I defer to Joel (CCed) on how best to resolve this in -stable.

Thanx, Paul

#197 lore raw
Quoted 121 lines · Paul E. McKenney
Quoted 92 lines · Liam R. Howlett
Quoted 91 lines · Paul E. McKenney
Quoted 78 lines · Liam R. Howlett
Quoted 27 lines · Naresh Kamboju
Quoted 10 lines · Greg Kroah-Hartman

This is the start of the stable review cycle for the 5.15.134 release. There are 183 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 Fri, 06 Oct 2023 17:51:12 +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.134-rc1.gz

or in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-5.15.y
and the diffstat can be found below.

thanks,

greg k-h

Results from Linaro’s test farm.
Regressions on x86.

Following kernel warning noticed on x86 while booting stable-rc 5.15.134-rc1 with selftest merge config built kernel.

Quoted 7 lines

Anyone noticed this kernel warning ?

This is always reproducible while booting x86 with a given config.

From that config:

#
# RCU Subsystem
#
CONFIG_TREE_RCU=y
# CONFIG_RCU_EXPERT is not set
CONFIG_SRCU=y
CONFIG_TREE_SRCU=y
CONFIG_TASKS_RCU_GENERIC=y
CONFIG_TASKS_RUDE_RCU=y
CONFIG_TASKS_TRACE_RCU=y
CONFIG_RCU_STALL_COMMON=y
CONFIG_RCU_NEED_SEGCBLIST=y

# end of RCU Subsystem

#
# RCU Debugging
#
CONFIG_PROVE_RCU=y
# CONFIG_RCU_SCALE_TEST is not set
# CONFIG_RCU_TORTURE_TEST is not set
# CONFIG_RCU_REF_SCALE_TEST is not set
CONFIG_RCU_CPU_STALL_TIMEOUT=21
CONFIG_RCU_TRACE=y
# CONFIG_RCU_EQS_DEBUG is not set

# end of RCU Debugging
Quoted 15 lines

x86 boot log:
-----

[    0.000000] Linux version 5.15.134-rc1 (tuxmake@tuxmake)
(x86_64-linux-gnu-gcc (Debian 12.2.0-14) 12.2.0, GNU ld (GNU Binutils
for Debian) 2.40) #1 SMP @1696443178
...
[    1.480701] ------------[ cut here ]------------
[    1.481296] WARNING: CPU: 0 PID: 13 at kernel/rcu/tasks.h:958
trc_inspect_reader+0x80/0xb0
[    1.481296] Modules linked in:
[    1.481296] CPU: 0 PID: 13 Comm: rcu_tasks_trace Not tainted 5.15.134-rc1 #1
[    1.481296] Hardware name: Supermicro SYS-5019S-ML/X11SSH-F, BIOS
2.5 11/26/2020
[    1.481296] RIP: 0010:trc_inspect_reader+0x80/0xb0
Quoted 8 lines

This function has changed a lot, including the dropping of this WARN_ON_ONCE(). The warning was replaced in 897ba84dc5aa ("rcu-tasks:
Handle idle tasks for recently offlined CPUs") with something that looks equivalent so I'm not sure why it would not trigger in newer revisions.

Obviously the behaviour I changed was the test for the task being idle. I am not sure how best to short-circuit that test from happening during boot as I am not familiar with the RCU code.

The usual test for RCU's notion of early boot being completed is (rcu_scheduler_active != RCU_SCHEDULER_INIT).

Quoted 8 lines
Quoted 2 lines

Except that "ofl" should always be false that early in boot, at least in mainline.

Is this still true in the final version of the patch where we set the boot task as !idle until just before the early boot is finished? I wouldn't think of this as 'early in boot' anymore as much as the entire kernel setup. Maybe we need to shorten the time we stay in !idle mode for earlier kernels?

In mainline, the ofl variable is defined as cpu_is_offline(cpu), and during boot, the boot CPU is guaranteed to be online. (As opposed to the boot CPU's idle-task state.)

Quoted 3 lines

How frequent is this function called? We could check something for early boot... or track down where the cpu is put online and restore idle before that happens?

Once per RCU Tasks Trace grace period per reader seen to be blocking that grace period. Its performance is as issue, but not to anywhere near the same extent as (say) rcu_read_lock_trace().

Quoted 6 lines
Quoted 5 lines
Quoted 3 lines

It's also worth noting that the bug this fixes wasn't exposed until the maple tree (added in v6.1) was used for the IRQ descriptors (added in v6.5).

Lots of latent bugs, to be sure, even with rcutorture. :-/

Quoted 8 lines
Quoted 3 lines

The Right Thing is to fix the bug all the way back to the introduction, but what fallout makes the backport less desirable than living with the unexposed bug?

You are quite right that it is possible for the risk of a backport to exceed the risk of the original bug.

I defer to Joel (CCed) on how best to resolve this in -stable.

Maybe I am missing something but this issue should also be happening in mainline right?

Even though mainline has 897ba84dc5aa ("rcu-tasks: Handle idle tasks for recently offlined CPUs") , the warning should still be happening due to Liam's "kernel/sched: Modify initial boot task idle setup" because the warning is just rearranged a bit but essentially the same.

IMHO, the right thing to do then is to drop Liam's patch from 5.15 and fix it in mainline (using the ideas described in this thread), then backport both that new fix and Liam's patch to 5.15.

Or is there a reason this warning does not show up on the mainline?

My impression is that dropping Liam's patch for the stable release and revisiting it later is a better approach since tiny RCU is used way less in the wild than tree/tasks RCU. Thoughts?

thanks,

- Joel

maintainer
#198 lore raw
Quoted 143 lines · Joel Fernandes
Quoted 121 lines · Paul E. McKenney
Quoted 92 lines · Liam R. Howlett
Quoted 91 lines · Paul E. McKenney
Quoted 78 lines · Liam R. Howlett
Quoted 27 lines · Naresh Kamboju
Quoted 10 lines · Greg Kroah-Hartman

This is the start of the stable review cycle for the 5.15.134 release. There are 183 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 Fri, 06 Oct 2023 17:51:12 +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.134-rc1.gz

or in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-5.15.y
and the diffstat can be found below.

thanks,

greg k-h

Results from Linaro’s test farm.
Regressions on x86.

Following kernel warning noticed on x86 while booting stable-rc 5.15.134-rc1 with selftest merge config built kernel.

Quoted 7 lines

Anyone noticed this kernel warning ?

This is always reproducible while booting x86 with a given config.

From that config:

#
# RCU Subsystem
#
CONFIG_TREE_RCU=y
# CONFIG_RCU_EXPERT is not set
CONFIG_SRCU=y
CONFIG_TREE_SRCU=y
CONFIG_TASKS_RCU_GENERIC=y
CONFIG_TASKS_RUDE_RCU=y
CONFIG_TASKS_TRACE_RCU=y
CONFIG_RCU_STALL_COMMON=y
CONFIG_RCU_NEED_SEGCBLIST=y

# end of RCU Subsystem

#
# RCU Debugging
#
CONFIG_PROVE_RCU=y
# CONFIG_RCU_SCALE_TEST is not set
# CONFIG_RCU_TORTURE_TEST is not set
# CONFIG_RCU_REF_SCALE_TEST is not set
CONFIG_RCU_CPU_STALL_TIMEOUT=21
CONFIG_RCU_TRACE=y
# CONFIG_RCU_EQS_DEBUG is not set

# end of RCU Debugging
Quoted 15 lines

x86 boot log:
-----

[    0.000000] Linux version 5.15.134-rc1 (tuxmake@tuxmake)
(x86_64-linux-gnu-gcc (Debian 12.2.0-14) 12.2.0, GNU ld (GNU Binutils
for Debian) 2.40) #1 SMP @1696443178
...
[    1.480701] ------------[ cut here ]------------
[    1.481296] WARNING: CPU: 0 PID: 13 at kernel/rcu/tasks.h:958
trc_inspect_reader+0x80/0xb0
[    1.481296] Modules linked in:
[    1.481296] CPU: 0 PID: 13 Comm: rcu_tasks_trace Not tainted 5.15.134-rc1 #1
[    1.481296] Hardware name: Supermicro SYS-5019S-ML/X11SSH-F, BIOS
2.5 11/26/2020
[    1.481296] RIP: 0010:trc_inspect_reader+0x80/0xb0
Quoted 8 lines

This function has changed a lot, including the dropping of this WARN_ON_ONCE(). The warning was replaced in 897ba84dc5aa ("rcu-tasks:
Handle idle tasks for recently offlined CPUs") with something that looks equivalent so I'm not sure why it would not trigger in newer revisions.

Obviously the behaviour I changed was the test for the task being idle. I am not sure how best to short-circuit that test from happening during boot as I am not familiar with the RCU code.

The usual test for RCU's notion of early boot being completed is (rcu_scheduler_active != RCU_SCHEDULER_INIT).

Quoted 8 lines
Quoted 2 lines

Except that "ofl" should always be false that early in boot, at least in mainline.

Is this still true in the final version of the patch where we set the boot task as !idle until just before the early boot is finished? I wouldn't think of this as 'early in boot' anymore as much as the entire kernel setup. Maybe we need to shorten the time we stay in !idle mode for earlier kernels?

In mainline, the ofl variable is defined as cpu_is_offline(cpu), and during boot, the boot CPU is guaranteed to be online. (As opposed to the boot CPU's idle-task state.)

Quoted 3 lines

How frequent is this function called? We could check something for early boot... or track down where the cpu is put online and restore idle before that happens?

Once per RCU Tasks Trace grace period per reader seen to be blocking that grace period. Its performance is as issue, but not to anywhere near the same extent as (say) rcu_read_lock_trace().

Quoted 6 lines
Quoted 5 lines
Quoted 3 lines

It's also worth noting that the bug this fixes wasn't exposed until the maple tree (added in v6.1) was used for the IRQ descriptors (added in v6.5).

Lots of latent bugs, to be sure, even with rcutorture. :-/

Quoted 8 lines
Quoted 3 lines

The Right Thing is to fix the bug all the way back to the introduction, but what fallout makes the backport less desirable than living with the unexposed bug?

You are quite right that it is possible for the risk of a backport to exceed the risk of the original bug.

I defer to Joel (CCed) on how best to resolve this in -stable.

Maybe I am missing something but this issue should also be happening in mainline right?

Even though mainline has 897ba84dc5aa ("rcu-tasks: Handle idle tasks for recently offlined CPUs") , the warning should still be happening due to Liam's "kernel/sched: Modify initial boot task idle setup" because the warning is just rearranged a bit but essentially the same.

IMHO, the right thing to do then is to drop Liam's patch from 5.15 and fix it in mainline (using the ideas described in this thread), then backport both that new fix and Liam's patch to 5.15.

Quoted 5 lines

Or is there a reason this warning does not show up on the mainline?

My impression is that dropping Liam's patch for the stable release and revisiting it later is a better approach since tiny RCU is used way less in the wild than tree/tasks RCU. Thoughts?

I think that this one is strange enough that we need to write down the situation in detail, make sure we have all the corner cases covered in both mainline and -stable, and decide what to do from there.

Yes, I know, this email thread contains much of this information, but a little organizing of it would be good.

Would you like to put that together, or should I? If me, I will get a draft out by the end of this coming Tuesday, Pacific Time.

Thanx, Paul

maintainer
#199 lore raw
Quoted 140 lines · Paul E. McKenney
Quoted 139 lines · Joel Fernandes
Quoted 121 lines · Paul E. McKenney
Quoted 92 lines · Liam R. Howlett
Quoted 91 lines · Paul E. McKenney
Quoted 78 lines · Liam R. Howlett
Quoted 27 lines · Naresh Kamboju
Quoted 10 lines · Greg Kroah-Hartman

This is the start of the stable review cycle for the 5.15.134 release. There are 183 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 Fri, 06 Oct 2023 17:51:12 +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.134-rc1.gz

or in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-5.15.y
and the diffstat can be found below.

thanks,

greg k-h

Results from Linaro’s test farm.
Regressions on x86.

Following kernel warning noticed on x86 while booting stable-rc 5.15.134-rc1 with selftest merge config built kernel.

Quoted 7 lines

Anyone noticed this kernel warning ?

This is always reproducible while booting x86 with a given config.

From that config:

#
# RCU Subsystem
#
CONFIG_TREE_RCU=y
# CONFIG_RCU_EXPERT is not set
CONFIG_SRCU=y
CONFIG_TREE_SRCU=y
CONFIG_TASKS_RCU_GENERIC=y
CONFIG_TASKS_RUDE_RCU=y
CONFIG_TASKS_TRACE_RCU=y
CONFIG_RCU_STALL_COMMON=y
CONFIG_RCU_NEED_SEGCBLIST=y

# end of RCU Subsystem

#
# RCU Debugging
#
CONFIG_PROVE_RCU=y
# CONFIG_RCU_SCALE_TEST is not set
# CONFIG_RCU_TORTURE_TEST is not set
# CONFIG_RCU_REF_SCALE_TEST is not set
CONFIG_RCU_CPU_STALL_TIMEOUT=21
CONFIG_RCU_TRACE=y
# CONFIG_RCU_EQS_DEBUG is not set

# end of RCU Debugging
Quoted 15 lines

x86 boot log:
-----

[    0.000000] Linux version 5.15.134-rc1 (tuxmake@tuxmake)
(x86_64-linux-gnu-gcc (Debian 12.2.0-14) 12.2.0, GNU ld (GNU Binutils
for Debian) 2.40) #1 SMP @1696443178
...
[    1.480701] ------------[ cut here ]------------
[    1.481296] WARNING: CPU: 0 PID: 13 at kernel/rcu/tasks.h:958
trc_inspect_reader+0x80/0xb0
[    1.481296] Modules linked in:
[    1.481296] CPU: 0 PID: 13 Comm: rcu_tasks_trace Not tainted 5.15.134-rc1 #1
[    1.481296] Hardware name: Supermicro SYS-5019S-ML/X11SSH-F, BIOS
2.5 11/26/2020
[    1.481296] RIP: 0010:trc_inspect_reader+0x80/0xb0
Quoted 8 lines

This function has changed a lot, including the dropping of this WARN_ON_ONCE(). The warning was replaced in 897ba84dc5aa ("rcu-tasks:
Handle idle tasks for recently offlined CPUs") with something that looks equivalent so I'm not sure why it would not trigger in newer revisions.

Obviously the behaviour I changed was the test for the task being idle. I am not sure how best to short-circuit that test from happening during boot as I am not familiar with the RCU code.

The usual test for RCU's notion of early boot being completed is (rcu_scheduler_active != RCU_SCHEDULER_INIT).

Quoted 8 lines
Quoted 2 lines

Except that "ofl" should always be false that early in boot, at least in mainline.

Is this still true in the final version of the patch where we set the boot task as !idle until just before the early boot is finished? I wouldn't think of this as 'early in boot' anymore as much as the entire kernel setup. Maybe we need to shorten the time we stay in !idle mode for earlier kernels?

In mainline, the ofl variable is defined as cpu_is_offline(cpu), and during boot, the boot CPU is guaranteed to be online. (As opposed to the boot CPU's idle-task state.)

Quoted 3 lines

How frequent is this function called? We could check something for early boot... or track down where the cpu is put online and restore idle before that happens?

Once per RCU Tasks Trace grace period per reader seen to be blocking that grace period. Its performance is as issue, but not to anywhere near the same extent as (say) rcu_read_lock_trace().

Quoted 6 lines
Quoted 5 lines
Quoted 3 lines

It's also worth noting that the bug this fixes wasn't exposed until the maple tree (added in v6.1) was used for the IRQ descriptors (added in v6.5).

Lots of latent bugs, to be sure, even with rcutorture. :-/

Quoted 8 lines
Quoted 3 lines

The Right Thing is to fix the bug all the way back to the introduction, but what fallout makes the backport less desirable than living with the unexposed bug?

You are quite right that it is possible for the risk of a backport to exceed the risk of the original bug.

I defer to Joel (CCed) on how best to resolve this in -stable.

Maybe I am missing something but this issue should also be happening in mainline right?

Even though mainline has 897ba84dc5aa ("rcu-tasks: Handle idle tasks for recently offlined CPUs") , the warning should still be happening due to Liam's "kernel/sched: Modify initial boot task idle setup" because the warning is just rearranged a bit but essentially the same.

Quoted 5 lines
Quoted 5 lines

IMHO, the right thing to do then is to drop Liam's patch from 5.15 and fix it in mainline (using the ideas described in this thread), then backport both that new fix and Liam's patch to 5.15.

Or is there a reason this warning does not show up on the mainline?

There is not a whole lot of commonality between the v5.15.134 version of RCU Tasks Trace and that of mainline. In theory, in mainline, CPU hotplug is supposed to be disabled across all calls to trc_inspect_reader(), which means that there would not be any CPU coming or going.

But there could potentially be some time between when a CPU was marked as online and its idle task was marked PF_IDLE. And in fact x86 start_secondary() invokes set_cpu_online() before it calls cpu_startup_entry(), and it is the latter than sets PF_IDLE.

The same is true of alpha, arc, arm, arm64, csky, ia64, loongarch, mips, openrisc, parisc, powerpc, riscv, s390, sh, sparc32, sparc64, x86 xen, and xtensa, which is everybody.

One reason why my testing did not reproduce this is because I was running against v6.6-rc1, and cff9b2332ab7 ("kernel/sched: Modify initial boot task idle setup") went into v6.6-rc3. An initial run merging in current mainline also failed to reproduce this, but I am running overnight. If that doesn't reproduce, I will try inserting delays between the set_cpu_online() and the cpu_startup_entry().

If this problem is real, fixes include:

o Revert Liam's patch and make Tiny RCU's call_rcu() deal with
the problem. This is overhead and non-tinyness, but to Joel's point, it might be best.

o Go back to something more like Liam's original patch, which
cleared PF_IDLE only for the boot CPU.

o Set PF_IDLE before calling set_cpu_online(). This would work,
but it would also be rather ugly, reaching into each and every architecture.

o Move the call to set_cpu_online() into cpu_startup_entry().
This would require some serious inspection to prove that it is safe, assuming that it is in fact safe.

o Drop the WARN_ON_ONCE() from trc_inspect_reader(). Not all
that excited by losing this diagnostic, but then again it has been awhile since it has caught anything.

o Make the WARN_ON_ONCE() condition in trc_inspect_reader() instead
to a "return false" to retry later. Ditto, also not liking the possibility of indefinite deferral with no warning.

There are likely other approaches.

Quoted 8 lines
Quoted 3 lines

My impression is that dropping Liam's patch for the stable release and revisiting it later is a better approach since tiny RCU is used way less in the wild than tree/tasks RCU. Thoughts?

I think that this one is strange enough that we need to write down the situation in detail, make sure we have all the corner cases covered in both mainline and -stable, and decide what to do from there.

Quoted 5 lines

Yes, I know, this email thread contains much of this information, but a little organizing of it would be good.

Would you like to put that together, or should I? If me, I will get a draft out by the end of this coming Tuesday, Pacific Time.

And I guess that this is that draft.

It is quite possible that Tasks RCU also has issues with momentary online non-idleness of non-boot-CPU idle tasks, but checking that is a task for another time.

Thanx, Paul

#200 lore raw

On Tue, Oct 10, 2023 at 06:34:35PM -0700, Paul E. McKenney wrote:
[...]

Quoted 43 lines
Quoted 23 lines
Quoted 23 lines
Quoted 6 lines
Quoted 6 lines
Quoted 5 lines
Quoted 3 lines

It's also worth noting that the bug this fixes wasn't exposed until the maple tree (added in v6.1) was used for the IRQ descriptors (added in v6.5).

Lots of latent bugs, to be sure, even with rcutorture. :-/

Quoted 8 lines
Quoted 3 lines

The Right Thing is to fix the bug all the way back to the introduction, but what fallout makes the backport less desirable than living with the unexposed bug?

You are quite right that it is possible for the risk of a backport to exceed the risk of the original bug.

I defer to Joel (CCed) on how best to resolve this in -stable.

Maybe I am missing something but this issue should also be happening in mainline right?

Even though mainline has 897ba84dc5aa ("rcu-tasks: Handle idle tasks for recently offlined CPUs") , the warning should still be happening due to Liam's "kernel/sched: Modify initial boot task idle setup" because the warning is just rearranged a bit but essentially the same.

Quoted 5 lines
Quoted 5 lines

IMHO, the right thing to do then is to drop Liam's patch from 5.15 and fix it in mainline (using the ideas described in this thread), then backport both that new fix and Liam's patch to 5.15.

Or is there a reason this warning does not show up on the mainline?

There is not a whole lot of commonality between the v5.15.134 version of RCU Tasks Trace and that of mainline. In theory, in mainline, CPU hotplug is supposed to be disabled across all calls to trc_inspect_reader(), which means that there would not be any CPU coming or going.

But there could potentially be some time between when a CPU was marked as online and its idle task was marked PF_IDLE. And in fact x86 start_secondary() invokes set_cpu_online() before it calls cpu_startup_entry(), and it is the latter than sets PF_IDLE.

The same is true of alpha, arc, arm, arm64, csky, ia64, loongarch, mips, openrisc, parisc, powerpc, riscv, s390, sh, sparc32, sparc64, x86 xen, and xtensa, which is everybody.

Quoted 6 lines

One reason why my testing did not reproduce this is because I was running against v6.6-rc1, and cff9b2332ab7 ("kernel/sched: Modify initial boot task idle setup") went into v6.6-rc3. An initial run merging in current mainline also failed to reproduce this, but I am running overnight. If that doesn't reproduce, I will try inserting delays between the set_cpu_online() and the cpu_startup_entry().

I thought the warning happens before set_cpu_online() is even called, because under such situation, ofl == true and the task is not set to PF_IDLE yet:

                  WARN_ON_ONCE(ofl && task_curr(t) && !is_idle_task(t));
Quoted 17 lines

If this problem is real, fixes include:

o Revert Liam's patch and make Tiny RCU's call_rcu() deal with
the problem. This is overhead and non-tinyness, but to Joel's point, it might be best.

o Go back to something more like Liam's original patch, which
cleared PF_IDLE only for the boot CPU.

o Set PF_IDLE before calling set_cpu_online(). This would work,
but it would also be rather ugly, reaching into each and every architecture.

o Move the call to set_cpu_online() into cpu_startup_entry().
This would require some serious inspection to prove that it is safe, assuming that it is in fact safe.

Quoted 7 lines

o Drop the WARN_ON_ONCE() from trc_inspect_reader(). Not all
that excited by losing this diagnostic, but then again it has been awhile since it has caught anything.

o Make the WARN_ON_ONCE() condition in trc_inspect_reader() instead
to a "return false" to retry later. Ditto, also not liking the possibility of indefinite deferral with no warning.

Just for completeness,

o Since it just a warning, checking for task_struct::pid == 0 instead of is_idle_task()?
Though PF_IDLE is also set in play_idle_precise().

o Change warning to:

                  WARN_ON_ONCE(ofl && task_curr(t) && (!is_idle_task(t) && t->pid != 0));

thanks,

- Joel

maintainer
#201 lore raw
Quoted 52 lines · Joel Fernandes

On Tue, Oct 10, 2023 at 06:34:35PM -0700, Paul E. McKenney wrote:
[...]

Quoted 43 lines
Quoted 23 lines
Quoted 23 lines
Quoted 6 lines
Quoted 6 lines
Quoted 5 lines
Quoted 3 lines

It's also worth noting that the bug this fixes wasn't exposed until the maple tree (added in v6.1) was used for the IRQ descriptors (added in v6.5).

Lots of latent bugs, to be sure, even with rcutorture. :-/

Quoted 8 lines
Quoted 3 lines

The Right Thing is to fix the bug all the way back to the introduction, but what fallout makes the backport less desirable than living with the unexposed bug?

You are quite right that it is possible for the risk of a backport to exceed the risk of the original bug.

I defer to Joel (CCed) on how best to resolve this in -stable.

Maybe I am missing something but this issue should also be happening in mainline right?

Even though mainline has 897ba84dc5aa ("rcu-tasks: Handle idle tasks for recently offlined CPUs") , the warning should still be happening due to Liam's "kernel/sched: Modify initial boot task idle setup" because the warning is just rearranged a bit but essentially the same.

Quoted 5 lines
Quoted 5 lines

IMHO, the right thing to do then is to drop Liam's patch from 5.15 and fix it in mainline (using the ideas described in this thread), then backport both that new fix and Liam's patch to 5.15.

Or is there a reason this warning does not show up on the mainline?

There is not a whole lot of commonality between the v5.15.134 version of RCU Tasks Trace and that of mainline. In theory, in mainline, CPU hotplug is supposed to be disabled across all calls to trc_inspect_reader(), which means that there would not be any CPU coming or going.

But there could potentially be some time between when a CPU was marked as online and its idle task was marked PF_IDLE. And in fact x86 start_secondary() invokes set_cpu_online() before it calls cpu_startup_entry(), and it is the latter than sets PF_IDLE.

The same is true of alpha, arc, arm, arm64, csky, ia64, loongarch, mips, openrisc, parisc, powerpc, riscv, s390, sh, sparc32, sparc64, x86 xen, and xtensa, which is everybody.

Quoted 6 lines

One reason why my testing did not reproduce this is because I was running against v6.6-rc1, and cff9b2332ab7 ("kernel/sched: Modify initial boot task idle setup") went into v6.6-rc3. An initial run merging in current mainline also failed to reproduce this, but I am running overnight. If that doesn't reproduce, I will try inserting delays between the set_cpu_online() and the cpu_startup_entry().

Quoted 4 lines

I thought the warning happens before set_cpu_online() is even called, because under such situation, ofl == true and the task is not set to PF_IDLE yet:

                  WARN_ON_ONCE(ofl && task_curr(t) && !is_idle_task(t));

That case is supposed to be excluded by the cpus_read_lock() calls. Yes, key phrase "supposed to be". ;-)

Quoted 25 lines
Quoted 17 lines

If this problem is real, fixes include:

o Revert Liam's patch and make Tiny RCU's call_rcu() deal with
the problem. This is overhead and non-tinyness, but to Joel's point, it might be best.

o Go back to something more like Liam's original patch, which
cleared PF_IDLE only for the boot CPU.

o Set PF_IDLE before calling set_cpu_online(). This would work,
but it would also be rather ugly, reaching into each and every architecture.

o Move the call to set_cpu_online() into cpu_startup_entry().
This would require some serious inspection to prove that it is safe, assuming that it is in fact safe.

Quoted 7 lines

o Drop the WARN_ON_ONCE() from trc_inspect_reader(). Not all
that excited by losing this diagnostic, but then again it has been awhile since it has caught anything.

o Make the WARN_ON_ONCE() condition in trc_inspect_reader() instead
to a "return false" to retry later. Ditto, also not liking the possibility of indefinite deferral with no warning.

Quoted 7 lines

Just for completeness,

o Since it just a warning, checking for task_struct::pid == 0 instead of is_idle_task()?
Though PF_IDLE is also set in play_idle_precise().

o Change warning to:

                  WARN_ON_ONCE(ofl && task_curr(t) && (!is_idle_task(t) && t->pid != 0));

This change does look promising, thank you!

Thanx, Paul

#202 lore raw
In reply to Paul E. McKenney
Quoted 5 lines · Paul E. McKenney

If this problem is real, fixes include:

o Revert Liam's patch and make Tiny RCU's call_rcu() deal with
the problem. This is overhead and non-tinyness, but to Joel's point, it might be best.

But what is calling call_rcu() or start_poll_synchronize_rcu() so early that the CPU is not even online? (that's before boot_cpu_init() !)

Deferring PF_IDLE setting might pave the way for more issues like this one, present or future. Though is_idle_task() returning true when the task is not in the idle loop but is playing the init/0 role is debatable.

An alternative for tiny RCU is to force waking up ksoftirqd when call_rcu() is in the idle task. Since rcu_qs() during the context switch raises a softirq anyway. It's more overhead for start_poll_synchronize_rcu() though but do we expect much RCU polling in idle?

include/linux/interrupt.h +1 -0
index a92bce40b04b..6ab15233e2be 100644
@@ -604,6 +604,7 @@ extern void __raise_softirq_irqoff(unsigned int nr);
 
 extern void raise_softirq_irqoff(unsigned int nr);
 extern void raise_softirq(unsigned int nr);
+extern void raise_ksoftirqd_irqsoff(unsigned int nr);
 
 DECLARE_PER_CPU(struct task_struct *, ksoftirqd);
 
kernel/rcu/tiny.c +6 -3
index 42f7589e51e0..872dab8b8b53 100644
@@ -189,12 +189,12 @@ void call_rcu(struct rcu_head *head, rcu_callback_t func)
 	local_irq_save(flags);
 	*rcu_ctrlblk.curtail = head;
 	rcu_ctrlblk.curtail = &head->next;
-	local_irq_restore(flags);
 
 	if (unlikely(is_idle_task(current))) {
 		/* force scheduling for rcu_qs() */
-		resched_cpu(0);
+		raise_ksoftirqd_irqsoff(RCU_SOFTIRQ);
 	}
+	local_irq_restore(flags);
 }
 EXPORT_SYMBOL_GPL(call_rcu);
 
@@ -225,10 +225,13 @@ EXPORT_SYMBOL_GPL(get_state_synchronize_rcu);
 unsigned long start_poll_synchronize_rcu(void)
 {
 	unsigned long gp_seq = get_state_synchronize_rcu();
+	unsigned long flags;
 
 	if (unlikely(is_idle_task(current))) {
+		local_irq_save(flags);
 		/* force scheduling for rcu_qs() */
-		resched_cpu(0);
+		raise_ksoftirqd_irqsoff(RCU_SOFTIRQ);
+		local_irq_restore(flags);
 	}
 	return gp_seq;
 }
kernel/softirq.c +8 -0
index 210cf5f8d92c..ef105cbdc705 100644
@@ -695,6 +695,14 @@ void __raise_softirq_irqoff(unsigned int nr)
 	or_softirq_pending(1UL << nr);
 }
 
+#ifdef CONFIG_RCU_TINY
+void raise_ksoftirqd(unsigned int nr)
+{
+	__raise_softirq_irqoff(nr);
+	wakeup_softirqd();
+}
+#endif
+
 void open_softirq(int nr, void (*action)(struct softirq_action *))
 {
 	softirq_vec[nr].action = action;
maintainer
#203 lore raw
Quoted 10 lines · Frederic Weisbecker
Quoted 5 lines · Paul E. McKenney

If this problem is real, fixes include:

o Revert Liam's patch and make Tiny RCU's call_rcu() deal with
the problem. This is overhead and non-tinyness, but to Joel's point, it might be best.

But what is calling call_rcu() or start_poll_synchronize_rcu() so early that the CPU is not even online? (that's before boot_cpu_init() !)

Quoted 8 lines

Deferring PF_IDLE setting might pave the way for more issues like this one, present or future. Though is_idle_task() returning true when the task is not in the idle loop but is playing the init/0 role is debatable.

An alternative for tiny RCU is to force waking up ksoftirqd when call_rcu() is in the idle task. Since rcu_qs() during the context switch raises a softirq anyway. It's more overhead for start_poll_synchronize_rcu() though but do we expect much RCU polling in idle?

Nice!!!

This does solve the original problem with little or no additional overhead (perhaps even with decreased overhead), and avoids the other RCU Tasks issues.

Thanx, Paul

Quoted 69 lines
include/linux/interrupt.h +1 -0
index a92bce40b04b..6ab15233e2be 100644
@@ -604,6 +604,7 @@ extern void __raise_softirq_irqoff(unsigned int nr);
 
 extern void raise_softirq_irqoff(unsigned int nr);
 extern void raise_softirq(unsigned int nr);
+extern void raise_ksoftirqd_irqsoff(unsigned int nr);
 
 DECLARE_PER_CPU(struct task_struct *, ksoftirqd);
 
kernel/rcu/tiny.c +6 -3
index 42f7589e51e0..872dab8b8b53 100644
@@ -189,12 +189,12 @@ void call_rcu(struct rcu_head *head, rcu_callback_t func)
 	local_irq_save(flags);
 	*rcu_ctrlblk.curtail = head;
 	rcu_ctrlblk.curtail = &head->next;
-	local_irq_restore(flags);
 
 	if (unlikely(is_idle_task(current))) {
 		/* force scheduling for rcu_qs() */
-		resched_cpu(0);
+		raise_ksoftirqd_irqsoff(RCU_SOFTIRQ);
 	}
+	local_irq_restore(flags);
 }
 EXPORT_SYMBOL_GPL(call_rcu);
 
@@ -225,10 +225,13 @@ EXPORT_SYMBOL_GPL(get_state_synchronize_rcu);
 unsigned long start_poll_synchronize_rcu(void)
 {
 	unsigned long gp_seq = get_state_synchronize_rcu();
+	unsigned long flags;
 
 	if (unlikely(is_idle_task(current))) {
+		local_irq_save(flags);
 		/* force scheduling for rcu_qs() */
-		resched_cpu(0);
+		raise_ksoftirqd_irqsoff(RCU_SOFTIRQ);
+		local_irq_restore(flags);
 	}
 	return gp_seq;
 }
kernel/softirq.c +8 -0
index 210cf5f8d92c..ef105cbdc705 100644
@@ -695,6 +695,14 @@ void __raise_softirq_irqoff(unsigned int nr)
 	or_softirq_pending(1UL << nr);
 }
 
+#ifdef CONFIG_RCU_TINY
+void raise_ksoftirqd(unsigned int nr)
+{
+	__raise_softirq_irqoff(nr);
+	wakeup_softirqd();
+}
+#endif
+
 void open_softirq(int nr, void (*action)(struct softirq_action *))
 {
 	softirq_vec[nr].action = action;
#204 lore raw
In reply to Paul E. McKenney

On Sun, Oct 8, 2023 at 9:20 PM Paul E. McKenney <[email protected]> wrote:
[...]

Quoted 45 lines
Quoted 35 lines
Quoted 14 lines
Quoted 3 lines

How frequent is this function called? We could check something for early boot... or track down where the cpu is put online and restore idle before that happens?

Once per RCU Tasks Trace grace period per reader seen to be blocking that grace period. Its performance is as issue, but not to anywhere near the same extent as (say) rcu_read_lock_trace().

Quoted 6 lines
Quoted 5 lines
Quoted 3 lines

It's also worth noting that the bug this fixes wasn't exposed until the maple tree (added in v6.1) was used for the IRQ descriptors (added in v6.5).

Lots of latent bugs, to be sure, even with rcutorture. :-/

Quoted 8 lines
Quoted 3 lines

The Right Thing is to fix the bug all the way back to the introduction, but what fallout makes the backport less desirable than living with the unexposed bug?

You are quite right that it is possible for the risk of a backport to exceed the risk of the original bug.

I defer to Joel (CCed) on how best to resolve this in -stable.

Maybe I am missing something but this issue should also be happening in mainline right?

Even though mainline has 897ba84dc5aa ("rcu-tasks: Handle idle tasks for recently offlined CPUs") , the warning should still be happening due to Liam's "kernel/sched: Modify initial boot task idle setup" because the warning is just rearranged a bit but essentially the same.

IMHO, the right thing to do then is to drop Liam's patch from 5.15 and fix it in mainline (using the ideas described in this thread), then backport both that new fix and Liam's patch to 5.15.

Quoted 5 lines

Or is there a reason this warning does not show up on the mainline?

My impression is that dropping Liam's patch for the stable release and revisiting it later is a better approach since tiny RCU is used way less in the wild than tree/tasks RCU. Thoughts?

I think that this one is strange enough that we need to write down the situation in detail, make sure we have all the corner cases covered in both mainline and -stable, and decide what to do from there.

Quoted 5 lines

Yes, I know, this email thread contains much of this information, but a little organizing of it would be good.

Would you like to put that together, or should I? If me, I will get a draft out by the end of this coming Tuesday, Pacific Time.

I apologize, I haven't been able to do any real work as I was OOO for the most part due to dental issues. I am about 25% back now. I will review your other email writeup and thanks for putting it together!

- Joel

maintainer
#205 lore raw
Quoted 50 lines · Joel Fernandes

On Sun, Oct 8, 2023 at 9:20 PM Paul E. McKenney <[email protected]> wrote:
[...]

Quoted 48 lines
Quoted 35 lines
Quoted 14 lines
Quoted 3 lines

How frequent is this function called? We could check something for early boot... or track down where the cpu is put online and restore idle before that happens?

Once per RCU Tasks Trace grace period per reader seen to be blocking that grace period. Its performance is as issue, but not to anywhere near the same extent as (say) rcu_read_lock_trace().

Quoted 6 lines
Quoted 5 lines
Quoted 3 lines

It's also worth noting that the bug this fixes wasn't exposed until the maple tree (added in v6.1) was used for the IRQ descriptors (added in v6.5).

Lots of latent bugs, to be sure, even with rcutorture. :-/

Quoted 8 lines
Quoted 3 lines

The Right Thing is to fix the bug all the way back to the introduction, but what fallout makes the backport less desirable than living with the unexposed bug?

You are quite right that it is possible for the risk of a backport to exceed the risk of the original bug.

I defer to Joel (CCed) on how best to resolve this in -stable.

Maybe I am missing something but this issue should also be happening in mainline right?

Even though mainline has 897ba84dc5aa ("rcu-tasks: Handle idle tasks for recently offlined CPUs") , the warning should still be happening due to Liam's "kernel/sched: Modify initial boot task idle setup" because the warning is just rearranged a bit but essentially the same.

IMHO, the right thing to do then is to drop Liam's patch from 5.15 and fix it in mainline (using the ideas described in this thread), then backport both that new fix and Liam's patch to 5.15.

Quoted 5 lines

Or is there a reason this warning does not show up on the mainline?

My impression is that dropping Liam's patch for the stable release and revisiting it later is a better approach since tiny RCU is used way less in the wild than tree/tasks RCU. Thoughts?

I think that this one is strange enough that we need to write down the situation in detail, make sure we have all the corner cases covered in both mainline and -stable, and decide what to do from there.

Yes, I know, this email thread contains much of this information, but a little organizing of it would be good.

Quoted 6 lines
Quoted 2 lines

Would you like to put that together, or should I? If me, I will get a draft out by the end of this coming Tuesday, Pacific Time.

I apologize, I haven't been able to do any real work as I was OOO for the most part due to dental issues. I am about 25% back now. I will review your other email writeup and thanks for putting it together!

No need to apologize! If anything, it is I who should apologize for not digging deeply into this to begin with. As always, there were distraction. ;-)

Thanx, Paul

#206 lore raw
In reply to Greg Kroah-Hartman
Quoted 8 lines · Greg Kroah-Hartman

This is the start of the stable review cycle for the 5.15.134 release. There are 183 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 Fri, 06 Oct 2023 17:51:12 +0000. Anything received after that time might be too late.

Build results:

	total: 160 pass: 158 fail: 2
Failed builds:
	i386:tools/perf
	x86_64:tools/perf
Qemu test results:
	total: 509 pass: 509 fail: 0

Guenter

Tested-by on the v1 series
#207 lore raw
In reply to Greg Kroah-Hartman
Quoted 9 lines · Greg Kroah-Hartman

This is the start of the stable review cycle for the 5.15.134 release. There are 183 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 Fri, 06 Oct 2023 17:51:12 +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.134-rc1.gz

or in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-5.15.y
and the diffstat can be found below.

thanks,

greg k-h

Built and booted successfully on RISC-V RV64 (HiFive Unmatched).

maintainer Tested-by on the v1 series
#208 lore raw
In reply to Greg Kroah-Hartman
Quoted 9 lines · Greg Kroah-Hartman

This is the start of the stable review cycle for the 5.15.134 release. There are 183 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 Fri, 06 Oct 2023 17:51:12 +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.134-rc1.gz

or in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-5.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
    26 boots:	26 pass, 0 fail
    94 tests:	94 pass, 0 fail

Linux version: 5.15.134-rc1-g6f28ecf24aef
Boards tested: tegra124-jetson-tk1, tegra186-p2771-0000,

                tegra194-p2972-0000, tegra194-p3509-0000+p3668-0000,
                tegra20-ventana, tegra210-p2371-2180,
                tegra210-p3450-0000, tegra30-cardhu-a04

Jon

#209 lore raw
In reply to Greg Kroah-Hartman

Hello Greg,

Quoted 14 lines · Greg Kroah-Hartman

This is the start of the stable review cycle for the 5.15.134 release. There are 183 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 Fri, 06 Oct 2023 17:51:12 +0000. Anything received after that time might be too late.

The whole patch series can be found in one patch at:

        https://www.kernel.org/pub/linux/kernel/v5.x/stable-review/patch-5.15.134-rc1.gz

or in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-5.15.y
and the diffstat can be found below.

[...]

Quoted 3 lines

Liam R. Howlett <[email protected]>
kernel/sched: Modify initial boot task idle setup

Let us drop this patch because it caused new tasks-RCU warnings (both normal and rude tasks RCU) in my stable test rig. We are discussing the "right fix" and at that time a backport can be done.

Hope Liam is also Ok with that. I am happy to do that future backport if needed.

Thanks,

- Joel

Quoted 838 lines

Heiner Kallweit <[email protected]>
i2c: i801: unregister tco_pdev in i801_probe() error path

Niklas Cassel <[email protected]>
ata: libata-scsi: ignore reserved bits for REPORT SUPPORTED OPERATION CODES

Kailang Yang <[email protected]>
ALSA: hda: Disable power save for solving pop issue on Lenovo ThinkCentre M70q

Pablo Neira Ayuso <[email protected]>
netfilter: nf_tables: disallow rule removal from chain binding

Pan Bian <[email protected]>
nilfs2: fix potential use after free in nilfs_gccache_submit_read_data()

Andy Shevchenko <[email protected]>
serial: 8250_port: Check IRQ data before use

Daniel Starke <[email protected]>
Revert "tty: n_gsm: fix UAF in gsm_cleanup_mux"

Ricky WU <[email protected]>
misc: rtsx: Fix some platforms can not boot and move the l1ss judgment to probe

Pu Wen <[email protected]>
x86/srso: Add SRSO mitigation for Hygon processors

Nicolin Chen <[email protected]>
iommu/arm-smmu-v3: Fix soft lockup triggered by arm_smmu_mm_invalidate_range

Vishal Goel <[email protected]>
Smack:- Use overlay inode label in smack_inode_copy_up()

Roberto Sassu <[email protected]>
smack: Retrieve transmuting information in smack_inode_getsecurity()

Roberto Sassu <[email protected]>
smack: Record transmuting in smk_transmuted

Irvin Cote <[email protected]>
nvme-pci: always return an ERR_PTR from nvme_pci_alloc_dev

Gleb Chesnokov <[email protected]>
scsi: qla2xxx: Fix NULL pointer dereference in target mode

Ian Rogers <[email protected]>
perf metric: Return early if no CPU PMU table exists

Andrii Staikov <[email protected]>

    i40e: fix potential NULL pointer dereferencing of pf->vf i40e_sync_vsi_filters()

Mika Westerberg <[email protected]>
watchdog: iTCO_wdt: Set NO_REBOOT if the watchdog is not already running

Mika Westerberg <[email protected]>
watchdog: iTCO_wdt: No need to stop the timer in probe

Pratyush Yadav <[email protected]>
nvme-pci: do not set the NUMA node of device if it has none

Christoph Hellwig <[email protected]>
nvme-pci: factor out a nvme_pci_alloc_dev helper

Christoph Hellwig <[email protected]>
nvme-pci: factor the iod mempool creation into a helper

Chengming Zhou <[email protected]>
cgroup: Fix suspicious rcu_dereference_check() usage warning

Chengming Zhou <[email protected]>
sched/cpuacct: Optimize away RCU read lock

Arnaldo Carvalho de Melo <[email protected]>
perf build: Define YYNOMEM as YYNOABORT for bison < 3.81

Thomas Zimmermann <[email protected]>
fbdev/sh7760fb: Depend on FB=y

Johnathan Mantey <[email protected]>
ncsi: Propagate carrier gain/loss events to the NCSI controller

Benjamin Gray <[email protected]>
powerpc/watchpoints: Annotate atomic context in more places

Benjamin Gray <[email protected]>
powerpc/watchpoint: Disable pagefaults when getting user instruction

Benjamin Gray <[email protected]>
powerpc/watchpoints: Disable preemption in thread_change_pc()

Hans Verkuil <[email protected]>
media: vb2: frame_vector.c: replace WARN_ONCE with a comment

Chancel Liu <[email protected]>
ASoC: imx-rpmsg: Set ignore_pmdown_time for dai_link

Stanislav Fomichev <[email protected]>
bpf: Clarify error expectations from bpf_clone_redirect

Shengjiu Wang <[email protected]>
ASoC: fsl: imx-pcm-rpmsg: Add SNDRV_PCM_INFO_BATCH flag

Valentin Caron <[email protected]>
spi: stm32: add a delay before SPI disable

Han Xu <[email protected]>
spi: nxp-fspi: reset the FLSHxCR1 registers

Niklas Cassel <[email protected]>
ata: libata-eh: do not clear ATA_PFLAG_EH_PENDING in ata_eh_reset()

Steve French <[email protected]>
smb3: correct places where ENOTSUPP is used instead of preferred EOPNOTSUPP

Michal Grzedzicki <[email protected]>

    scsi: pm80xx: Avoid leaking tags when processing OPC_INB_SET_CONTROLLER_CONFIG command

Michal Grzedzicki <[email protected]>

    scsi: pm80xx: Use phy-specific SAS address when sending PHY_START command

David Francis <[email protected]>
drm/amdgpu: Handle null atom context in VBIOS info ioctl

Swapnil Patel <[email protected]>
drm/amd/display: Don't check registers, if using AUX BL control

David Thompson <[email protected]>
platform/mellanox: mlxbf-bootctl: add NET dependency into Kconfig

Steven Rostedt (Google) <[email protected]>
ring-buffer: Do not attempt to read past "commit"

Ricardo B. Marliere <[email protected]>
selftests: fix dependency checker script

Filipe Manana <[email protected]>
btrfs: improve error message after failure to add delayed dir index item

Zheng Yejian <[email protected]>
ring-buffer: Avoid softlockup in ring_buffer_resize()

Zheng Yejian <[email protected]>
selftests/ftrace: Correctly enable event in instance-event.tc

Kiwoong Kim <[email protected]>
scsi: ufs: core: Move __ufshcd_send_uic_cmd() outside host_lock

Javed Hasan <[email protected]>
scsi: qedf: Add synchronization between I/O completions and abort

Helge Deller <[email protected]>
parisc: irq: Make irq_stack_union static to avoid sparse warning

Helge Deller <[email protected]>
parisc: drivers: Fix sparse warning

Helge Deller <[email protected]>
parisc: iosapic.c: Fix sparse warnings

Helge Deller <[email protected]>
parisc: sba: Fix compile warning wrt list of SBA devices

Tobias Schramm <[email protected]>
spi: sun6i: fix race between DMA RX transfer completion and RX FIFO drain

Tobias Schramm <[email protected]>
spi: sun6i: reduce DMA RX transfer width to single byte

Sergey Senozhatsky <[email protected]>
dma-debug: don't call __dma_entry_alloc_check_leak() under free_entries_lock

William A. Kennington III <[email protected]>
i2c: npcm7xx: Fix callback completion ordering

Wenhua Lin <[email protected]>
gpio: pmic-eic-sprd: Add can_sleep flag for PMIC EIC chip

Nathan Rossi <[email protected]>
soc: imx8m: Enable OCOTP clock for imx8mm before reading registers

Max Filippov <[email protected]>
xtensa: boot/lib: fix function prototypes

Randy Dunlap <[email protected]>
xtensa: boot: don't add include-dirs

Randy Dunlap <[email protected]>
xtensa: iss/network: make functions static

Max Filippov <[email protected]>
xtensa: add default definition for XCHAL_HAVE_DIV32

Christophe JAILLET <[email protected]>
firmware: imx-dsp: Fix an error handling path in imx_dsp_setup_channels()

Dan Carpenter <[email protected]>
power: supply: ucs1002: fix error code in ucs1002_get_property()

Tony Lindgren <[email protected]>
bus: ti-sysc: Fix SYSC_QUIRK_SWSUP_SIDLE_ACT handling for uart wake-up

Tony Lindgren <[email protected]>
ARM: dts: ti: omap: motorola-mapphone: Fix abe_clkctrl warning on boot

Tony Lindgren <[email protected]>
ARM: dts: ti: omap: Fix bandgap thermal cells addressing for omap3/4

Krzysztof Kozlowski <[email protected]>
ARM: dts: omap: correct indentation

Thomas Gleixner <[email protected]>
treewide: Replace GPLv2 boilerplate/reference with SPDX - gpl-2.0_56.RULE (part 1)

Timo Alho <[email protected]>
clk: tegra: fix error return case for recalc_rate

Adam Ford <[email protected]>
bus: ti-sysc: Fix missing AM35xx SoC matching

Julien Panis <[email protected]>
bus: ti-sysc: Use fsleep() instead of usleep_range() in sysc_reset()

Marek Vasut <[email protected]>
drm/bridge: ti-sn65dsi83: Do not generate HFP/HBP/HSA and EOT packet

Christoph Hellwig <[email protected]>
MIPS: Alchemy: only build mmc support helpers if au1xmmc is enabled

Qu Wenruo <[email protected]>
btrfs: reset destination buffer when read_extent_buffer() gets invalid range

Nilesh Javali <[email protected]>
scsi: qla2xxx: Use raw_smp_processor_id() instead of smp_processor_id()

Shreyas Deodhar <[email protected]>
scsi: qla2xxx: Select qpair depending on which CPU post_cmd() gets called

Werner Fischer <[email protected]>
ata: ahci: Add Elkhart Lake AHCI controller

Mario Limonciello <[email protected]>
ata: ahci: Rename board_ahci_mobile

Paul Menzel <[email protected]>
ata: ahci: Add support for AMD A85 FCH (Hudson D4)

Paul Menzel <[email protected]>
ata: libata: Rename link flag ATA_LFLAG_NO_DB_DELAY

Xiao Liang <[email protected]>
netfilter: nft_exthdr: Fix non-linear header modification

Florian Westphal <[email protected]>
netfilter: exthdr: add support for tcp option removal

Namhyung Kim <[email protected]>
perf build: Update build rule for generated files

Ian Rogers <[email protected]>
perf jevents: Switch build to use jevents.py

Werner Sembach <[email protected]>
Input: i8042 - add quirk for TUXEDO Gemini 17 Gen1/Clevo PD70PN

Huacai Chen <[email protected]>

    Input: i8042 - rename i8042-x86ia64io.h to i8042-acpipnpio.h

Darrick J. Wong <[email protected]>
xfs: fix xfs_inodegc_stop racing with mod_delayed_work

Darrick J. Wong <[email protected]>
xfs: disable reaping in fscounters scrub

Darrick J. Wong <[email protected]>
xfs: check that per-cpu inodegc workers actually run on that cpu

Darrick J. Wong <[email protected]>
xfs: explicitly specify cpu when forcing inodegc delayed work to run immediately

Dave Chinner <[email protected]>
xfs: introduce xfs_inodegc_push()

Dave Chinner <[email protected]>
xfs: bound maximum wait time for inodegc work

Liang He <[email protected]>
i2c: mux: gpio: Add missing fwnode_handle_put()

Andy Shevchenko <[email protected]>
i2c: mux: gpio: Replace custom acpi_get_local_address()

Xiaoke Wang <[email protected]>
i2c: mux: demux-pinctrl: check the return value of devm_kstrdup()

Christophe JAILLET <[email protected]>

    gpio: tb10x: Fix an error handling path in tb10x_gpio_probe()

Sasha Levin <[email protected]>
Fix up backport of 136191703038 ("interconnect: Teach lockdep about icc_bw_lock order")

Muhammad Husaini Zulkifli <[email protected]>
igc: Expose tx-usecs coalesce setting to user

Sebastian Andrzej Siewior <[email protected]>
bnxt_en: Flush XDP for bnxt_poll_nitroa0()'s NAPI

Sebastian Andrzej Siewior <[email protected]>
net: ena: Flush XDP packets on error.

Sebastian Andrzej Siewior <[email protected]>
locking/seqlock: Do the lockdep annotation before locking in do_write_seqcount_begin_nested()

Jozsef Kadlecsik <[email protected]>
netfilter: ipset: Fix race between IPSET_CMD_CREATE and IPSET_CMD_SWAP

Florian Westphal <[email protected]>
netfilter: nf_tables: disable toggling dormant table state more than once

Artem Chernyshev <[email protected]>
net: rds: Fix possible NULL-pointer dereference

Ziyang Xuan <[email protected]>
team: fix null-ptr-deref when team device type is changed

Eric Dumazet <[email protected]>
net: bridge: use DEV_STATS_INC()

Jie Wang <[email protected]>
net: hns3: add 5ms delay before clear firmware reset irq source

Jijie Shao <[email protected]>
net: hns3: fix fail to delete tc flower rules during reset issue

Jian Shen <[email protected]>
net: hns3: only enable unicast promisc when mac table full

Jie Wang <[email protected]>
net: hns3: fix GRE checksum offload issue

Josh Poimboeuf <[email protected]>
x86/srso: Fix SBPB enablement for spec_rstack_overflow=off

Josh Poimboeuf <[email protected]>
x86/srso: Fix srso_show_state() side effect

Stephen Boyd <[email protected]>
platform/x86: intel_scu_ipc: Fail IPC send if still busy

Stephen Boyd <[email protected]>
platform/x86: intel_scu_ipc: Don't override scu in intel_scu_ipc_dev_simple_command()

Stephen Boyd <[email protected]>
platform/x86: intel_scu_ipc: Check status upon timeout in ipc_wait_for_interrupt()

Stephen Boyd <[email protected]>
platform/x86: intel_scu_ipc: Check status after timeout in busy_loop()

Eric Dumazet <[email protected]>

    dccp: fix dccp_v4_err()/dccp_v6_err() again

Kajol Jain <[email protected]>
powerpc/perf/hv-24x7: Update domain value check

Kyle Zeng <[email protected]>
ipv4: fix null-deref in ipv4_link_failure

Vinicius Costa Gomes <[email protected]>
igc: Fix infinite initialization loop with early XDP redirect

David Christensen <[email protected]>
ionic: fix 16bit math issue when PAGE_SIZE >= 64KB

Ivan Vecera <[email protected]>
i40e: Fix VF VLAN offloading when port VLAN is configured

Mateusz Palczewski <[email protected]>
i40e: Add VF VLAN pruning

Radoslaw Tyl <[email protected]>
iavf: do not process adminq tasks when __IAVF_IN_REMOVE_TASK is set

Shengjiu Wang <[email protected]>
ASoC: imx-audmix: Fix return error with devm_clk_get()

Sasha Neftin <[email protected]>
net/core: Fix ETH_P_1588 flow dissector

Sabrina Dubroca <[email protected]>
selftests: tls: swap the TX and RX sockets in some tests

Toke Høiland-Jørgensen <[email protected]>
bpf: Avoid deadlock when using queue and stack maps from NMI

Pablo Neira Ayuso <[email protected]>
netfilter: nf_tables: disallow element removal on anonymous sets

Jerome Brunet <[email protected]>
ASoC: meson: spdifin: start hw on dai probe

Florian Westphal <[email protected]>
netfilter: nf_tables: fix memleak when more than 255 elements expired

Pablo Neira Ayuso <[email protected]>
netfilter: nft_set_hash: try later when GC hits EAGAIN on iteration

Pablo Neira Ayuso <[email protected]>
netfilter: nft_set_pipapo: stop GC iteration if GC transaction allocation fails

Pablo Neira Ayuso <[email protected]>
netfilter: nft_set_pipapo: call nft_trans_gc_queue_sync() in catchall GC

Pablo Neira Ayuso <[email protected]>
netfilter: nft_set_rbtree: use read spinlock to avoid datapath contention

Pablo Neira Ayuso <[email protected]>
netfilter: nft_set_rbtree: skip sync GC for new elements in this transaction

Florian Westphal <[email protected]>
netfilter: nf_tables: defer gc run if previous batch is still pending

Pablo Neira Ayuso <[email protected]>
netfilter: nf_tables: use correct lock to protect gc_list

Pablo Neira Ayuso <[email protected]>
netfilter: nf_tables: GC transaction race with abort path

Pablo Neira Ayuso <[email protected]>
netfilter: nf_tables: GC transaction race with netns dismantle

Pablo Neira Ayuso <[email protected]>
netfilter: nf_tables: fix GC transaction races with netns and netlink event exit path

Florian Westphal <[email protected]>
netfilter: nf_tables: don't fail inserts if duplicate has expired

Pablo Neira Ayuso <[email protected]>
netfilter: nf_tables: remove busy mark and gc batch API

Pablo Neira Ayuso <[email protected]>
netfilter: nft_set_hash: mark set element as dead when deleting from packet path

Pablo Neira Ayuso <[email protected]>
netfilter: nf_tables: adapt set backend to use GC transaction API

Pablo Neira Ayuso <[email protected]>
netfilter: nf_tables: GC transaction API to avoid race with control plane

Florian Westphal <[email protected]>
netfilter: nf_tables: don't skip expired elements during walk

Steven Rostedt (Google) <[email protected]>
tracing: Have event inject files inc the trace array ref count

Jan Kara <[email protected]>
ext4: do not let fstrim block system suspend

Jan Kara <[email protected]>
ext4: move setting of trimmed bit into ext4_try_to_trim_range()

Kemeng Shi <[email protected]>
ext4: replace the traditional ternary conditional operator with with max()/min()

Lukas Czerner <[email protected]>
ext4: change s_last_trim_minblks type to unsigned long

Lukas Bulwahn <[email protected]>
ext4: scope ret locally in ext4_try_to_trim_range()

Szuying Chen <[email protected]>
ata: libahci: clear pending interrupt status

Hannes Reinecke <[email protected]>
ata: ahci: Drop pointless VPRINTK() calls and convert the remaining ones

Steven Rostedt (Google) <[email protected]>
tracing: Increase trace array ref count on enable and filter files

John Keeping <[email protected]>
tracing: Make trace_marker{,_raw} stream-like

Olga Kornievskaia <[email protected]>
NFSv4.1: fix pnfs MDS=DS session trunking

Olga Kornievskaia <[email protected]>
NFSv4.1: use EXCHGID4_FLAG_USE_PNFS_DS for DS server

Trond Myklebust <[email protected]>
SUNRPC: Mark the cred for revalidation if the server rejects it

Trond Myklebust <[email protected]>
NFS/pNFS: Report EINVAL errors from connect() to the server

Trond Myklebust <[email protected]>
NFS: More fixes for nfs_direct_write_reschedule_io()

Trond Myklebust <[email protected]>
NFS: Use the correct commit info in nfs_join_page_group()

-------------

Diffstat:

 Makefile                                           |   4 +-
 arch/arm/boot/dts/am33xx.dtsi                      |   5 +-
 arch/arm/boot/dts/am3517.dtsi                      |   5 +-
 arch/arm/boot/dts/am4372.dtsi                      |   5 +-
 arch/arm/boot/dts/artpec6-devboard.dts             |   9 +-
 arch/arm/boot/dts/dm814x.dtsi                      |   6 +-
 arch/arm/boot/dts/dm816x.dtsi                      |   6 +-
 arch/arm/boot/dts/dra62x.dtsi                      |   6 +-
 arch/arm/boot/dts/dra7-dspeve-thermal.dtsi         |   5 +-
 arch/arm/boot/dts/dra7-iva-thermal.dtsi            |   5 +-
 arch/arm/boot/dts/imx6q-gk802.dts                  |   9 +-
 arch/arm/boot/dts/motorola-mapphone-common.dtsi    |   4 +-
 arch/arm/boot/dts/omap-gpmc-smsc911x.dtsi          |   6 +-
 arch/arm/boot/dts/omap-gpmc-smsc9221.dtsi          |   6 +-
 arch/arm/boot/dts/omap2.dtsi                       |   5 +-
 arch/arm/boot/dts/omap2420.dtsi                    |   5 +-
 arch/arm/boot/dts/omap2430.dtsi                    |   5 +-
 arch/arm/boot/dts/omap3-cm-t3517.dts               |  12 +-
 arch/arm/boot/dts/omap3-cpu-thermal.dtsi           |   8 +-
 arch/arm/boot/dts/omap3-gta04.dtsi                 |   6 +-
 arch/arm/boot/dts/omap3-ldp.dts                    |   2 +-
 arch/arm/boot/dts/omap3-n900.dts                   |  38 +-
 arch/arm/boot/dts/omap3-zoom3.dts                  |  44 +--
 arch/arm/boot/dts/omap3.dtsi                       |   5 +-
 arch/arm/boot/dts/omap34xx.dtsi                    |   5 +-
 arch/arm/boot/dts/omap36xx.dtsi                    |   5 +-
 arch/arm/boot/dts/omap4-cpu-thermal.dtsi           |  34 +-
 arch/arm/boot/dts/omap443x.dtsi                    |   6 +-
 arch/arm/boot/dts/omap4460.dtsi                    |   6 +-
 arch/arm/boot/dts/omap5-cm-t54.dts                 |  56 +--
 arch/arm/boot/dts/omap5-core-thermal.dtsi          |   5 +-
 arch/arm/boot/dts/omap5-gpu-thermal.dtsi           |   5 +-
 arch/arm/boot/dts/orion5x-lacie-d2-network.dts     |   5 +-
 .../dts/orion5x-lacie-ethernet-disk-mini-v2.dts    |   9 +-
 .../boot/dts/orion5x-maxtor-shared-storage-2.dts   |   5 +-
 arch/arm/boot/dts/orion5x-mv88f5181.dtsi           |   9 +-
 arch/arm/boot/dts/orion5x-mv88f5182.dtsi           |   9 +-
 arch/arm/boot/dts/orion5x-netgear-wnr854t.dts      |   9 +-
 arch/arm/boot/dts/orion5x-rd88f5182-nas.dts        |   9 +-
 arch/arm/boot/dts/orion5x.dtsi                     |   9 +-
 arch/arm/include/asm/hardware/cache-aurora-l2.h    |   5 +-
 arch/arm/include/asm/hardware/cache-feroceon-l2.h  |   6 +-
 arch/arm/include/asm/hardware/cache-tauros2.h      |   5 +-
 arch/arm/mach-davinci/board-da830-evm.c            |   6 +-
 arch/arm/mach-davinci/board-da850-evm.c            |   6 +-
 arch/arm/mach-davinci/board-dm355-evm.c            |   6 +-
 arch/arm/mach-davinci/board-dm355-leopard.c        |   5 +-
 arch/arm/mach-davinci/board-dm644x-evm.c           |   6 +-
 arch/arm/mach-davinci/board-dm646x-evm.c           |   7 +-
 arch/arm/mach-davinci/board-mityomapl138.c         |   5 +-
 arch/arm/mach-davinci/board-neuros-osd2.c          |   5 +-
 arch/arm/mach-davinci/board-omapl138-hawk.c        |   5 +-
 arch/arm/mach-davinci/common.c                     |   6 +-
 arch/arm/mach-davinci/cpuidle.h                    |   5 +-
 arch/arm/mach-davinci/da830.c                      |   6 +-
 arch/arm/mach-davinci/da850.c                      |   6 +-
 arch/arm/mach-davinci/dm355.c                      |   6 +-
 arch/arm/mach-davinci/dm644x.c                     |   6 +-
 arch/arm/mach-davinci/dm646x.c                     |   6 +-
 arch/arm/mach-davinci/include/mach/common.h        |   6 +-
 arch/arm/mach-davinci/include/mach/cputype.h       |   6 +-
 arch/arm/mach-davinci/include/mach/da8xx.h         |   6 +-
 arch/arm/mach-davinci/include/mach/hardware.h      |   6 +-
 arch/arm/mach-davinci/include/mach/serial.h        |   6 +-
 arch/arm/mach-davinci/mux.c                        |   6 +-
 arch/arm/mach-davinci/mux.h                        |   6 +-
 arch/arm/mach-davinci/pm_domain.c                  |   5 +-
 arch/arm/mach-dove/bridge-regs.h                   |   9 +-
 arch/arm/mach-dove/cm-a510.c                       |   5 +-
 arch/arm/mach-dove/common.c                        |   5 +-
 arch/arm/mach-dove/common.h                        |   5 +-
 arch/arm/mach-dove/dove-db-setup.c                 |   5 +-
 arch/arm/mach-dove/dove.h                          |   9 +-
 arch/arm/mach-dove/irq.c                           |   5 +-
 arch/arm/mach-dove/irqs.h                          |   9 +-
 arch/arm/mach-dove/mpp.c                           |   5 +-
 arch/arm/mach-dove/pcie.c                          |   5 +-
 arch/arm/mach-dove/pm.h                            |   6 +-
 arch/arm/mach-lpc18xx/board-dt.c                   |   5 +-
 arch/arm/mach-lpc32xx/pm.c                         |   6 +-
 arch/arm/mach-lpc32xx/suspend.S                    |   6 +-
 arch/arm/mach-mv78xx0/bridge-regs.h                |   6 +-
 arch/arm/mach-mv78xx0/buffalo-wxl-setup.c          |   5 +-
 arch/arm/mach-mv78xx0/common.c                     |   5 +-
 arch/arm/mach-mv78xx0/common.h                     |   5 +-
 arch/arm/mach-mv78xx0/db78x00-bp-setup.c           |   5 +-
 arch/arm/mach-mv78xx0/irq.c                        |   5 +-
 arch/arm/mach-mv78xx0/irqs.h                       |   9 +-
 arch/arm/mach-mv78xx0/mpp.c                        |   5 +-
 arch/arm/mach-mv78xx0/mpp.h                        |   6 +-
 arch/arm/mach-mv78xx0/mv78xx0.h                    |   5 +-
 arch/arm/mach-mv78xx0/pcie.c                       |   5 +-
 arch/arm/mach-mv78xx0/rd78x00-masa-setup.c         |   5 +-
 arch/arm/mach-mvebu/armada-370-xp.h                |   5 +-
 arch/arm/mach-mvebu/board-v7.c                     |   5 +-
 arch/arm/mach-mvebu/coherency.c                    |   5 +-
 arch/arm/mach-mvebu/coherency.h                    |   6 +-
 arch/arm/mach-mvebu/coherency_ll.S                 |   5 +-
 arch/arm/mach-mvebu/common.h                       |   5 +-
 arch/arm/mach-mvebu/cpu-reset.c                    |   5 +-
 arch/arm/mach-mvebu/dove.c                         |   5 +-
 arch/arm/mach-mvebu/headsmp-a9.S                   |   5 +-
 arch/arm/mach-mvebu/headsmp.S                      |   5 +-
 arch/arm/mach-mvebu/kirkwood.c                     |   5 +-
 arch/arm/mach-mvebu/kirkwood.h                     |   5 +-
 arch/arm/mach-mvebu/mvebu-soc-id.c                 |   5 +-
 arch/arm/mach-mvebu/mvebu-soc-id.h                 |   5 +-
 arch/arm/mach-mvebu/platsmp-a9.c                   |   5 +-
 arch/arm/mach-mvebu/platsmp.c                      |   5 +-
 arch/arm/mach-mvebu/pm-board.c                     |   5 +-
 arch/arm/mach-mvebu/pm.c                           |   5 +-
 arch/arm/mach-mvebu/pmsu.c                         |   5 +-
 arch/arm/mach-mvebu/pmsu.h                         |   5 +-
 arch/arm/mach-mvebu/pmsu_ll.S                      |   5 +-
 arch/arm/mach-mvebu/system-controller.c            |   5 +-
 arch/arm/mach-omap1/include/mach/mtd-xip.h         |   6 +-
 arch/arm/mach-omap1/pm_bus.c                       |   6 +-
 arch/arm/mach-omap2/prcm43xx.h                     |   5 +-
 arch/arm/mach-omap2/vc.c                           |   6 +-
 arch/arm/mach-orion5x/board-d2net.c                |   5 +-
 arch/arm/mach-orion5x/board-dt.c                   |   5 +-
 arch/arm/mach-orion5x/board-rd88f5182.c            |   5 +-
 arch/arm/mach-orion5x/bridge-regs.h                |   9 +-
 arch/arm/mach-orion5x/common.c                     |   5 +-
 arch/arm/mach-orion5x/db88f5281-setup.c            |   5 +-
 arch/arm/mach-orion5x/irq.c                        |   5 +-
 arch/arm/mach-orion5x/irqs.h                       |   5 +-
 arch/arm/mach-orion5x/kurobox_pro-setup.c          |   5 +-
 arch/arm/mach-orion5x/ls_hgl-setup.c               |   5 +-
 arch/arm/mach-orion5x/mpp.c                        |   5 +-
 arch/arm/mach-orion5x/net2big-setup.c              |   6 +-
 arch/arm/mach-orion5x/orion5x.h                    |   5 +-
 arch/arm/mach-orion5x/pci.c                        |   5 +-
 arch/arm/mach-orion5x/rd88f5181l-fxo-setup.c       |   5 +-
 arch/arm/mach-orion5x/rd88f5181l-ge-setup.c        |   5 +-
 arch/arm/mach-orion5x/rd88f5182-setup.c            |   5 +-
 arch/arm/mach-orion5x/rd88f6183ap-ge-setup.c       |   5 +-
 arch/arm/mach-orion5x/ts78xx-setup.c               |   5 +-
 arch/arm/mach-orion5x/wnr854t-setup.c              |   9 +-
 arch/arm/mach-orion5x/wrt350n-v2-setup.c           |   9 +-
 arch/arm/mach-pxa/eseries.c                        |   7 +-
 arch/arm/mach-pxa/standby.S                        |   6 +-
 arch/arm/mach-spear/generic.h                      |   5 +-
 arch/arm/mach-spear/include/mach/misc_regs.h       |   5 +-
 arch/arm/mach-spear/include/mach/spear.h           |   5 +-
 arch/arm/mach-spear/pl080.c                        |   5 +-
 arch/arm/mach-spear/pl080.h                        |   5 +-
 arch/arm/mach-spear/restart.c                      |   5 +-
 arch/arm/mach-spear/spear1310.c                    |   5 +-
 arch/arm/mach-spear/spear1340.c                    |   5 +-
 arch/arm/mach-spear/spear13xx.c                    |   5 +-
 arch/arm/mach-spear/spear300.c                     |   5 +-
 arch/arm/mach-spear/spear310.c                     |   5 +-
 arch/arm/mach-spear/spear320.c                     |   5 +-
 arch/arm/mach-spear/spear3xx.c                     |   5 +-
 arch/arm/mach-spear/spear6xx.c                     |   5 +-
 arch/arm/mach-spear/time.c                         |   5 +-
 arch/arm/mm/cache-feroceon-l2.c                    |   5 +-
 arch/arm/mm/cache-tauros2.c                        |   5 +-
 arch/mips/alchemy/devboards/db1000.c               |   4 +
 arch/mips/alchemy/devboards/db1200.c               |   6 +
 arch/mips/alchemy/devboards/db1300.c               |   4 +
 arch/parisc/include/asm/ropes.h                    |   3 +
 arch/parisc/kernel/drivers.c                       |   2 +-
 arch/parisc/kernel/irq.c                           |   2 +-
 arch/powerpc/kernel/hw_breakpoint.c                |  16 +-
 arch/powerpc/kernel/hw_breakpoint_constraints.c    |   7 +-
 arch/powerpc/perf/hv-24x7.c                        |   2 +-
 arch/x86/kernel/cpu/bugs.c                         |   4 +-
 arch/x86/kernel/cpu/common.c                       |   2 +-
 arch/xtensa/boot/Makefile                          |   3 +-
 arch/xtensa/boot/lib/zmem.c                        |   5 +-
 arch/xtensa/include/asm/core.h                     |   4 +
 arch/xtensa/platforms/iss/network.c                |   4 +-
 drivers/ata/ahci.c                                 | 111 +++---
 drivers/ata/ahci_brcm.c                            |   2 +-
 drivers/ata/ahci_xgene.c                           |   4 -
 drivers/ata/libahci.c                              |  49 +--
 drivers/ata/libata-core.c                          |  47 ++-
 drivers/ata/libata-eh.c                            |  13 +-
 drivers/ata/libata-sata.c                          |   2 +-
 drivers/ata/libata-scsi.c                          |   2 +-
 drivers/ata/libata-transport.c                     |   9 +-
 drivers/ata/libata.h                               |   2 +
 drivers/bus/ti-sysc.c                              |  31 +-
 drivers/char/agp/parisc-agp.c                      |   2 -
 drivers/clk/tegra/clk-bpmp.c                       |   2 +-
 drivers/firmware/imx/imx-dsp.c                     |   1 +
 drivers/gpio/gpio-pmic-eic-sprd.c                  |   1 +
 drivers/gpio/gpio-tb10x.c                          |   6 +-
 drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c            |  17 +-
 .../amd/display/dc/dce110/dce110_hw_sequencer.c    |   4 +-
 drivers/gpu/drm/bridge/ti-sn65dsi83.c              |   4 +-
 drivers/gpu/drm/meson/meson_encoder_hdmi.c         |   2 +
 drivers/i2c/busses/i2c-i801.c                      |   1 +
 drivers/i2c/busses/i2c-npcm7xx.c                   |  17 +-
 drivers/i2c/muxes/i2c-demux-pinctrl.c              |   4 +
 drivers/i2c/muxes/i2c-mux-gpio.c                   |  47 +--
 .../serio/{i8042-x86ia64io.h => i8042-acpipnpio.h} |  13 +-
 drivers/input/serio/i8042.h                        |   2 +-
 drivers/interconnect/core.c                        |   1 +
 drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3-sva.c    |  27 +-
 drivers/media/common/videobuf2/frame_vector.c      |   6 +-
 drivers/misc/cardreader/rts5227.c                  |  55 +--
 drivers/misc/cardreader/rts5228.c                  |  57 +--
 drivers/misc/cardreader/rts5249.c                  |  56 +--
 drivers/misc/cardreader/rts5260.c                  |  43 +--
 drivers/misc/cardreader/rts5261.c                  |  52 +--
 drivers/misc/cardreader/rtsx_pcr.c                 |  51 ++-
 drivers/net/ethernet/amazon/ena/ena_netdev.c       |   3 +
 drivers/net/ethernet/broadcom/bnxt/bnxt.c          |   5 +
 drivers/net/ethernet/hisilicon/hns3/hns3_enet.c    |   9 +
 .../ethernet/hisilicon/hns3/hns3pf/hclge_main.c    |  13 +-
 drivers/net/ethernet/intel/i40e/i40e.h             |   1 +
 drivers/net/ethernet/intel/i40e/i40e_ethtool.c     |   9 +
 drivers/net/ethernet/intel/i40e/i40e_main.c        | 138 ++++++-
 drivers/net/ethernet/intel/i40e/i40e_virtchnl_pf.c |  16 +-
 drivers/net/ethernet/intel/iavf/iavf_main.c        |   3 +-
 drivers/net/ethernet/intel/igc/igc_ethtool.c       |  31 +-
 drivers/net/ethernet/intel/igc/igc_main.c          |   2 +-
 drivers/net/ethernet/pensando/ionic/ionic_dev.h    |   1 +
 drivers/net/ethernet/pensando/ionic/ionic_txrx.c   |  10 +-
 drivers/net/team/team.c                            |  10 +-
 drivers/net/thunderbolt.c                          |   3 +-
 drivers/nvme/host/pci.c                            | 121 ++++---
 drivers/parisc/iosapic.c                           |   4 +-
 drivers/parisc/iosapic_private.h                   |   4 +-
 drivers/platform/mellanox/Kconfig                  |   1 +
 drivers/platform/x86/intel_scu_ipc.c               |  66 ++--
 drivers/power/supply/ucs1002_power.c               |   3 +-
 drivers/scsi/pm8001/pm8001_hwi.c                   |   2 +-
 drivers/scsi/pm8001/pm80xx_hwi.c                   |   4 +-
 drivers/scsi/qedf/qedf_io.c                        |  10 +-
 drivers/scsi/qedf/qedf_main.c                      |   7 +-
 drivers/scsi/qla2xxx/qla_def.h                     |   3 +
 drivers/scsi/qla2xxx/qla_init.c                    |   5 +-
 drivers/scsi/qla2xxx/qla_inline.h                  |  58 +++
 drivers/scsi/qla2xxx/qla_isr.c                     |  12 +-
 drivers/scsi/qla2xxx/qla_nvme.c                    |   4 +
 drivers/scsi/qla2xxx/qla_os.c                      |   6 +
 drivers/scsi/qla2xxx/qla_target.c                  |   3 +-
 drivers/scsi/qla2xxx/tcm_qla2xxx.c                 |   4 +-
 drivers/scsi/ufs/ufshcd.c                          |   6 +-
 drivers/soc/imx/soc-imx8m.c                        |  10 +
 drivers/spi/spi-nxp-fspi.c                         |   7 +
 drivers/spi/spi-stm32.c                            |   8 +
 drivers/spi/spi-sun6i.c                            |  31 +-
 drivers/tty/n_gsm.c                                |   4 +-
 drivers/tty/serial/8250/8250_port.c                |   5 +-
 drivers/video/fbdev/Kconfig                        |   2 +-
 drivers/watchdog/iTCO_wdt.c                        |  26 +-
 fs/binfmt_elf_fdpic.c                              |   5 +-
 fs/btrfs/delayed-inode.c                           |   7 +-
 fs/btrfs/extent_io.c                               |   8 +-
 fs/btrfs/super.c                                   |   2 +-
 fs/cifs/inode.c                                    |   2 +-
 fs/cifs/smb2ops.c                                  |   6 +-
 fs/ext4/ext4.h                                     |   2 +-
 fs/ext4/mballoc.c                                  |  67 ++--
 fs/nfs/direct.c                                    |  25 +-
 fs/nfs/flexfilelayout/flexfilelayout.c             |   1 +
 fs/nfs/nfs4client.c                                |   9 +-
 fs/nfs/nfs4proc.c                                  |   4 +
 fs/nfs/write.c                                     |  23 +-
 fs/nilfs2/gcinode.c                                |   6 +-
 fs/proc/task_nommu.c                               |  27 +-
 fs/xfs/scrub/common.c                              |  25 --
 fs/xfs/scrub/common.h                              |   2 -
 fs/xfs/scrub/fscounters.c                          |  13 +-
 fs/xfs/scrub/scrub.c                               |   2 -
 fs/xfs/scrub/scrub.h                               |   1 -
 fs/xfs/xfs_icache.c                                |  92 +++--
 fs/xfs/xfs_icache.h                                |   1 +
 fs/xfs/xfs_mount.h                                 |   5 +-
 fs/xfs/xfs_qm_syscalls.c                           |   9 +-
 fs/xfs/xfs_super.c                                 |  12 +-
 fs/xfs/xfs_trace.h                                 |   1 +
 include/linux/btf_ids.h                            |   2 +-
 include/linux/cgroup.h                             |   3 +-
 include/linux/if_team.h                            |   2 +
 include/linux/libata.h                             |   4 +-
 include/linux/nfs_fs_sb.h                          |   1 +
 include/linux/nfs_page.h                           |   4 +-
 include/linux/seqlock.h                            |   2 +-
 include/net/netfilter/nf_tables.h                  | 127 +++----
 include/uapi/linux/bpf.h                           |   4 +-
 io_uring/io_uring.c                                |   2 +-
 kernel/bpf/queue_stack_maps.c                      |  21 +-
 kernel/dma/debug.c                                 |  20 +-
 kernel/sched/core.c                                |   2 +-
 kernel/sched/cpuacct.c                             |   4 +-
 kernel/sched/cpupri.c                              |   1 +
 kernel/sched/idle.c                                |   1 +
 kernel/trace/ring_buffer.c                         |  10 +
 kernel/trace/trace.c                               |  45 ++-
 kernel/trace/trace.h                               |   2 +
 kernel/trace/trace_events.c                        |   6 +-
 kernel/trace/trace_events_inject.c                 |   3 +-
 net/bridge/br_forward.c                            |   4 +-
 net/bridge/br_input.c                              |   4 +-
 net/core/flow_dissector.c                          |   2 +-
 net/dccp/ipv4.c                                    |   9 +-
 net/dccp/ipv6.c                                    |   9 +-
 net/ipv4/route.c                                   |   4 +-
 net/ncsi/ncsi-aen.c                                |   5 +
 net/netfilter/ipset/ip_set_core.c                  |  12 +-
 net/netfilter/nf_tables_api.c                      | 400 +++++++++++++++++----
 net/netfilter/nft_exthdr.c                         | 110 +++++-
 net/netfilter/nft_set_hash.c                       |  87 +++--
 net/netfilter/nft_set_pipapo.c                     |  71 ++--
 net/netfilter/nft_set_rbtree.c                     | 161 +++++----
 net/rds/rdma_transport.c                           |  12 +-
 net/sunrpc/clnt.c                                  |  15 +-
 security/smack/smack.h                             |   1 +
 security/smack/smack_lsm.c                         |  65 +++-
 sound/pci/hda/hda_intel.c                          |   1 +
 sound/soc/fsl/imx-audmix.c                         |   2 +-
 sound/soc/fsl/imx-pcm-rpmsg.c                      |   1 +
 sound/soc/fsl/imx-rpmsg.c                          |   8 +
 sound/soc/meson/axg-spdifin.c                      |  49 +--
 tools/build/Makefile.build                         |  10 +
 tools/include/linux/btf_ids.h                      |   2 +-
 tools/include/uapi/linux/bpf.h                     |   4 +-
 tools/perf/Makefile.config                         |  19 +
 tools/perf/Makefile.perf                           |   1 +
 tools/perf/pmu-events/Build                        |  19 +-
 tools/perf/pmu-events/empty-pmu-events.c           | 158 ++++++++
 tools/perf/util/Build                              |   6 +
 tools/perf/util/metricgroup.c                      |   3 +
 .../ftrace/test.d/instances/instance-event.tc      |   2 +-
 tools/testing/selftests/kselftest_deps.sh          |  77 +++-
 tools/testing/selftests/net/tls.c                  |   8 +-
 332 files changed, 2602 insertions(+), 1896 deletions(-)
author maintainer
#210 lore raw
Quoted 23 lines · Joel Fernandes

Hello Greg,

Quoted 14 lines · Greg Kroah-Hartman

This is the start of the stable review cycle for the 5.15.134 release. There are 183 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 Fri, 06 Oct 2023 17:51:12 +0000. Anything received after that time might be too late.

The whole patch series can be found in one patch at:

        https://www.kernel.org/pub/linux/kernel/v5.x/stable-review/patch-5.15.134-rc1.gz

or in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-5.15.y
and the diffstat can be found below.

[...]

Quoted 3 lines

Liam R. Howlett <[email protected]>
kernel/sched: Modify initial boot task idle setup

Quoted 5 lines

Let us drop this patch because it caused new tasks-RCU warnings (both normal and rude tasks RCU) in my stable test rig. We are discussing the "right fix" and at that time a backport can be done.

Hope Liam is also Ok with that. I am happy to do that future backport if needed.

This is already in a released kernel, a bunch of them:

	5.15.134 6.1.56 6.5.6 6.6-rc3

should it be reverted from all of the stable releases, or just for 5.15.y?

thanks,

greg k-h

#211 lore raw
Quoted 29 lines · Greg Kroah-Hartman
Quoted 27 lines · Joel Fernandes

Hello Greg,

Quoted 14 lines · Greg Kroah-Hartman

This is the start of the stable review cycle for the 5.15.134 release. There are 183 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 Fri, 06 Oct 2023 17:51:12 +0000. Anything received after that time might be too late.

The whole patch series can be found in one patch at:

        https://www.kernel.org/pub/linux/kernel/v5.x/stable-review/patch-5.15.134-rc1.gz

or in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-5.15.y
and the diffstat can be found below.

[...]

Quoted 3 lines

Liam R. Howlett <[email protected]>
kernel/sched: Modify initial boot task idle setup

Let us drop this patch because it caused new tasks-RCU warnings (both normal and rude tasks RCU) in my stable test rig. We are discussing the "right fix" and at that time a backport can be done.

Quoted 6 lines
Quoted 1 line

Hope Liam is also Ok with that. I am happy to do that future backport if needed.

This is already in a released kernel, a bunch of them:

        5.15.134 6.1.56 6.5.6 6.6-rc3

should it be reverted from all of the stable releases, or just for 5.15.y?

Just 5.15.y. The others don't have an issue with the patch per my tests.

Thanks,

- Joel

author maintainer
#212 lore raw
Quoted 31 lines · Joel Fernandes
Quoted 29 lines · Greg Kroah-Hartman
Quoted 27 lines · Joel Fernandes

Hello Greg,

Quoted 14 lines · Greg Kroah-Hartman

This is the start of the stable review cycle for the 5.15.134 release. There are 183 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 Fri, 06 Oct 2023 17:51:12 +0000. Anything received after that time might be too late.

The whole patch series can be found in one patch at:

        https://www.kernel.org/pub/linux/kernel/v5.x/stable-review/patch-5.15.134-rc1.gz

or in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-5.15.y
and the diffstat can be found below.

[...]

Quoted 3 lines

Liam R. Howlett <[email protected]>
kernel/sched: Modify initial boot task idle setup

Let us drop this patch because it caused new tasks-RCU warnings (both normal and rude tasks RCU) in my stable test rig. We are discussing the "right fix" and at that time a backport can be done.

Quoted 8 lines
Quoted 6 lines
Quoted 1 line

Hope Liam is also Ok with that. I am happy to do that future backport if needed.

This is already in a released kernel, a bunch of them:

        5.15.134 6.1.56 6.5.6 6.6-rc3

should it be reverted from all of the stable releases, or just for 5.15.y?

Just 5.15.y. The others don't have an issue with the patch per my tests.

Ok, now reverted, thanks.

greg k-h