5.15.134-rc1 review
Subsystems (6)
Greg Kroah-Hartman
maintainerPATCH 104/183 xtensa: iss/network: make functions static
In reply to Greg Kroah-Hartman5.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)
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
@@ -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
Greg Kroah-Hartman
maintainerPATCH 105/183 xtensa: boot: dont add include-dirs
In reply to Greg Kroah-Hartman5.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]
Message-Id: <[email protected]>
--- arch/xtensa/boot/Makefile | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-)
arch/xtensa/boot/Makefile +1 -2
@@ -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
Greg Kroah-Hartman
maintainerPATCH 106/183 xtensa: boot/lib: fix function prototypes
In reply to Greg Kroah-Hartman5.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)
--- arch/xtensa/boot/lib/zmem.c | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-)
arch/xtensa/boot/lib/zmem.c +3 -2
@@ -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
Greg Kroah-Hartman
maintainerPATCH 107/183 soc: imx8m: Enable OCOTP clock for imx8mm before reading registers
In reply to Greg Kroah-Hartman5.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.
--- drivers/soc/imx/soc-imx8m.c | 10 ++++++++++ 1 file changed, 10 insertions(+)
drivers/soc/imx/soc-imx8m.c +10 -0
@@ -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
Greg Kroah-Hartman
maintainerPATCH 108/183 gpio: pmic-eic-sprd: Add can_sleep flag for PMIC EIC chip
In reply to Greg Kroah-Hartman5.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.
--- drivers/gpio/gpio-pmic-eic-sprd.c | 1 + 1 file changed, 1 insertion(+)
drivers/gpio/gpio-pmic-eic-sprd.c +1 -0
@@ -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
Greg Kroah-Hartman
maintainerPATCH 109/183 i2c: npcm7xx: Fix callback completion ordering
In reply to Greg Kroah-Hartman5.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.
--- drivers/i2c/busses/i2c-npcm7xx.c | 17 +++++++---------- 1 file changed, 7 insertions(+), 10 deletions(-)
drivers/i2c/busses/i2c-npcm7xx.c +7 -10
@@ -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
Greg Kroah-Hartman
maintainerPATCH 110/183 dma-debug: dont call __dma_entry_alloc_check_leak() under free_entries_lock
In reply to Greg Kroah-Hartman5.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
@@ -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
Greg Kroah-Hartman
maintainerPATCH 111/183 spi: sun6i: reduce DMA RX transfer width to single byte
In reply to Greg Kroah-Hartman5.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
@@ -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
Greg Kroah-Hartman
maintainerPATCH 112/183 spi: sun6i: fix race between DMA RX transfer completion and RX FIFO drain
In reply to Greg Kroah-Hartman5.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
@@ -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
Greg Kroah-Hartman
maintainerPATCH 113/183 parisc: sba: Fix compile warning wrt list of SBA devices
In reply to Greg Kroah-Hartman5.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
@@ -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
@@ -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
Greg Kroah-Hartman
maintainerPATCH 114/183 parisc: iosapic.c: Fix sparse warnings
In reply to Greg Kroah-Hartman5.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
@@ -202,9 +202,9 @@ static inline void iosapic_write(void __iomem *iosapic, unsigned int reg, u32 vastatic 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
@@ -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
Greg Kroah-Hartman
maintainerPATCH 115/183 parisc: drivers: Fix sparse warning
In reply to Greg Kroah-Hartman5.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
@@ -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
Greg Kroah-Hartman
maintainerPATCH 116/183 parisc: irq: Make irq_stack_union static to avoid sparse warning
In reply to Greg Kroah-Hartman5.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
@@ -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
Greg Kroah-Hartman
maintainerPATCH 117/183 scsi: qedf: Add synchronization between I/O completions and abort
In reply to Greg Kroah-Hartman5.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
@@ -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
@@ -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
Greg Kroah-Hartman
maintainerPATCH 118/183 scsi: ufs: core: Move __ufshcd_send_uic_cmd() outside host_lock
In reply to Greg Kroah-Hartman5.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
@@ -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
Greg Kroah-Hartman
maintainerPATCH 119/183 selftests/ftrace: Correctly enable event in instance-event.tc
In reply to Greg Kroah-Hartman5.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
@@ -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
Greg Kroah-Hartman
maintainerPATCH 120/183 ring-buffer: Avoid softlockup in ring_buffer_resize()
In reply to Greg Kroah-Hartman5.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
@@ -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
Greg Kroah-Hartman
maintainerPATCH 121/183 btrfs: improve error message after failure to add delayed dir index item
In reply to Greg Kroah-Hartman5.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
@@ -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
Greg Kroah-Hartman
maintainerPATCH 122/183 selftests: fix dependency checker script
In reply to Greg Kroah-Hartman5.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
@@ -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
Greg Kroah-Hartman
maintainerPATCH 123/183 ring-buffer: Do not attempt to read past "commit"
In reply to Greg Kroah-Hartman5.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
@@ -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
Greg Kroah-Hartman
maintainerPATCH 124/183 platform/mellanox: mlxbf-bootctl: add NET dependency into Kconfig
In reply to Greg Kroah-Hartman5.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
@@ -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
Greg Kroah-Hartman
maintainerPATCH 125/183 drm/amd/display: Dont check registers, if using AUX BL control
In reply to Greg Kroah-Hartman5.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
@@ -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
Greg Kroah-Hartman
maintainerPATCH 126/183 drm/amdgpu: Handle null atom context in VBIOS info ioctl
In reply to Greg Kroah-Hartman5.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
@@ -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
Greg Kroah-Hartman
maintainerPATCH 127/183 scsi: pm80xx: Use phy-specific SAS address when sending PHY_START command
In reply to Greg Kroah-Hartman5.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
@@ -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
@@ -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
Greg Kroah-Hartman
maintainerPATCH 128/183 scsi: pm80xx: Avoid leaking tags when processing OPC_INB_SET_CONTROLLER_CONFIG command
In reply to Greg Kroah-Hartman5.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
@@ -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
Greg Kroah-Hartman
maintainerPATCH 129/183 smb3: correct places where ENOTSUPP is used instead of preferred EOPNOTSUPP
In reply to Greg Kroah-Hartman5.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
@@ -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
@@ -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
Greg Kroah-Hartman
maintainerPATCH 130/183 ata: libata-eh: do not clear ATA_PFLAG_EH_PENDING in ata_eh_reset()
In reply to Greg Kroah-Hartman5.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
@@ -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
Greg Kroah-Hartman
maintainerPATCH 131/183 spi: nxp-fspi: reset the FLSHxCR1 registers
In reply to Greg Kroah-Hartman5.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
@@ -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
Greg Kroah-Hartman
maintainerPATCH 132/183 spi: stm32: add a delay before SPI disable
In reply to Greg Kroah-Hartman5.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
@@ -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
Greg Kroah-Hartman
maintainerPATCH 133/183 ASoC: fsl: imx-pcm-rpmsg: Add SNDRV_PCM_INFO_BATCH flag
In reply to Greg Kroah-Hartman5.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
@@ -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
Greg Kroah-Hartman
maintainerPATCH 134/183 bpf: Clarify error expectations from bpf_clone_redirect
In reply to Greg Kroah-Hartman5.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
@@ -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
@@ -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
Greg Kroah-Hartman
maintainerPATCH 135/183 ASoC: imx-rpmsg: Set ignore_pmdown_time for dai_link
In reply to Greg Kroah-Hartman5.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
@@ -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
Greg Kroah-Hartman
maintainerPATCH 136/183 media: vb2: frame_vector.c: replace WARN_ONCE with a comment
In reply to Greg Kroah-Hartman5.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
@@ -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
Greg Kroah-Hartman
maintainerPATCH 137/183 powerpc/watchpoints: Disable preemption in thread_change_pc()
In reply to Greg Kroah-Hartman5.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
@@ -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
Greg Kroah-Hartman
maintainerPATCH 138/183 powerpc/watchpoint: Disable pagefaults when getting user instruction
In reply to Greg Kroah-Hartman5.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
@@ -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
Greg Kroah-Hartman
maintainerPATCH 139/183 powerpc/watchpoints: Annotate atomic context in more places
In reply to Greg Kroah-Hartman5.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
@@ -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
Greg Kroah-Hartman
maintainerPATCH 140/183 ncsi: Propagate carrier gain/loss events to the NCSI controller
In reply to Greg Kroah-Hartman5.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
@@ -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
Greg Kroah-Hartman
maintainerPATCH 141/183 fbdev/sh7760fb: Depend on FB=y
In reply to Greg Kroah-Hartman5.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
@@ -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
Greg Kroah-Hartman
maintainerPATCH 142/183 perf build: Define YYNOMEM as YYNOABORT for bison < 3.81
In reply to Greg Kroah-Hartman5.15-stable review patch. If anyone has any objections, please let me know.
------------------
From: Arnaldo Carvalho de Melo <[email protected]>
[ Upstream commit 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
@@ -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
Greg Kroah-Hartman
maintainerPATCH 143/183 sched/cpuacct: Optimize away RCU read lock
In reply to Greg Kroah-Hartman5.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
@@ -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
@@ -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
Greg Kroah-Hartman
maintainerPATCH 144/183 cgroup: Fix suspicious rcu_dereference_check() usage warning
In reply to Greg Kroah-Hartman5.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
@@ -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
Greg Kroah-Hartman
maintainerPATCH 145/183 nvme-pci: factor the iod mempool creation into a helper
In reply to Greg Kroah-Hartman5.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
@@ -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
Greg Kroah-Hartman
maintainerPATCH 146/183 nvme-pci: factor out a nvme_pci_alloc_dev helper
In reply to Greg Kroah-Hartman5.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
@@ -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
Greg Kroah-Hartman
maintainerPATCH 147/183 nvme-pci: do not set the NUMA node of device if it has none
In reply to Greg Kroah-Hartman5.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
@@ -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
Greg Kroah-Hartman
maintainerPATCH 148/183 watchdog: iTCO_wdt: No need to stop the timer in probe
In reply to Greg Kroah-Hartman5.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
@@ -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
Greg Kroah-Hartman
maintainerPATCH 149/183 watchdog: iTCO_wdt: Set NO_REBOOT if the watchdog is not already running
In reply to Greg Kroah-Hartman5.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
@@ -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
Greg Kroah-Hartman
maintainerPATCH 150/183 i40e: fix potential NULL pointer dereferencing of pf->vf i40e_sync_vsi_filters()
In reply to Greg Kroah-Hartman5.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
@@ -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
Greg Kroah-Hartman
maintainerPATCH 151/183 perf metric: Return early if no CPU PMU table exists
In reply to Greg Kroah-Hartman5.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 ,)
$
--- tools/perf/util/metricgroup.c | 3 +++ 1 file changed, 3 insertions(+)
tools/perf/util/metricgroup.c +3 -0
@@ -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
Greg Kroah-Hartman
maintainerPATCH 152/183 scsi: qla2xxx: Fix NULL pointer dereference in target mode
In reply to Greg Kroah-Hartman5.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.
--- 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
@@ -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
@@ -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
@@ -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
@@ -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
Greg Kroah-Hartman
maintainerPATCH 153/183 nvme-pci: always return an ERR_PTR from nvme_pci_alloc_dev
In reply to Greg Kroah-Hartman5.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.
--- drivers/nvme/host/pci.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-)
drivers/nvme/host/pci.c +3 -3
@@ -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
Greg Kroah-Hartman
maintainerPATCH 154/183 smack: Record transmuting in smk_transmuted
In reply to Greg Kroah-Hartman5.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
@@ -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
Greg Kroah-Hartman
maintainerPATCH 155/183 smack: Retrieve transmuting information in smack_inode_getsecurity()
In reply to Greg Kroah-Hartman5.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
@@ -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
Greg Kroah-Hartman
maintainerPATCH 156/183 Smack:- Use overlay inode label in smack_inode_copy_up()
In reply to Greg Kroah-Hartman5.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
@@ -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
Greg Kroah-Hartman
maintainerPATCH 157/183 iommu/arm-smmu-v3: Fix soft lockup triggered by arm_smmu_mm_invalidate_range
In reply to Greg Kroah-Hartman5.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
@@ -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
Greg Kroah-Hartman
maintainerPATCH 158/183 x86/srso: Add SRSO mitigation for Hygon processors
In reply to Greg Kroah-Hartman5.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), {} };
Greg Kroah-Hartman
maintainerPATCH 159/183 misc: rtsx: Fix some platforms can not boot and move the l1ss judgment to probe
In reply to Greg Kroah-Hartman5.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_settingstatic 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(structelse 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
Greg Kroah-Hartman
maintainerPATCH 160/183 Revert "tty: n_gsm: fix UAF in gsm_cleanup_mux"
In reply to Greg Kroah-Hartman5.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().
--- 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);
Greg Kroah-Hartman
maintainerPATCH 161/183 serial: 8250_port: Check IRQ data before use
In reply to Greg Kroah-Hartman5.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--- 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);
Greg Kroah-Hartman
maintainerPATCH 162/183 nilfs2: fix potential use after free in nilfs_gccache_submit_read_data()
In reply to Greg Kroah-Hartman5.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(strucstruct 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; }
Greg Kroah-Hartman
maintainerPATCH 163/183 netfilter: nf_tables: disallow rule removal from chain binding
In reply to Greg Kroah-Hartman5.15-stable review patch. If anyone has any objections, please let me know.
------------------
From: Pablo Neira Ayuso <[email protected]>
[ Upstream commit 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").
--- net/netfilter/nf_tables_api.c | 18 +++++++++++++----- 1 file changed, 13 insertions(+), 5 deletions(-)
net/netfilter/nf_tables_api.c +13 -5
@@ -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
Greg Kroah-Hartman
maintainerPATCH 164/183 ALSA: hda: Disable power save for solving pop issue on Lenovo ThinkCentre M70q
In reply to Greg Kroah-Hartman5.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 */
Greg Kroah-Hartman
maintainerPATCH 165/183 ata: libata-scsi: ignore reserved bits for REPORT SUPPORTED OPERATION CODES
In reply to Greg Kroah-Hartman5.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).
--- 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_devicebreak ;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 );
Greg Kroah-Hartman
maintainerPATCH 166/183 i2c: i801: unregister tco_pdev in i801_probe() error path
In reply to Greg Kroah-Hartman5.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.
--- 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; }
Greg Kroah-Hartman
maintainerPATCH 167/183 kernel/sched: Modify initial boot task idle setup
In reply to Greg Kroah-Hartman5.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 )
Greg Kroah-Hartman
maintainerPATCH 168/183 sched/rt: Fix live lock between select_fallback_rq() and RT push
In reply to Greg Kroah-Hartman5.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 cif (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
Greg Kroah-Hartman
maintainerPATCH 169/183 io_uring/fs: remove sqe->rw_flags checking from LINKAT
In reply to Greg Kroah-Hartman5.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.
--- 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_kiocif (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 ;
Greg Kroah-Hartman
maintainerPATCH 170/183 Revert "SUNRPC dont update timeout value on connection reset"
In reply to Greg Kroah-Hartman5.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.
--- 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);
Greg Kroah-Hartman
maintainerPATCH 171/183 proc: nommu: /proc/<pid>/maps: release mmap read lock
In reply to Greg Kroah-Hartman5.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.
--- 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)
Greg Kroah-Hartman
maintainerPATCH 172/183 ring-buffer: Update "shortest_full" in polling
In reply to Greg Kroah-Hartman5.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.
--- 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 trif (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;
Greg Kroah-Hartman
maintainerPATCH 173/183 btrfs: properly report 0 avail for very full file systems
In reply to Greg Kroah-Hartman5.15-stable review patch. If anyone has any objections, please let me know.
------------------
From: Josef Bacik <[email protected]>
commit 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 ;
Greg Kroah-Hartman
maintainerPATCH 174/183 bpf: Fix BTF_ID symbol generation collision
In reply to Greg Kroah-Hartman5.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
Greg Kroah-Hartman
maintainerPATCH 175/183 bpf: Fix BTF_ID symbol generation collision in tools/
In reply to Greg Kroah-Hartman5.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
Greg Kroah-Hartman
maintainerPATCH 176/183 net: thunderbolt: Fix TCPv6 GSO checksum calculation
In reply to Greg Kroah-Hartman5.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,
Greg Kroah-Hartman
maintainerPATCH 177/183 ata: libata-core: Fix ata_port_request_pm() locking
In reply to Greg Kroah-Hartman5.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 astruct 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 aspin_unlock_irqrestore (ap->lock, flags); -if (!async) { +if (!async)ata_port_wait_eh (ap); -WARN_ON (ap->pflags &ATA_PFLAG_PM_PENDING ); - } }/*
Greg Kroah-Hartman
maintainerPATCH 178/183 ata: libata-core: Fix port and device removal
In reply to Greg Kroah-Hartman5.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_pif (!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);
Greg Kroah-Hartman
maintainerPATCH 179/183 ata: libata-core: Do not register PM operations for SAS ports
In reply to Greg Kroah-Hartman5.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 *aput_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;
Greg Kroah-Hartman
maintainerPATCH 180/183 ata: libata-sata: increase PMP SRST timeout to 10s
In reply to Greg Kroah-Hartman5.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.
--- 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
Greg Kroah-Hartman
maintainerPATCH 181/183 fs: binfmt_elf_efpic: fix personality for ELF-FDPIC
In reply to Greg Kroah-Hartman5.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.
--- 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 ;
Greg Kroah-Hartman
maintainerPATCH 182/183 drm/meson: fix memory leak on ->hpd_notify callback
In reply to Greg Kroah-Hartman5.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.
--- 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_notifreturn ;cec_notifier_set_phys_addr_from_edid (encoder_hdmi->cec_notifier, edid); + +kfree (edid); }else cec_notifier_phys_addr_invalidate (encoder_hdmi->cec_notifier); }
Greg Kroah-Hartman
maintainerPATCH 183/183 netfilter: nf_tables: fix kdoc warnings after gc rework
In reply to Greg Kroah-Hartman5.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'
--- 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)
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.gzor in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.gitlinux-5.15.y
and the diffstat can be found below.thanks,
greg k-h
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
Greg Kroah-Hartman
maintainerQuoted 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.gzor in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.gitlinux-5.15.y
and the diffstat can be found below.thanks,
greg k-h
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 1caused 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 usejevents.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
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.gzor in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.gitlinux-5.15.y
and the diffstat can be found below.thanks,
greg k-h
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 1caused 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 usejevents.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
Greg Kroah-Hartman
maintainerQuoted 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.gzor in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.gitlinux-5.15.y
and the diffstat can be found below.thanks,
greg k-h
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 1caused 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 usejevents.py") was causing build failures:
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 intools/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:
c1ef510a0f2aperf metric: Return early if no CPU PMU table exists Patch 81:40ddac4ffc75perf build: Update build rule for generated files Patch 80:8df938ed8c8aperf jevents: Switch build to usejevents.py
All of these are now dropped.
thanks,
greg k-h
Sasha Levin
maintainerQuoted 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.gzor in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.gitlinux-5.15.y
and the diffstat can be found below.thanks,
greg k-h
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 1caused 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 usejevents.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 intools/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
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.gitlinux-5.15.yQuoted 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 usein this
Quoted 4 lines
Quoted 4 lines
function)
if (!table)
^~~~~util/metricgroup.c:1261:7: note: each undeclared identifier isreported 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("perfjevents:
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 intools/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
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.gzor in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.gitlinux-5.15.y
and the diffstat can be found below.thanks,
greg k-h
Compiled and booted on my test system. No dmesg regressions.
thanks,
-- Shuah
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.gzor in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.gitlinux-5.15.y
and the diffstat can be found below.
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
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.gzor in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.gitlinux-5.15.y
and the diffstat can be found below.thanks,
greg k-h
Results from Linaro’s test farm.
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
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.gzor in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.gitlinux-5.15.y
and the diffstat can be found below.thanks,
greg k-h
Results from Linaro’s test farm.
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 setCONFIG_SRCU=yCONFIG_TREE_SRCU=yCONFIG_TASKS_RCU_GENERIC=yCONFIG_TASKS_RUDE_RCU=yCONFIG_TASKS_TRACE_RCU=yCONFIG_RCU_STALL_COMMON=yCONFIG_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 setCONFIG_RCU_CPU_STALL_TIMEOUT=21CONFIG_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
Paul E. McKenney
maintainerQuoted 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.gzor in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.gitlinux-5.15.y
and the diffstat can be found below.thanks,
greg k-h
Results from Linaro’s test farm.
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_EXPERTis not setCONFIG_SRCU=yCONFIG_TREE_SRCU=yCONFIG_TASKS_RCU_GENERIC=yCONFIG_TASKS_RUDE_RCU=yCONFIG_TASKS_TRACE_RCU=yCONFIG_RCU_STALL_COMMON=yCONFIG_RCU_NEED_SEGCBLIST=y# end of RCU Subsystem#
# RCU Debugging
#CONFIG_PROVE_RCU=y
#CONFIG_RCU_SCALE_TESTis not set
#CONFIG_RCU_TORTURE_TESTis not set
#CONFIG_RCU_REF_SCALE_TESTis not setCONFIG_RCU_CPU_STALL_TIMEOUT=21CONFIG_RCU_TRACE=y
#CONFIG_RCU_EQS_DEBUGis not set# end of RCU DebuggingQuoted 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 in897ba84dc5aa("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
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.gzor in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.gitlinux-5.15.y
and the diffstat can be found below.thanks,
greg k-h
Results from Linaro’s test farm.
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_EXPERTis not setCONFIG_SRCU=yCONFIG_TREE_SRCU=yCONFIG_TASKS_RCU_GENERIC=yCONFIG_TASKS_RUDE_RCU=yCONFIG_TASKS_TRACE_RCU=yCONFIG_RCU_STALL_COMMON=yCONFIG_RCU_NEED_SEGCBLIST=y# end of RCU Subsystem#
# RCU Debugging
#CONFIG_PROVE_RCU=y
#CONFIG_RCU_SCALE_TESTis not set
#CONFIG_RCU_TORTURE_TESTis not set
#CONFIG_RCU_REF_SCALE_TESTis not setCONFIG_RCU_CPU_STALL_TIMEOUT=21CONFIG_RCU_TRACE=y
#CONFIG_RCU_EQS_DEBUGis not set# end of RCU DebuggingQuoted 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/0xb0Quoted 8 lines
This function has changed a lot, including the dropping of this
WARN_ON_ONCE(). The warning was replaced in897ba84dc5aa("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
Paul E. McKenney
maintainerQuoted 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.gzor in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.gitlinux-5.15.y
and the diffstat can be found below.thanks,
greg k-h
Results from Linaro’s test farm.
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_EXPERTis not setCONFIG_SRCU=yCONFIG_TREE_SRCU=yCONFIG_TASKS_RCU_GENERIC=yCONFIG_TASKS_RUDE_RCU=yCONFIG_TASKS_TRACE_RCU=yCONFIG_RCU_STALL_COMMON=yCONFIG_RCU_NEED_SEGCBLIST=y# end of RCU Subsystem#
# RCU Debugging
#CONFIG_PROVE_RCU=y
#CONFIG_RCU_SCALE_TESTis not set
#CONFIG_RCU_TORTURE_TESTis not set
#CONFIG_RCU_REF_SCALE_TESTis not setCONFIG_RCU_CPU_STALL_TIMEOUT=21CONFIG_RCU_TRACE=y
#CONFIG_RCU_EQS_DEBUGis not set# end of RCU DebuggingQuoted 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/0xb0Quoted 8 lines
This function has changed a lot, including the dropping of this
WARN_ON_ONCE(). The warning was replaced in897ba84dc5aa("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
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.gzor in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.gitlinux-5.15.y
and the diffstat can be found below.thanks,
greg k-h
Results from Linaro’s test farm.
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_EXPERTis not setCONFIG_SRCU=yCONFIG_TREE_SRCU=yCONFIG_TASKS_RCU_GENERIC=yCONFIG_TASKS_RUDE_RCU=yCONFIG_TASKS_TRACE_RCU=yCONFIG_RCU_STALL_COMMON=yCONFIG_RCU_NEED_SEGCBLIST=y# end of RCU Subsystem#
# RCU Debugging
#CONFIG_PROVE_RCU=y
#CONFIG_RCU_SCALE_TESTis not set
#CONFIG_RCU_TORTURE_TESTis not set
#CONFIG_RCU_REF_SCALE_TESTis not setCONFIG_RCU_CPU_STALL_TIMEOUT=21CONFIG_RCU_TRACE=y
#CONFIG_RCU_EQS_DEBUGis not set# end of RCU DebuggingQuoted 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/0xb0Quoted 8 lines
This function has changed a lot, including the dropping of this
WARN_ON_ONCE(). The warning was replaced in897ba84dc5aa("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
Paul E. McKenney
maintainerQuoted 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.gzor in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.gitlinux-5.15.y
and the diffstat can be found below.thanks,
greg k-h
Results from Linaro’s test farm.
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_EXPERTis not setCONFIG_SRCU=yCONFIG_TREE_SRCU=yCONFIG_TASKS_RCU_GENERIC=yCONFIG_TASKS_RUDE_RCU=yCONFIG_TASKS_TRACE_RCU=yCONFIG_RCU_STALL_COMMON=yCONFIG_RCU_NEED_SEGCBLIST=y# end of RCU Subsystem#
# RCU Debugging
#CONFIG_PROVE_RCU=y
#CONFIG_RCU_SCALE_TESTis not set
#CONFIG_RCU_TORTURE_TESTis not set
#CONFIG_RCU_REF_SCALE_TESTis not setCONFIG_RCU_CPU_STALL_TIMEOUT=21CONFIG_RCU_TRACE=y
#CONFIG_RCU_EQS_DEBUGis not set# end of RCU DebuggingQuoted 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/0xb0Quoted 8 lines
This function has changed a lot, including the dropping of this
WARN_ON_ONCE(). The warning was replaced in897ba84dc5aa("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
Paul E. McKenney
maintainerQuoted 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.gzor in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.gitlinux-5.15.y
and the diffstat can be found below.thanks,
greg k-h
Results from Linaro’s test farm.
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_EXPERTis not setCONFIG_SRCU=yCONFIG_TREE_SRCU=yCONFIG_TASKS_RCU_GENERIC=yCONFIG_TASKS_RUDE_RCU=yCONFIG_TASKS_TRACE_RCU=yCONFIG_RCU_STALL_COMMON=yCONFIG_RCU_NEED_SEGCBLIST=y# end of RCU Subsystem#
# RCU Debugging
#CONFIG_PROVE_RCU=y
#CONFIG_RCU_SCALE_TESTis not set
#CONFIG_RCU_TORTURE_TESTis not set
#CONFIG_RCU_REF_SCALE_TESTis not setCONFIG_RCU_CPU_STALL_TIMEOUT=21CONFIG_RCU_TRACE=y
#CONFIG_RCU_EQS_DEBUGis not set# end of RCU DebuggingQuoted 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/0xb0Quoted 8 lines
This function has changed a lot, including the dropping of this
WARN_ON_ONCE(). The warning was replaced in897ba84dc5aa("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
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 x86start_secondary()invokesset_cpu_online()before it callscpu_startup_entry(), and it is the latter than setsPF_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 theset_cpu_online()and thecpu_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
clearedPF_IDLEonly for the boot CPU.o Set
PF_IDLEbefore callingset_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()intocpu_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()fromtrc_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 intrc_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
Paul E. McKenney
maintainerQuoted 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 x86start_secondary()invokesset_cpu_online()before it callscpu_startup_entry(), and it is the latter than setsPF_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 theset_cpu_online()and thecpu_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 toPF_IDLEyet: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
clearedPF_IDLEonly for the boot CPU.o Set
PF_IDLEbefore callingset_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()intocpu_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()fromtrc_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 intrc_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 ofis_idle_task()?
ThoughPF_IDLEis also set inplay_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
Frederic Weisbecker
maintainerQuoted 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
@@ -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
@@ -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
@@ -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;
Paul E. McKenney
maintainerQuoted 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()orstart_poll_synchronize_rcu()so early that the CPU is not even online? (that's beforeboot_cpu_init()!)
Quoted 8 lines
Deferring
PF_IDLEsetting might pave the way for more issues like this one, present or future. Thoughis_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. Sincercu_qs()during the context switch raises a softirq anyway. It's more overhead forstart_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@@ -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@@ -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@@ -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;
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
Paul E. McKenney
maintainerQuoted 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
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
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.gzor in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.gitlinux-5.15.y
and the diffstat can be found below.thanks,
greg k-h
Built and booted successfully on RISC-V RV64 (HiFive Unmatched).
Quoted 9 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 5.15.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.gzor in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.gitlinux-5.15.y
and the diffstat can be found below.thanks,
greg k-h
All tests passing for Tegra ...
Test results for stable-v5.15:
10 builds: 10 pass, 0 fail
26 boots: 26 pass, 0 fail
94 tests: 94 pass, 0 failLinux 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-a04Jon
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.gzor in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.gitlinux-5.15.y
and the diffstat can be found below.
[...]
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: unregistertco_pdevini801_probe()error pathNiklas Cassel <[email protected]>
ata: libata-scsi: ignore reserved bits for REPORT SUPPORTED OPERATION CODESKailang Yang <[email protected]>
ALSA: hda: Disable power save for solving pop issue on Lenovo ThinkCentre M70qPablo Neira Ayuso <[email protected]>
netfilter:nf_tables: disallow rule removal from chain bindingPan Bian <[email protected]>
nilfs2: fix potential use after free innilfs_gccache_submit_read_data()Andy Shevchenko <[email protected]>
serial: 8250_port: Check IRQ data before useDaniel Starke <[email protected]>
Revert "tty:n_gsm: fix UAF ingsm_cleanup_mux"Ricky WU <[email protected]>
misc: rtsx: Fix some platforms can not boot and move the l1ss judgment to probePu Wen <[email protected]>
x86/srso: Add SRSO mitigation for Hygon processorsNicolin Chen <[email protected]>
iommu/arm-smmu-v3: Fix soft lockup triggered byarm_smmu_mm_invalidate_rangeVishal Goel <[email protected]>
Smack:- Use overlay inode label insmack_inode_copy_up()Roberto Sassu <[email protected]>
smack: Retrieve transmuting information insmack_inode_getsecurity()Roberto Sassu <[email protected]>
smack: Record transmuting insmk_transmutedIrvin Cote <[email protected]>
nvme-pci: always return anERR_PTRfromnvme_pci_alloc_devGleb Chesnokov <[email protected]>
scsi: qla2xxx: Fix NULL pointer dereference in target modeIan Rogers <[email protected]>
perf metric: Return early if no CPU PMU table existsAndrii Staikov <[email protected]>
i40e: fix potential NULL pointer dereferencing of pf->vf i40e_sync_vsi_filters()Mika Westerberg <[email protected]>
watchdog:iTCO_wdt: SetNO_REBOOTif the watchdog is not already runningMika Westerberg <[email protected]>
watchdog:iTCO_wdt: No need to stop the timer in probePratyush Yadav <[email protected]>
nvme-pci: do not set the NUMA node of device if it has noneChristoph Hellwig <[email protected]>
nvme-pci: factor out anvme_pci_alloc_devhelperChristoph Hellwig <[email protected]>
nvme-pci: factor the iod mempool creation into a helperChengming Zhou <[email protected]>
cgroup: Fix suspiciousrcu_dereference_check()usage warningChengming Zhou <[email protected]>
sched/cpuacct: Optimize away RCU read lockArnaldo Carvalho de Melo <[email protected]>
perf build: Define YYNOMEM as YYNOABORT for bison < 3.81Thomas Zimmermann <[email protected]>
fbdev/sh7760fb: Depend on FB=yJohnathan Mantey <[email protected]>
ncsi: Propagate carrier gain/loss events to the NCSI controllerBenjamin Gray <[email protected]>
powerpc/watchpoints: Annotate atomic context in more placesBenjamin Gray <[email protected]>
powerpc/watchpoint: Disable pagefaults when getting user instructionBenjamin Gray <[email protected]>
powerpc/watchpoints: Disable preemption inthread_change_pc()Hans Verkuil <[email protected]>
media: vb2:frame_vector.c: replaceWARN_ONCEwith a commentChancel Liu <[email protected]>
ASoC: imx-rpmsg: Setignore_pmdown_timefordai_linkStanislav Fomichev <[email protected]>
bpf: Clarify error expectations frombpf_clone_redirectShengjiu Wang <[email protected]>
ASoC: fsl: imx-pcm-rpmsg: AddSNDRV_PCM_INFO_BATCHflagValentin Caron <[email protected]>
spi: stm32: add a delay before SPI disableHan Xu <[email protected]>
spi: nxp-fspi: reset the FLSHxCR1 registersNiklas Cassel <[email protected]>
ata: libata-eh: do not clearATA_PFLAG_EH_PENDINGinata_eh_reset()Steve French <[email protected]>
smb3: correct places where ENOTSUPP is used instead of preferred EOPNOTSUPPMichal Grzedzicki <[email protected]>
scsi: pm80xx: Avoid leaking tags when processing OPC_INB_SET_CONTROLLER_CONFIG commandMichal Grzedzicki <[email protected]>
scsi: pm80xx: Use phy-specific SAS address when sending PHY_START commandDavid Francis <[email protected]>
drm/amdgpu: Handle null atom context in VBIOS info ioctlSwapnil Patel <[email protected]>
drm/amd/display: Don't check registers, if using AUX BL controlDavid Thompson <[email protected]>
platform/mellanox: mlxbf-bootctl: add NET dependency intoKconfigSteven Rostedt (Google) <[email protected]>
ring-buffer: Do not attempt to read past "commit"Ricardo B. Marliere <[email protected]>
selftests: fix dependency checker scriptFilipe Manana <[email protected]>
btrfs: improve error message after failure to add delayed dir index itemZheng Yejian <[email protected]>
ring-buffer: Avoid softlockup inring_buffer_resize()Zheng Yejian <[email protected]>
selftests/ftrace: Correctly enable event in instance-event.tcKiwoong Kim <[email protected]>
scsi: ufs: core: Move__ufshcd_send_uic_cmd()outsidehost_lockJaved Hasan <[email protected]>
scsi: qedf: Add synchronization between I/O completions and abortHelge Deller <[email protected]>
parisc: irq: Makeirq_stack_unionstatic to avoid sparse warningHelge Deller <[email protected]>
parisc: drivers: Fix sparse warningHelge Deller <[email protected]>
parisc:iosapic.c: Fix sparse warningsHelge Deller <[email protected]>
parisc: sba: Fix compile warning wrt list of SBA devicesTobias Schramm <[email protected]>
spi: sun6i: fix race between DMA RX transfer completion and RX FIFO drainTobias Schramm <[email protected]>
spi: sun6i: reduce DMA RX transfer width to single byteSergey Senozhatsky <[email protected]>
dma-debug: don't call__dma_entry_alloc_check_leak()underfree_entries_lockWilliam A. Kennington III <[email protected]>
i2c: npcm7xx: Fix callback completion orderingWenhua Lin <[email protected]>
gpio: pmic-eic-sprd: Addcan_sleepflag for PMIC EIC chipNathan Rossi <[email protected]>
soc: imx8m: Enable OCOTP clock for imx8mm before reading registersMax Filippov <[email protected]>
xtensa: boot/lib: fix function prototypesRandy Dunlap <[email protected]>
xtensa: boot: don't add include-dirsRandy Dunlap <[email protected]>
xtensa: iss/network: make functions staticMax Filippov <[email protected]>
xtensa: add default definition forXCHAL_HAVE_DIV32Christophe JAILLET <[email protected]>
firmware: imx-dsp: Fix an error handling path inimx_dsp_setup_channels()Dan Carpenter <[email protected]>
power: supply: ucs1002: fix error code inucs1002_get_property()Tony Lindgren <[email protected]>
bus: ti-sysc: FixSYSC_QUIRK_SWSUP_SIDLE_ACThandling for uart wake-upTony Lindgren <[email protected]>
ARM: dts: ti: omap: motorola-mapphone: Fixabe_clkctrlwarning on bootTony Lindgren <[email protected]>
ARM: dts: ti: omap: Fix bandgap thermal cells addressing for omap3/4Krzysztof Kozlowski <[email protected]>
ARM: dts: omap: correct indentationThomas 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 forrecalc_rateAdam Ford <[email protected]>
bus: ti-sysc: Fix missing AM35xx SoC matchingJulien Panis <[email protected]>
bus: ti-sysc: Usefsleep()instead ofusleep_range()insysc_reset()Marek Vasut <[email protected]>
drm/bridge: ti-sn65dsi83: Do not generate HFP/HBP/HSA and EOT packetChristoph Hellwig <[email protected]>
MIPS: Alchemy: only build mmc support helpers if au1xmmc is enabledQu Wenruo <[email protected]>
btrfs: reset destination buffer whenread_extent_buffer()gets invalid rangeNilesh Javali <[email protected]>
scsi: qla2xxx: Useraw_smp_processor_id()instead ofsmp_processor_id()Shreyas Deodhar <[email protected]>
scsi: qla2xxx: Select qpair depending on which CPUpost_cmd()gets calledWerner Fischer <[email protected]>
ata: ahci: Add Elkhart Lake AHCI controllerMario Limonciello <[email protected]>
ata: ahci: Renameboard_ahci_mobilePaul Menzel <[email protected]>
ata: ahci: Add support for AMD A85 FCH (Hudson D4)Paul Menzel <[email protected]>
ata: libata: Rename link flagATA_LFLAG_NO_DB_DELAYXiao Liang <[email protected]>
netfilter:nft_exthdr: Fix non-linear header modificationFlorian Westphal <[email protected]>
netfilter: exthdr: add support for tcp option removalNamhyung Kim <[email protected]>
perf build: Update build rule for generated filesIan Rogers <[email protected]>
perf jevents: Switch build to usejevents.pyWerner Sembach <[email protected]>
Input: i8042 - add quirk for TUXEDO Gemini 17 Gen1/Clevo PD70PNHuacai Chen <[email protected]>
Input: i8042 - rename i8042-x86ia64io.h to i8042-acpipnpio.hDarrick J. Wong <[email protected]>
xfs: fixxfs_inodegc_stopracing withmod_delayed_workDarrick J. Wong <[email protected]>
xfs: disable reaping in fscounters scrubDarrick J. Wong <[email protected]>
xfs: check that per-cpu inodegc workers actually run on that cpuDarrick J. Wong <[email protected]>
xfs: explicitly specify cpu when forcing inodegc delayed work to run immediatelyDave Chinner <[email protected]>
xfs: introducexfs_inodegc_push()Dave Chinner <[email protected]>
xfs: bound maximum wait time for inodegc workLiang He <[email protected]>
i2c: mux: gpio: Add missingfwnode_handle_put()Andy Shevchenko <[email protected]>
i2c: mux: gpio: Replace customacpi_get_local_address()Xiaoke Wang <[email protected]>
i2c: mux: demux-pinctrl: check the return value ofdevm_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 abouticc_bw_lockorder")Muhammad Husaini Zulkifli <[email protected]>
igc: Expose tx-usecs coalesce setting to userSebastian Andrzej Siewior <[email protected]>
bnxt_en: Flush XDP for bnxt_poll_nitroa0()'s NAPISebastian Andrzej Siewior <[email protected]>
net: ena: Flush XDP packets on error.Sebastian Andrzej Siewior <[email protected]>
locking/seqlock: Do the lockdep annotation before locking indo_write_seqcount_begin_nested()Jozsef Kadlecsik <[email protected]>
netfilter: ipset: Fix race betweenIPSET_CMD_CREATEandIPSET_CMD_SWAPFlorian Westphal <[email protected]>
netfilter:nf_tables: disable toggling dormant table state more than onceArtem Chernyshev <[email protected]>
net: rds: Fix possible NULL-pointer dereferenceZiyang Xuan <[email protected]>
team: fix null-ptr-deref when team device type is changedEric Dumazet <[email protected]>
net: bridge: useDEV_STATS_INC()Jie Wang <[email protected]>
net: hns3: add 5ms delay before clear firmware reset irq sourceJijie Shao <[email protected]>
net: hns3: fix fail to delete tc flower rules during reset issueJian Shen <[email protected]>
net: hns3: only enable unicast promisc when mac table fullJie Wang <[email protected]>
net: hns3: fix GRE checksum offload issueJosh Poimboeuf <[email protected]>
x86/srso: Fix SBPB enablement for spec_rstack_overflow=offJosh Poimboeuf <[email protected]>
x86/srso: Fixsrso_show_state()side effectStephen Boyd <[email protected]>
platform/x86:intel_scu_ipc: Fail IPC send if still busyStephen Boyd <[email protected]>
platform/x86:intel_scu_ipc: Don't override scu inintel_scu_ipc_dev_simple_command()Stephen Boyd <[email protected]>
platform/x86:intel_scu_ipc: Check status upon timeout inipc_wait_for_interrupt()Stephen Boyd <[email protected]>
platform/x86:intel_scu_ipc: Check status after timeout inbusy_loop()Eric Dumazet <[email protected]>
dccp: fix dccp_v4_err()/dccp_v6_err() againKajol Jain <[email protected]>
powerpc/perf/hv-24x7: Update domain value checkKyle Zeng <[email protected]>
ipv4: fix null-deref inipv4_link_failureVinicius Costa Gomes <[email protected]>
igc: Fix infinite initialization loop with early XDP redirectDavid Christensen <[email protected]>
ionic: fix 16bit math issue whenPAGE_SIZE>= 64KBIvan Vecera <[email protected]>
i40e: Fix VF VLAN offloading when port VLAN is configuredMateusz Palczewski <[email protected]>
i40e: Add VF VLAN pruningRadoslaw Tyl <[email protected]>
iavf: do not process adminq tasks when__IAVF_IN_REMOVE_TASKis setShengjiu Wang <[email protected]>
ASoC: imx-audmix: Fix return error withdevm_clk_get()Sasha Neftin <[email protected]>
net/core: FixETH_P_1588flow dissectorSabrina Dubroca <[email protected]>
selftests: tls: swap the TX and RX sockets in some testsToke Høiland-Jørgensen <[email protected]>
bpf: Avoid deadlock when using queue and stack maps from NMIPablo Neira Ayuso <[email protected]>
netfilter:nf_tables: disallow element removal on anonymous setsJerome Brunet <[email protected]>
ASoC: meson: spdifin: start hw on dai probeFlorian Westphal <[email protected]>
netfilter:nf_tables: fix memleak when more than 255 elements expiredPablo Neira Ayuso <[email protected]>
netfilter:nft_set_hash: try later when GC hits EAGAIN on iterationPablo Neira Ayuso <[email protected]>
netfilter:nft_set_pipapo: stop GC iteration if GC transaction allocation failsPablo Neira Ayuso <[email protected]>
netfilter:nft_set_pipapo: callnft_trans_gc_queue_sync()in catchall GCPablo Neira Ayuso <[email protected]>
netfilter:nft_set_rbtree: use read spinlock to avoid datapath contentionPablo Neira Ayuso <[email protected]>
netfilter:nft_set_rbtree: skip sync GC for new elements in this transactionFlorian Westphal <[email protected]>
netfilter:nf_tables: defer gc run if previous batch is still pendingPablo Neira Ayuso <[email protected]>
netfilter:nf_tables: use correct lock to protectgc_listPablo Neira Ayuso <[email protected]>
netfilter:nf_tables: GC transaction race with abort pathPablo Neira Ayuso <[email protected]>
netfilter:nf_tables: GC transaction race with netns dismantlePablo Neira Ayuso <[email protected]>
netfilter:nf_tables: fix GC transaction races with netns and netlink event exit pathFlorian Westphal <[email protected]>
netfilter:nf_tables: don't fail inserts if duplicate has expiredPablo Neira Ayuso <[email protected]>
netfilter:nf_tables: remove busy mark and gc batch APIPablo Neira Ayuso <[email protected]>
netfilter:nft_set_hash: mark set element as dead when deleting from packet pathPablo Neira Ayuso <[email protected]>
netfilter:nf_tables: adapt set backend to use GC transaction APIPablo Neira Ayuso <[email protected]>
netfilter:nf_tables: GC transaction API to avoid race with control planeFlorian Westphal <[email protected]>
netfilter:nf_tables: don't skip expired elements during walkSteven Rostedt (Google) <[email protected]>
tracing: Have event inject files inc the trace array ref countJan Kara <[email protected]>
ext4: do not let fstrim block system suspendJan Kara <[email protected]>
ext4: move setting of trimmed bit intoext4_try_to_trim_range()Kemeng Shi <[email protected]>
ext4: replace the traditional ternary conditional operator with with max()/min()Lukas Czerner <[email protected]>
ext4: changes_last_trim_minblkstype to unsigned longLukas Bulwahn <[email protected]>
ext4: scope ret locally inext4_try_to_trim_range()Szuying Chen <[email protected]>
ata: libahci: clear pending interrupt statusHannes Reinecke <[email protected]>
ata: ahci: Drop pointlessVPRINTK()calls and convert the remaining onesSteven Rostedt (Google) <[email protected]>
tracing: Increase trace array ref count on enable and filter filesJohn Keeping <[email protected]>
tracing: Make trace_marker{,_raw} stream-likeOlga Kornievskaia <[email protected]>
NFSv4.1: fix pnfs MDS=DS session trunkingOlga Kornievskaia <[email protected]>
NFSv4.1: useEXCHGID4_FLAG_USE_PNFS_DSfor DS serverTrond Myklebust <[email protected]>
SUNRPC: Mark the cred for revalidation if the server rejects itTrond Myklebust <[email protected]>
NFS/pNFS: Report EINVAL errors fromconnect()to the serverTrond Myklebust <[email protected]>
NFS: More fixes fornfs_direct_write_reschedule_io()Trond Myklebust <[email protected]>
NFS: Use the correct commit info innfs_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(-)
Greg Kroah-Hartman
maintainerQuoted 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.gzor in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.gitlinux-5.15.y
and the diffstat can be found below.[...]
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
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.gzor in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.gitlinux-5.15.y
and the diffstat can be found below.[...]
Quoted 3 lines
Liam R. Howlett <[email protected]>
kernel/sched: Modify initial boot task idle setupLet 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-rc3should 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
Greg Kroah-Hartman
maintainerQuoted 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.gzor in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.gitlinux-5.15.y
and the diffstat can be found below.[...]
Quoted 3 lines
Liam R. Howlett <[email protected]>
kernel/sched: Modify initial boot task idle setupLet 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-rc3should 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