6.9.6-rc1 review

PATCH In review Greg Kroah-Hartman 18 participants 311 messages Jun 19, 2024 – Jul 2, 2024 Page 3 of 3

Subsystems (6)

Stable branch Memory management Tegra architecture support cgroup +2 more subsystems

lore

Share & tools

lore

Greg Kroah-Hartman

author maintainer

2024-06-19 13:24 UTC #284 lore raw

PATCH 274/281 serial: 8250_dw: Dont use struct dw8250_data outside of 8250_dw

In reply to Greg Kroah-Hartman

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

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

From: Andy Shevchenko <[email protected]>

[ Upstream commit 87d80bfbd577912462061b1a45c0ed9c7fcb872f ]

The container of the struct dw8250_port_data is private to the actual driver. In particular, 8250_lpss and 8250_dw use different data types that are assigned to the UART port private_data. Hence, it must not be used outside the specific driver.

Currently the only cpr_val is required by the common code, make it be available via struct dw8250_port_data.

This fixes the UART breakage on Intel Galileo boards.

Fixes 593dea000bc1 ("serial: 8250: dw: Allow to use a fallback CPR value if not synthesized")

Signed-off-by Andy Shevchenko <[email protected]>

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

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

Signed-off-by Sasha Levin <[email protected]>

---
 drivers/tty/serial/8250/8250_dw.c    | 9 +++++++--
 drivers/tty/serial/8250/8250_dwlib.c | 3 +--
 drivers/tty/serial/8250/8250_dwlib.h | 3 ++-
 3 files changed, 10 insertions(+), 5 deletions(-)

drivers/tty/serial/8250/8250_dw.c +7 -2

index 1300c92b8702a..94d680e4b5353 100644
@@ -55,6 +55,7 @@
 #define DW_UART_QUIRK_SKIP_SET_RATE	BIT(2)
 #define DW_UART_QUIRK_IS_DMA_FC		BIT(3)
 #define DW_UART_QUIRK_APMC0D08		BIT(4)
+#define DW_UART_QUIRK_CPR_VALUE		BIT(5)
 
 static inline struct dw8250_data *clk_to_dw8250_data(struct notifier_block *nb)
 {

@@ -445,6 +446,10 @@ static void dw8250_prepare_rx_dma(struct uart_8250_port *p)
 static void dw8250_quirks(struct uart_port *p, struct dw8250_data *data)
 {
 	unsigned int quirks = data->pdata ? data->pdata->quirks : 0;
+	u32 cpr_value = data->pdata ? data->pdata->cpr_value : 0;
+
+	if (quirks & DW_UART_QUIRK_CPR_VALUE)
+		data->data.cpr_value = cpr_value;
 
 #ifdef CONFIG_64BIT
 	if (quirks & DW_UART_QUIRK_OCTEON) {

@@ -727,8 +732,8 @@ static const struct dw8250_platform_data dw8250_armada_38x_data = {
 
 static const struct dw8250_platform_data dw8250_renesas_rzn1_data = {
 	.usr_reg = DW_UART_USR,
-	.cpr_val = 0x00012f32,
-	.quirks = DW_UART_QUIRK_IS_DMA_FC,
+	.cpr_value = 0x00012f32,
+	.quirks = DW_UART_QUIRK_CPR_VALUE | DW_UART_QUIRK_IS_DMA_FC,
 };
 
 static const struct dw8250_platform_data dw8250_starfive_jh7100_data = {

drivers/tty/serial/8250/8250_dwlib.c +1 -2

index 3e33ddf7bc800..5a2520943dfd5 100644
@@ -242,7 +242,6 @@ static const struct serial_rs485 dw8250_rs485_supported = {
 void dw8250_setup_port(struct uart_port *p)
 {
 	struct dw8250_port_data *pd = p->private_data;
-	struct dw8250_data *data = to_dw8250_data(pd);
 	struct uart_8250_port *up = up_to_u8250p(p);
 	u32 reg, old_dlf;

@@ -278,7 +277,7 @@ void dw8250_setup_port(struct uart_port *p)
 
 	reg = dw8250_readl_ext(p, DW_UART_CPR);
 	if (!reg) {
-		reg = data->pdata->cpr_val;
+		reg = pd->cpr_value;
 		dev_dbg(p->dev, "CPR is not available, using 0x%08x instead\n", reg);
 	}
 	if (!reg)

drivers/tty/serial/8250/8250_dwlib.h +2 -1

index f13e91f2cace9..794a9014cdac1 100644
@@ -19,6 +19,7 @@ struct dw8250_port_data {
 	struct uart_8250_dma	dma;
 
 	/* Hardware configuration */
+	u32			cpr_value;
 	u8			dlf_size;
 
 	/* RS485 variables */

@@ -27,7 +28,7 @@ struct dw8250_port_data {
 
 struct dw8250_platform_data {
 	u8 usr_reg;
-	u32 cpr_val;
+	u32 cpr_value;
 	unsigned int quirks;
 };

Signature · 1 line

2.43.0

Greg Kroah-Hartman

author maintainer

2024-06-19 13:24 UTC #285 lore raw

PATCH 275/281 dt-bindings: usb: realtek,rts5411: Add missing "additionalProperties" on child nodes

In reply to Greg Kroah-Hartman

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

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

From: Rob Herring (Arm) <[email protected]>

[ Upstream commit e4228cfd092351c2d9b1a3048b2070287291ccbb ]

All nodes need an explicit additionalProperties or unevaluatedProperties unless a $ref has one that's false. As that is not the case with usb-device.yaml, "additionalProperties" is needed here.

Fixes c44d9dab31d6 ("dt-bindings: usb: Add downstream facing ports to realtek binding")

Signed-off-by "Rob Herring (Arm)" <[email protected]>

Reviewed-by Stephen Boyd <[email protected]>

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

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

Signed-off-by Sasha Levin <[email protected]>

---
 Documentation/devicetree/bindings/usb/realtek,rts5411.yaml | 1 +
 1 file changed, 1 insertion(+)

Documentation/devicetree/bindings/usb/realtek,rts5411.yaml +1 -0

index 0874fc21f66fb..6577a61cc0753 100644
@@ -65,6 +65,7 @@ patternProperties:
     description: The hard wired USB devices
     type: object
     $ref: /schemas/usb/usb-device.yaml
+    additionalProperties: true
 
 required:
   - peer-hub

Signature · 1 line

2.43.0

Greg Kroah-Hartman

author maintainer

2024-06-19 13:24 UTC #286 lore raw

PATCH 276/281 usb-storage: alauda: Check whether the media is initialized

In reply to Greg Kroah-Hartman

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

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

From: Shichao Lai <[email protected]>

[ Upstream commit 16637fea001ab3c8df528a8995b3211906165a30 ]

The member "uzonesize" of struct alauda_info will remain 0 if alauda_init_media() fails, potentially causing divide errors in alauda_read_data() and alauda_write_lba().
- Add a member "media_initialized" to struct alauda_info.
- Change a condition in alauda_check_media() to ensure the first initialization.
- Add an error check for the return value of alauda_init_media().

Fixes e80b0fade09e ("[PATCH] USB Storage: add alauda support")

Reported-by xingwei lee <[email protected]>

Reported-by yue sun <[email protected]>

Reviewed-by Alan Stern <[email protected]>

Signed-off-by Shichao Lai <[email protected]>

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

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

Signed-off-by Sasha Levin <[email protected]>

---
 drivers/usb/storage/alauda.c | 9 ++++++---
 1 file changed, 6 insertions(+), 3 deletions(-)

drivers/usb/storage/alauda.c +6 -3

index 115f05a6201a1..40d34cc28344a 100644
@@ -105,6 +105,8 @@ struct alauda_info {
 	unsigned char sense_key;
 	unsigned long sense_asc;	/* additional sense code */
 	unsigned long sense_ascq;	/* additional sense code qualifier */
+
+	bool media_initialized;
 };
 
 #define short_pack(lsb,msb) ( ((u16)(lsb)) | ( ((u16)(msb))<<8 ) )

@@ -476,11 +478,12 @@ static int alauda_check_media(struct us_data *us)
 	}
 
 	/* Check for media change */
-	if (status[0] & 0x08) {
+	if (status[0] & 0x08 || !info->media_initialized) {
 		usb_stor_dbg(us, "Media change detected\n");
 		alauda_free_maps(&MEDIA_INFO(us));
-		alauda_init_media(us);
-
+		rc = alauda_init_media(us);
+		if (rc == USB_STOR_TRANSPORT_GOOD)
+			info->media_initialized = true;
 		info->sense_key = UNIT_ATTENTION;
 		info->sense_asc = 0x28;
 		info->sense_ascq = 0x00;

Signature · 1 line

2.43.0

Greg Kroah-Hartman

author maintainer

2024-06-19 13:25 UTC #287 lore raw

PATCH 277/281 mei: vsc: Fix wrong invocation of ACPI SID method

In reply to Greg Kroah-Hartman

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

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

From: Hans de Goede <[email protected]>

[ Upstream commit af076156ec6d70332f1555754e99d4a3771ec297 ]

When using an initializer for a union only one of the union members must be initialized. The initializer for the acpi_object union variable passed as argument to the SID ACPI method was initializing both the type and the integer members of the union.

Unfortunately rather then complaining about this gcc simply ignores the first initializer and only used the second integer.value = 1 initializer. Leaving type set to 0 which leads to the argument being skipped by acpi acpi_ns_evaluate() resulting in:

ACPI Warning: \_SB.PC00.SPI1.SPFD.CVFD.SID: Insufficient arguments - Caller passed 0, method requires 1 (20240322/nsarguments-232)

Fix this by initializing only the integer struct part of the union and initializing both members of the integer struct.

Signed-off-by Hans de Goede <[email protected]>

Reviewed-by Sakari Ailus <[email protected]>

Fixes 566f5ca97680 ("mei: Add transport driver for IVSC device")

Reviewed-by Wentong Wu <[email protected]>

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

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

Signed-off-by Sasha Levin <[email protected]>

---
 drivers/misc/mei/vsc-fw-loader.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

drivers/misc/mei/vsc-fw-loader.c +1 -1

index ffa4ccd96a104..596a9d695dfc1 100644
@@ -252,7 +252,7 @@ static int vsc_get_sensor_name(struct vsc_fw_loader *fw_loader,
 {
 	struct acpi_buffer buffer = { ACPI_ALLOCATE_BUFFER };
 	union acpi_object obj = {
-		.type = ACPI_TYPE_INTEGER,
+		.integer.type = ACPI_TYPE_INTEGER,
 		.integer.value = 1,
 	};
 	struct acpi_object_list arg_list = {

Signature · 1 line

2.43.0

Greg Kroah-Hartman

author maintainer

2024-06-19 13:24 UTC #288 lore raw

PATCH 278/281 misc: microchip: pci1xxxx: Fix a memory leak in the error handling of gp_aux_bus_probe()

In reply to Greg Kroah-Hartman

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

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

From: Yongzhi Liu <[email protected]>

[ Upstream commit 77427e3d5c353e3dd98c7c0af322f8d9e3131ace ]

There is a memory leak (forget to free allocated buffers) in a memory allocation failure path.

Fix it to jump to the correct error handling code.

Fixes 393fc2f5948f ("misc: microchip: pci1xxxx: load auxiliary bus driver for the PIO function in the multi-function endpoint of pci1xxxx device.")

Signed-off-by Yongzhi Liu <[email protected]>

Reviewed-by Kumaravel Thiagarajan <[email protected]>

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

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

Signed-off-by Sasha Levin <[email protected]>

---
 drivers/misc/mchp_pci1xxxx/mchp_pci1xxxx_gp.c | 6 ++++--
 1 file changed, 4 insertions(+), 2 deletions(-)

drivers/misc/mchp_pci1xxxx/mchp_pci1xxxx_gp.c +4 -2

index de75d89ef53e8..34c9be437432a 100644
@@ -69,8 +69,10 @@ static int gp_aux_bus_probe(struct pci_dev *pdev, const struct pci_device_id *id
 
 	aux_bus->aux_device_wrapper[1] = kzalloc(sizeof(*aux_bus->aux_device_wrapper[1]),
 						 GFP_KERNEL);
-	if (!aux_bus->aux_device_wrapper[1])
-		return -ENOMEM;
+	if (!aux_bus->aux_device_wrapper[1]) {
+		retval =  -ENOMEM;
+		goto err_aux_dev_add_0;
+	}
 
 	retval = ida_alloc(&gp_client_ida, GFP_KERNEL);
 	if (retval < 0)

Signature · 1 line

2.43.0

Greg Kroah-Hartman

author maintainer

2024-06-19 13:24 UTC #289 lore raw

PATCH 279/281 i2c: at91: Fix the functionality flags of the slave-only interface

In reply to Greg Kroah-Hartman

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

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

From: Jean Delvare <[email protected]>

[ Upstream commit d6d5645e5fc1233a7ba950de4a72981c394a2557 ]

When an I2C adapter acts only as a slave, it should not claim to support I2C master capabilities.

Fixes 9d3ca54b550c ("i2c: at91: added slave mode support")

Signed-off-by Jean Delvare <[email protected]>

Cc Juergen Fitschen <[email protected]>

Cc Ludovic Desroches <[email protected]>

Cc Codrin Ciubotariu <[email protected]>

Cc Andi Shyti <[email protected]>

Cc Nicolas Ferre <[email protected]>

Cc Alexandre Belloni <[email protected]>

Cc Claudiu Beznea <[email protected]>

Signed-off-by Andi Shyti <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

---
 drivers/i2c/busses/i2c-at91-slave.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

drivers/i2c/busses/i2c-at91-slave.c +1 -2

index d6eeea5166c04..131a67d9d4a68 100644
@@ -106,8 +106,7 @@ static int at91_unreg_slave(struct i2c_client *slave)
 
 static u32 at91_twi_func(struct i2c_adapter *adapter)
 {
-	return I2C_FUNC_SLAVE | I2C_FUNC_I2C | I2C_FUNC_SMBUS_EMUL
-		| I2C_FUNC_SMBUS_READ_BLOCK_DATA;
+	return I2C_FUNC_SLAVE;
 }
 
 static const struct i2c_algorithm at91_twi_algorithm_slave = {

Signature · 1 line

2.43.0

Greg Kroah-Hartman

author maintainer

2024-06-19 13:24 UTC #290 lore raw

PATCH 280/281 i2c: designware: Fix the functionality flags of the slave-only interface

In reply to Greg Kroah-Hartman

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

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

From: Jean Delvare <[email protected]>

[ Upstream commit cbf3fb5b29e99e3689d63a88c3cddbffa1b8de99 ]

When an I2C adapter acts only as a slave, it should not claim to support I2C master capabilities.

Fixes 5b6d721b266a ("i2c: designware: enable SLAVE in platform module")

Signed-off-by Jean Delvare <[email protected]>

Cc Luis Oliveira <[email protected]>

Cc Jarkko Nikula <[email protected]>

Cc Andy Shevchenko <[email protected]>

Cc Mika Westerberg <[email protected]>

Cc Jan Dabros <[email protected]>

Cc Andi Shyti <[email protected]>

Reviewed-by Andy Shevchenko <[email protected]>

Acked-by Jarkko Nikula <[email protected]>

Tested-by Jarkko Nikula <[email protected]>

Signed-off-by Andi Shyti <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

---
 drivers/i2c/busses/i2c-designware-slave.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

drivers/i2c/busses/i2c-designware-slave.c +1 -1

index 2e079cf20bb5b..78e2c47e3d7da 100644
@@ -220,7 +220,7 @@ static const struct i2c_algorithm i2c_dw_algo = {
 
 void i2c_dw_configure_slave(struct dw_i2c_dev *dev)
 {
-	dev->functionality = I2C_FUNC_SLAVE | DW_IC_DEFAULT_FUNCTIONALITY;
+	dev->functionality = I2C_FUNC_SLAVE;
 
 	dev->slave_cfg = DW_IC_CON_RX_FIFO_FULL_HLD_CTRL |
 			 DW_IC_CON_RESTART_EN | DW_IC_CON_STOP_DET_IFADDRESSED;

Signature · 1 line

2.43.0

Greg Kroah-Hartman

author maintainer

2024-06-19 13:25 UTC #291 lore raw

PATCH 281/281 zap_pid_ns_processes: clear TIF_NOTIFY_SIGNAL along with TIF_SIGPENDING

In reply to Greg Kroah-Hartman

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

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

From: Oleg Nesterov <[email protected]>

[ Upstream commit 7fea700e04bd3f424c2d836e98425782f97b494e ]

kernel_wait4() doesn't sleep and returns -EINTR if there is no eligible child and signal_pending() is true.

That is why zap_pid_ns_processes() clears TIF_SIGPENDING but this is not enough, it should also clear TIF_NOTIFY_SIGNAL to make signal_pending() return false and avoid a busy-wait loop.

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

Fixes 12db8b690010 ("entry: Add support for TIF_NOTIFY_SIGNAL")

Signed-off-by Oleg Nesterov <[email protected]>

Reported-by Rachel Menge <[email protected]>

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

Reviewed-by Boqun Feng <[email protected]>

Tested-by Wei Fu <[email protected]>

Reviewed-by Jens Axboe <[email protected]>

Cc Allen Pais <[email protected]>

Cc Christian Brauner <[email protected]>

Cc Frederic Weisbecker <[email protected]>

Cc Joel Fernandes (Google) <[email protected]>

Cc Joel Granados <[email protected]>

Cc Josh Triplett <[email protected]>

Cc Lai Jiangshan <[email protected]>

Cc Mateusz Guzik <[email protected]>

Cc Mathieu Desnoyers <[email protected]>

Cc Mike Christie <[email protected]>

Cc Neeraj Upadhyay <[email protected]>

Cc Paul E. McKenney <[email protected]>

Cc Steven Rostedt (Google) <[email protected]>

Cc Zqiang <[email protected]>

Cc Thomas Gleixner <[email protected]>

Signed-off-by Andrew Morton <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

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

kernel/pid_namespace.c +1 -0

index 7ade20e952321..415201ca0c7e4 100644
@@ -218,6 +218,7 @@ void zap_pid_ns_processes(struct pid_namespace *pid_ns)
 	 */
 	do {
 		clear_thread_flag(TIF_SIGPENDING);
+		clear_thread_flag(TIF_NOTIFY_SIGNAL);
 		rc = kernel_wait4(-1, NULL, __WALL, NULL);
 	} while (rc != -ECHILD);

Signature · 1 line

2.43.0

Florian Fainelli

Tested-by on the v1 series

2024-06-19 14:51 UTC #292 lore raw

In reply to Greg Kroah-Hartman

Quoted 9 lines · Greg Kroah-Hartman

This is the start of the stable review cycle for the 6.9.6 release. There are 281 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, 21 Jun 2024 12:55:11 +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/v6.x/stable-review/patch-6.9.6-rc1.gz
or in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-6.9.y
and the diffstat can be found below.
thanks,
greg k-h

On ARCH_BRCMSTB using 32-bit and 64-bit ARM kernels, build tested on BMIPS_GENERIC:

Tested-by Florian Fainelli <[email protected]>

Signature · 1 line

Florian

SeongJae Park

maintainer Tested-by on the v1 series

2024-06-19 17:08 UTC #293 lore raw

In reply to Greg Kroah-Hartman

Hello,

Quoted 5 lines · On Wed, 19 Jun 2024 14:52:39 +0200 Greg Kroah-Hartman…

This is the start of the stable review cycle for the 6.9.6 release. There are 281 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, 21 Jun 2024 12:55:11 +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/v6.x/stable-review/patch-6.9.6-rc1.gz
or in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-6.9.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].

Tested-by SeongJae Park <[email protected]>

[1] https://github.com/awslabs/damon-tests/tree/next/corr
[2] 93f303762da5 ("Linux 6.9.6-rc1")

Thanks,
SJ

[...]

---

ok 6 selftests: damon: debugfs_duplicate_context_creation.sh
ok 7 selftests: damon: debugfs_rm_non_contexts.sh
ok 8 selftests: damon: debugfs_target_ids_read_before_terminate_race.sh ok 9 selftests: damon: debugfs_target_ids_pid_leak.sh
ok 10 selftests: damon: sysfs.sh
ok 11 selftests: damon: sysfs_update_removed_scheme_dir.sh
ok 12 selftests: damon: sysfs_update_schemes_tried_regions_hang.py ok 13 selftests: damon: sysfs_update_schemes_tried_regions_wss_estimation.py ok 14 selftests: damon: damos_quota.py
ok 15 selftests: damon: damos_apply_interval.py
ok 16 selftests: damon: reclaim.sh
ok 17 selftests: damon: lru_sort.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_m68k.sh
ok 13 selftests: damon-tests: build_i386_idle_flag.sh
ok 14 selftests: damon-tests: build_i386_highpte.sh
ok 15 selftests: damon-tests: build_nomemcg.sh
[33m
[92mPASS [39m

Jon Hunter

maintainer Tested-by on the v1 series

2024-06-19 19:19 UTC #294 lore raw

In reply to Greg Kroah-Hartman

Quoted 9 lines · Greg Kroah-Hartman

This is the start of the stable review cycle for the 6.9.6 release. There are 281 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, 21 Jun 2024 12:55:11 +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/v6.x/stable-review/patch-6.9.6-rc1.gz
or in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-6.9.y
and the diffstat can be found below.
thanks,
greg k-h

All tests passing for Tegra ...

Test results for stable-v6.9:

    10 builds:	10 pass, 0 fail
    26 boots:	26 pass, 0 fail
    116 tests:	116 pass, 0 fail

Linux version: 6.9.6-rc1-g93f303762da5
Boards tested: tegra124-jetson-tk1, tegra186-p2771-0000,

                tegra194-p2972-0000, tegra194-p3509-0000+p3668-0000,
                tegra20-ventana, tegra210-p2371-2180,
                tegra210-p3450-0000, tegra30-cardhu-a04

Tested-by Jon Hunter <[email protected]>

Jon

Pavel Machek

Tested-by on the v1 series

2024-06-19 20:57 UTC #295 lore raw

In reply to Greg Kroah-Hartman

Hi!

Quoted 4 lines

This is the start of the stable review cycle for the 6.9.6 release. There are 281 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.

CIP testing did not find any problems here:

https://gitlab.com/cip-project/cip-testing/linux-stable-rc-ci/-/tree/linux-6.9.y

6.6 passes our testing, too:

https://gitlab.com/cip-project/cip-testing/linux-stable-rc-ci/-/tree/linux-6.6.y

Tested-by Pavel Machek (CIP) <[email protected]>

Best regards,
Pavel

Signature · 2 lines

DENX Software Engineering GmbH,        Managing Director: Erika Unter
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany

Allen

Tested-by Allen Pais on the v1 series

2024-06-19 21:16 UTC #296 lore raw

In reply to Greg Kroah-Hartman

Quoted 9 lines

This is the start of the stable review cycle for the 6.9.6 release. There are 281 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, 21 Jun 2024 12:55:11 +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/v6.x/stable-review/patch-6.9.6-rc1.gz
or in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-6.9.y
and the diffstat can be found below.
thanks,
greg k-h

Compiled and booted on my x86_64 and ARM64 test systems. No errors or regressions.

Tested-by Allen Pais <[email protected]>

Thanks.

Kelsey Steele

Tested-by on the v1 series

2024-06-20 03:43 UTC #297 lore raw

In reply to Greg Kroah-Hartman

Quoted 8 lines · Greg Kroah-Hartman

This is the start of the stable review cycle for the 6.9.6 release. There are 281 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, 21 Jun 2024 12:55:11 +0000. Anything received after that time might be too late.

No regressions found on WSL (x86 and arm64).

Built, booted, and reviewed dmesg.

Thank you. :)

Tested-by Kelsey Steele <[email protected]>

Bagas Sanjaya

Tested-by on the v1 series

2024-06-20 04:56 UTC #298 lore raw

In reply to Greg Kroah-Hartman

Quoted 5 lines · Greg Kroah-Hartman

This is the start of the stable review cycle for the 6.9.6 release. There are 281 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.

Successfully compiled and installed the kernel on my computer (Acer Aspire E15, Intel Core i3 Haswell). No noticeable regressions.

Tested-by Bagas Sanjaya <[email protected]>

Signature · 1 line

An old man doll... just what I always wanted! - Clara

Peter Schneider

Tested-by on the v1 series

2024-06-20 06:34 UTC #299 lore raw

In reply to Greg Kroah-Hartman

Am 19.06.2024 um 14:52 schrieb Greg Kroah-Hartman:

Quoted 7 lines

This is the start of the stable review cycle for the 6.9.6 release. There are 281 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, 21 Jun 2024 12:55:11 +0000. Anything received after that time might be too late.

Builds, boots and works fine w/o regressions on my 2-socket Ivy Bridge Xeon E5-2697 v2 server.

Tested-by Peter Schneider <[email protected]>

Beste Grüße,
Peter Schneider

Signature · 8 lines

Climb the mountain not to plant your flag, but to embrace the challenge,
enjoy the air and behold the view. Climb it so you can see the world,
not so the world can see you.                    -- David McCullough Jr.

OpenPGP:  0xA3828BD796CCE11A8CADE8866E3A92C92C3FF244
Download: https://www.peters-netzplatz.de/download/pschneider1968_pub.asc
https://keys.mailvelope.com/pks/lookup?op=get&[email protected]
https://keys.mailvelope.com/pks/lookup?op=get&[email protected]

Mark Brown

Tested-by on the v1 series

2024-06-20 11:44 UTC #300 lore raw

In reply to Greg Kroah-Hartman

Quoted 4 lines · Greg Kroah-Hartman

This is the start of the stable review cycle for the 6.9.6 release. There are 281 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.

Tested-by Mark Brown <[email protected]>

Naresh Kamboju

2024-06-20 11:51 UTC #301 lore raw

In reply to Greg Kroah-Hartman

Quoted 10 lines · Greg Kroah-Hartman

This is the start of the stable review cycle for the 6.9.6 release. There are 281 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, 21 Jun 2024 12:55:11 +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/v6.x/stable-review/patch-6.9.6-rc1.gz
or in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-6.9.y
and the diffstat can be found below.
thanks,
greg k-h

There are two major issues on arm64 Juno-r2 on Linux stable-rc 6.9.6-rc1

Reported-by Linux Kernel Functional Testing <[email protected]>

1)
The LTP controllers cgroup_fj_stress test cases causing kernel crash on arm64 Juno-r2 with
compat mode testing with stable-rc 6.9 kernel.

In the recent past I have reported this issues on Linux mainline.

LTP: fork13: kernel panic on rk3399-rock-pi-4 running mainline 6.10.rc3
- https://lore.kernel.org/all/CA+G9fYvKmr84WzTArmfaypKM9+=Aw0uXCtuUKHQKFCNMGJyOgQ@mail.gmail.com/

it goes like this,

  Unable to handle kernel NULL pointer dereference at virtual address
  ...
  Insufficient stack space to handle exception!
  end Kernel panic - not syncing: kernel stack overflow

2)
The LTP controllers cgroup_fj_stress test suite causing kernel oops on arm64 Juno-r2 (with the clang-night build toolchain).

  Unable to handle kernel NULL pointer dereference at virtual address
0000000000000009
  Internal error: Oops: 0000000096000044 [#1] PREEMPT SMP
  pc : xprt_alloc_slot+0x54/0x1c8
  lr : xprt_alloc_slot+0x30/0x1c8

Details of crash log:
1)
Crash log:
-----------
cgroup_fj_stress 1 TINFO: Running: cgroup_fj_stress.sh cpuacct 200 1 none cgroup_fj_stress 1 TINFO: timeout per run is 0h 50m 0s tst_cgroup.c:764: TINFO: Mounted V1 cpuacct CGroup on /scratch/ltp-iiltEE0UOm/cgroup_cpuacct
cgroup_fj_stress 1 TINFO: test starts with cgroup version 1 cgroup_fj_stress 1 TINFO: Creating subgroups ...

[ 1785.477847] Unable to handle kernel NULL pointer dereference at
virtual address 0000000000000070
[ 1785.486682] Mem abort info:
[ 1785.489477]   ESR = 0x0000000096000004
[ 1785.493232]   EC = 0x25: DABT (current EL), IL = 32 bits
[ 1785.498555]   SET = 0, FnV = 0
[ 1785.501613]   EA = 0, S1PTW = 0
[ 1785.504757]   FSC = 0x04: level 0 translation fault
[ 1785.509643] Data abort info:
[ 1785.512526]   ISV = 0, ISS = 0x00000004, ISS2 = 0x00000000
[ 1785.518021]   CM = 0, WnR = 0, TnD = 0, TagAccess = 0
[ 1785.523082]   GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0
..
[ 1786.235715] Unable to handle kernel NULL pointer dereference at
virtual address 0000000000000070
..
[ 1786.286238] Unable to handle kernel NULL pointer dereference at
virtual address 0000000000000070
..
[ 1786.336761] Unable to handle kernel NULL pointer dereference at
virtual address 0000000000000070
[ 1786.345564] Mem abort info:
[ 1786.348359]   ESR = 0x0000000096000004
[ 1786.352112]   EC = 0x25: DABT (current EL), IL = 32 bits
[ 1786.357434]   SET = 0, FnV = 0
[ 1786.360492]   EA = 0, S1PTW = 0
[ 1786.363637]   FSC = 0x04: level 0 translation fault
[ 1786.368523] Data abort info:
[ 1786.371405]   ISV = 0, ISS = 0x00000004, ISS2 = 0x00000000
[ 1786.376900]   CM = 0, WnR = 0, TnD = 0, TagAccess = 0
[ 1786.381960]   GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0
[ 1786.387284] Unable to handle kernel NULL pointer dereference at
virtual address 0000000000000070
[ 1786.387293] Insufficient stack space to handle exception!
[ 1786.387296] ESR: 0x0000000096000047 -- DABT (current EL)
[ 1786.387302] FAR: 0xffff80008399ffe0
[ 1786.387306] Task stack:     [0xffff8000839a0000..0xffff8000839a4000]
[ 1786.387312] IRQ stack:      [0xffff8000837f8000..0xffff8000837fc000]
[ 1786.387319] Overflow stack: [0xffff00097ec95320..0xffff00097ec96320]
[ 1786.387327] CPU: 4 PID: 0 Comm: swapper/4 Not tainted 6.9.6-rc1 #1
[ 1786.387338] Hardware name: ARM Juno development board (r2) (DT)
[ 1786.387344] pstate: a00003c5 (NzCv DAIF -PAN -UAO -TCO -DIT -SSBS BTYPE=--)
[ 1786.387355] pc : _prb_read_valid (kernel/printk/printk_ringbuffer.c:2109)
[ 1786.387374] lr : prb_read_valid (kernel/printk/printk_ringbuffer.c:2183)
[ 1786.387385] sp : ffff80008399ffe0
[ 1786.387390] x29: ffff8000839a0030 x28: ffff000800365f00 x27: ffff800082530008
[ 1786.387407] x26: ffff8000834e33b8 x25: ffff8000839a00b0 x24: 0000000000000001
[ 1786.387423] x23: ffff8000839a00a8 x22: ffff8000830e3e40 x21: 0000000000001e9e
[ 1786.387438] x20: 0000000000000000 x19: ffff8000839a01c8 x18: 0000000000000010
[ 1786.387453] x17: 72646461206c6175 x16: 7472697620746120 x15: 65636e6572656665
[ 1786.387468] x14: 726564207265746e x13: 3037303030303030 x12: 3030303030303030
[ 1786.387483] x11: 2073736572646461 x10: ffff800083151ea0 x9 : ffff80008014273c
[ 1786.387498] x8 : ffff8000839a0120 x7 : 0000000000000000 x6 : 0000000000000e9f
[ 1786.387512] x5 : ffff8000839a00c8 x4 : ffff8000837157c0 x3 : 0000000000000000
[ 1786.387526] x2 : ffff8000839a00b0 x1 : 0000000000000000 x0 : ffff8000830e3f58
[ 1786.387542] Kernel panic - not syncing: kernel stack overflow
[ 1786.387549] SMP: stopping secondary CPUs
[ 1787.510055] SMP: failed to stop secondary CPUs 0,4
[ 1787.510065] Kernel Offset: disabled
[ 1787.510068] CPU features: 0x4,00001061,e0100000,0200421b
[ 1787.510076] Memory Limit: none
[ 1787.680436] ---[ end Kernel panic - not syncing: kernel stack overflow ]---

2) Kernel oops log:
-----------

[ 1094.253182]  __secondary_switched+0xb8/0xc0
[ 1094.258306] Unable to handle kernel NULL pointer dereference at
virtual address 0000000000000009
[ 1094.267132] Mem abort info:
[ 1094.269938]   ESR = 0x0000000096000044
[ 1094.273701]   EC = 0x25: DABT (current EL), IL = 32 bits
[ 1094.279031]   SET = 0, FnV = 0
[ 1094.282097]   EA = 0, S1PTW = 0
[ 1094.285242]   FSC = ranslation fault
[ 1094.290136] Data abort info:
[ 1094.293019]   ISV = 0, ISS = 0x00000044, ISS2 = 0x00000000
[ 1094.298523]   CM = 0, WnR = 1, TnD = 0, TagAccess = 0
[ 1094.303592]   GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0
[ 1094.308921] user pgtable: 4k bit VAs, pgdp=00000008a2a34000
[ 1094.315383] [0000000000000009] pgd=0000000000000000, p4d=0000000000000000
[ 1094.322211] Internal error: Oops: 0000000096000044 [#1] PREEMPT SMP
[ 1094.328489] Modules linked in: btrfs xor xor_neon raid6_pq
zstd_compress libcrc38x hdlcd cec drm_dma_helper onboard_usb_hub
crct10dif_ce drm_kms_helper fuse drm backlight dm_mod ip_tables
x_tables
[ 1094.346744] CPU: 1 PID: 161 Comm: systemd-journal Tainted: G
W          6.9.6-rc1 #1
[ 1094.355112] Hardware name: ARM Juno development board (r2) (DT)
[ 1094.361038] pstate: 20000005 (nzCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)
[ 1094.368013] pc : xprt_alloc_slot+0x54/0x1c8
[ 1094.372208] lr : xprt_alloc_slot+0x30/0x1c8
[ 1094.376398] sp : ffff800082dc37e0
[ 1094.379713] x29: ffff800082dc37e0 x28: ffff8000814d31c8 x27: 0000000000008080
[ 1094.386868] x26: ffff8000825da000 x25: 0000000000000001 x24: 0000000000440100
[ 1094.394022] x23: ffff000821759300 x22: 0000000000002102 x21: ffff00082d39d000
[ 1094.401176] x20: ffff00082201f800 x19: ffff0008225bf400 x18: 0000000000000000
[ 1094.408329] x17: 0000000000000000 x16: 0000000000000800 x15: 8080008000000000
[ 1094.415483] x14: 0000ff0064656873 x13: ffff800082dc0000 x12: 0000000000000022
[ 1094.422636] x11: dead000000000100 x10: 0000000000000001 x9 : 0000000000000000
[ 1094.429790] x8 : ffff00082d39d0c8 x7 : 0000000000000000 x6 : 0000000000000000
[ 1094.436942] x5 : 0000000000000000 x4 : ffff00097ec4c530 x3 : ffff800082dc3790
[ 1094.444096] x2 : ffff000821759300 x1 : 0000000000000000 x0 : ffff800081583770
[ 1094.451249] Call trace:
[ 1094.453694]  xprt_alloc_slot+0x54/0x1c8
[ 1094.457536]  xprt_reserve+0x6c/0xe8
[ 1094.461029]  call_reserve+0x2c/0x40
[ 1094.464522]  __rpc_execute+0x124/0x640
[ 1094.468280]  rpc_execute+0x100/0x280
[ 1094.471862]  rpc_run_task+0x124/0x1e8
[ 1094.475528]  rpc_call_sync+0x58/0xc0
[ 1094.479106]  nfs3_proc_getattr+0x94/0xf8
[ 1094.483037]  __nfs_revalidate_inode+0x13c/0x310
[ 1094.487575]  nfs_access_get_cached+0x23c/0x3b8
[ 1094.492024]  nfs_do_access+0x74/0x2b8
[ 1094.495689]  nfs_permission+0xb8/0x1e0
[ 1094.499441]  inode_permission+0xc4/0x170
[ 1094.503371]  link_path_walk+0x100/0x3e0
[ 1094.507215]  path_lookupat+0x74/0x130
[ 1094.510882]  filename_lookup+0xdc/0x1d8
[ 1094.514724]  user_path_at_empty+0x58/0x108
[ 1094.518828]  do_faccessat+0x178/0x330
[ 1094.522495]  __arm64_sys_faccessat+0x30/0x48
[ 1094.526771]  invoke_syscall+0x4c/0x118
[ 1094.530528]  el0_svc_common+0x8c/0xf0
[ 1094.534197]  do_el0_svc+0x28/0x40
[ 1094.537518]  el0_svc+0x40/0x88
[ 1094.540576]  el0t_64_sync_handler+0x90/0x100
[ 1094.544853]  el0t_64_sync+0x190/0x198
[ 1094.548522] Code: d280200b f2fbd5ab 5280044c d1032115 (f9000549)
[ 1094.554623] ---[ end trace 0000000000000000 ]---
[ 1094.559268] note: systemd-journal[161] exited with preempt_count 1
[ 1115.569495] rcu: INFO: rcu_preempt self-detected stall on CPU

Links:
------
1)
- https://qa-reports.linaro.org/lkft/linux-stable-rc-linux-6.9.y/build/v6.9.5-282-g93f303762da5/testrun/24410131/suite/log-parser-test/test/check-kernel-panic/log
- https://qa-reports.linaro.org/lkft/linux-stable-rc-linux-6.9.y/build/v6.9.5-282-g93f303762da5/testrun/24410131/suite/log-parser-test/test/check-kernel-panic-a44367e5836148d6e94412d6de8ab7a0ca37c18d2bfb6a639947ecd2704ad6b1/details/
- https://tuxapi.tuxsuite.com/v1/groups/linaro/projects/lkft/tests/2i6h1Ah6I8CP7ABUzTl9shfaW60
- https://lkft.validation.linaro.org/scheduler/job/7687060#L23314

2)
- https://qa-reports.linaro.org/lkft/linux-stable-rc-linux-6.9.y/build/v6.9.5-282-g93f303762da5/testrun/24410890/suite/log-parser-test/test/check-kernel-oops/log
- https://qa-reports.linaro.org/lkft/linux-stable-rc-linux-6.9.y/build/v6.9.5-282-g93f303762da5/testrun/24410890/suite/log-parser-test/test/check-kernel-exception-55b962f42ea3dfdcb5c7b6c7ceee184b48ae8d479f430f7b31241f220adcb542/details/
- https://qa-reports.linaro.org/lkft/linux-stable-rc-linux-6.9.y/build/v6.9.5-282-g93f303762da5/testrun/24410890/suite/log-parser-test/tests/
- https://lkft.validation.linaro.org/scheduler/job/7688690#L16336

Build details:
-------
* kernel: 6.9.6-rc1
* git: https://gitlab.com/Linaro/lkft/mirrors/stable/linux-stable-rc
* git branch: linux-6.9.y
* git commit: 93f303762da5a9d9c2c72cac615d4d092ce42b1f
* git describe: v6.9.5-282-g93f303762da5

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

Greg Kroah-Hartman

author maintainer

2024-06-20 12:29 UTC #302 lore raw

Quoted 41 lines · Naresh Kamboju

Quoted 10 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 6.9.6 release. There are 281 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, 21 Jun 2024 12:55:11 +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/v6.x/stable-review/patch-6.9.6-rc1.gz
or in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-6.9.y
and the diffstat can be found below.
thanks,
greg k-h
There are two major issues on arm64 Juno-r2 on Linux stable-rc 6.9.6-rc1
Reported-by Linux Kernel Functional Testing <[email protected]>
1)
The LTP controllers cgroup_fj_stress test cases causing kernel crash on arm64 Juno-r2 with
compat mode testing with stable-rc 6.9 kernel.
In the recent past I have reported this issues on Linux mainline.
LTP: fork13: kernel panic on rk3399-rock-pi-4 running mainline 6.10.rc3
- https://lore.kernel.org/all/CA+G9fYvKmr84WzTArmfaypKM9+=Aw0uXCtuUKHQKFCNMGJyOgQ@mail.gmail.com/
it goes like this,
  Unable to handle kernel NULL pointer dereference at virtual address
  ...
  Insufficient stack space to handle exception!
  end Kernel panic - not syncing: kernel stack overflow

Quoted 8 lines

2)
The LTP controllers cgroup_fj_stress test suite causing kernel oops on arm64 Juno-r2 (with the clang-night build toolchain).
  Unable to handle kernel NULL pointer dereference at virtual address
0000000000000009
  Internal error: Oops: 0000000096000044 [#1] PREEMPT SMP
  pc : xprt_alloc_slot+0x54/0x1c8
  lr : xprt_alloc_slot+0x30/0x1c8

And these are regressions? Any chance to run 'git bisect'?

thanks,

greg k-h

Naresh Kamboju

2024-06-20 13:14 UTC #303 lore raw

Quoted 52 lines · Greg Kroah-Hartman

Quoted 41 lines · Naresh Kamboju
Quoted 10 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 6.9.6 release. There are 281 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, 21 Jun 2024 12:55:11 +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/v6.x/stable-review/patch-6.9.6-rc1.gz
or in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-6.9.y
and the diffstat can be found below.
thanks,
greg k-h
There are two major issues on arm64 Juno-r2 on Linux stable-rc 6.9.6-rc1
Reported-by Linux Kernel Functional Testing <[email protected]>
1)
The LTP controllers cgroup_fj_stress test cases causing kernel crash on arm64 Juno-r2 with
compat mode testing with stable-rc 6.9 kernel.
In the recent past I have reported this issues on Linux mainline.
LTP: fork13: kernel panic on rk3399-rock-pi-4 running mainline 6.10.rc3
- https://lore.kernel.org/all/CA+G9fYvKmr84WzTArmfaypKM9+=Aw0uXCtuUKHQKFCNMGJyOgQ@mail.gmail.com/
it goes like this,
  Unable to handle kernel NULL pointer dereference at virtual address
  ...
  Insufficient stack space to handle exception!
  end Kernel panic - not syncing: kernel stack overflow
Quoted 8 lines
2)
The LTP controllers cgroup_fj_stress test suite causing kernel oops on arm64 Juno-r2 (with the clang-night build toolchain).
  Unable to handle kernel NULL pointer dereference at virtual address
0000000000000009
  Internal error: Oops: 0000000096000044 [#1] PREEMPT SMP
  pc : xprt_alloc_slot+0x54/0x1c8
  lr : xprt_alloc_slot+0x30/0x1c8

Quoted 1 line

And these are regressions? Any chance to run 'git bisect'?

it's difficult to reproduce the first one so we haven't been able to bisect it. It seemd like David and Baolin might have an idea what's causing it.

- Naresh

David Hildenbrand

2024-06-20 13:53 UTC #304 lore raw

Quoted 39 lines · Naresh Kamboju

Quoted 37 lines · Greg Kroah-Hartman
Quoted 35 lines · Naresh Kamboju
Quoted 10 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 6.9.6 release. There are 281 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, 21 Jun 2024 12:55:11 +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/v6.x/stable-review/patch-6.9.6-rc1.gz
or in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-6.9.y
and the diffstat can be found below.
thanks,
greg k-h
There are two major issues on arm64 Juno-r2 on Linux stable-rc 6.9.6-rc1
Reported-by Linux Kernel Functional Testing <[email protected]>
1)
The LTP controllers cgroup_fj_stress test cases causing kernel crash on arm64 Juno-r2 with
compat mode testing with stable-rc 6.9 kernel.
In the recent past I have reported this issues on Linux mainline.
LTP: fork13: kernel panic on rk3399-rock-pi-4 running mainline 6.10.rc3
- https://lore.kernel.org/all/CA+G9fYvKmr84WzTArmfaypKM9+=Aw0uXCtuUKHQKFCNMGJyOgQ@mail.gmail.com/

Quoted 6 lines

it goes like this,

   Unable to handle kernel NULL pointer dereference at virtual address
   ...
   Insufficient stack space to handle exception!
   end Kernel panic - not syncing: kernel stack overflow

How is that related to 6.9.6-rc1? That report is from mainline (6.10.rc3).

Can you share a similar kernel dmesg output from the issue on 6.9.6-rc1?

Signature · 3 lines

Cheers,

David / dhildenb

Naresh Kamboju

2024-06-20 14:03 UTC #305 lore raw

Quoted 48 lines · David Hildenbrand

Quoted 39 lines · Naresh Kamboju
Quoted 37 lines · Greg Kroah-Hartman
Quoted 35 lines · Naresh Kamboju
Quoted 10 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 6.9.6 release. There are 281 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, 21 Jun 2024 12:55:11 +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/v6.x/stable-review/patch-6.9.6-rc1.gz
or in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-6.9.y
and the diffstat can be found below.
thanks,
greg k-h
There are two major issues on arm64 Juno-r2 on Linux stable-rc 6.9.6-rc1
Reported-by Linux Kernel Functional Testing <[email protected]>
1)
The LTP controllers cgroup_fj_stress test cases causing kernel crash on arm64 Juno-r2 with
compat mode testing with stable-rc 6.9 kernel.
In the recent past I have reported this issues on Linux mainline.
LTP: fork13: kernel panic on rk3399-rock-pi-4 running mainline 6.10.rc3
- https://lore.kernel.org/all/CA+G9fYvKmr84WzTArmfaypKM9+=Aw0uXCtuUKHQKFCNMGJyOgQ@mail.gmail.com/
Quoted 6 lines
Quoted 6 lines
Quoted 6 lines
it goes like this,
   Unable to handle kernel NULL pointer dereference at virtual address
   ...
   Insufficient stack space to handle exception!
   end Kernel panic - not syncing: kernel stack overflow

Quoted 3 lines

How is that related to 6.9.6-rc1? That report is from mainline (6.10.rc3).
Can you share a similar kernel dmesg output from the issue on 6.9.6-rc1?

I request you to use this link for detailed boot log, test log and crash log.
- https://lkft.validation.linaro.org/scheduler/job/7687060#L23314

Few more logs related to build artifacts links provided in the original email thread and bottom of this email.

crash log:
---

[ 0.000000] Booting Linux on physical CPU 0x0000000100 [0x410fd033]
[ 0.000000] Linux version 6.9.6-rc1 (tuxmake@tuxmake)
(aarch64-linux-gnu-gcc (Debian 13.2.0-12) 13.2.0, GNU ld (GNU Binutils
for Debian) 2.42) #1 SMP PREEMPT @1718817000
...
[ 1786.336761] Unable to handle kernel NULL pointer dereference at
virtual address 0000000000000070
[ 1786.345564] Mem abort info:
[ 1786.348359]   ESR = 0x0000000096000004
[ 1786.352112]   EC = 0x25: DABT (current EL), IL = 32 bits
[ 1786.357434]   SET = 0, FnV = 0
[ 1786.360492]   EA = 0, S1PTW = 0
[ 1786.363637]   FSC = 0x04: level 0 translation fault
[ 1786.368523] Data abort info:
[ 1786.371405]   ISV = 0, ISS = 0x00000004, ISS2 = 0x00000000
[ 1786.376900]   CM = 0, WnR = 0, TnD = 0, TagAccess = 0
[ 1786.381960]   GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0
[ 1786.387284] Unable to handle kernel NULL pointer dereference at
virtual address 0000000000000070
[ 1786.387293] Insufficient stack space to handle exception!
[ 1786.387296] ESR: 0x0000000096000047 -- DABT (current EL)
[ 1786.387302] FAR: 0xffff80008399ffe0
[ 1786.387306] Task stack:     [0xffff8000839a0000..0xffff8000839a4000]
[ 1786.387312] IRQ stack:      [0xffff8000837f8000..0xffff8000837fc000]
[ 1786.387319] Overflow stack: [0xffff00097ec95320..0xffff00097ec96320]
[ 1786.387327] CPU: 4 PID: 0 Comm: swapper/4 Not tainted 6.9.6-rc1 #1
[ 1786.387338] Hardware name: ARM Juno development board (r2) (DT)
[ 1786.387344] pstate: a00003c5 (NzCv DAIF -PAN -UAO -TCO -DIT -SSBS BTYPE=--)
[ 1786.387355] pc : _prb_read_valid (kernel/printk/printk_ringbuffer.c:2109)
[ 1786.387374] lr : prb_read_valid (kernel/printk/printk_ringbuffer.c:2183)
[ 1786.387385] sp : ffff80008399ffe0
[ 1786.387390] x29: ffff8000839a0030 x28: ffff000800365f00 x27: ffff800082530008
[ 1786.387407] x26: ffff8000834e33b8 x25: ffff8000839a00b0 x24: 0000000000000001
[ 1786.387423] x23: ffff8000839a00a8 x22: ffff8000830e3e40 x21: 0000000000001e9e
[ 1786.387438] x20: 0000000000000000 x19: ffff8000839a01c8 x18: 0000000000000010
[ 1786.387453] x17: 72646461206c6175 x16: 7472697620746120 x15: 65636e6572656665
[ 1786.387468] x14: 726564207265746e x13: 3037303030303030 x12: 3030303030303030
[ 1786.387483] x11: 2073736572646461 x10: ffff800083151ea0 x9 : ffff80008014273c
[ 1786.387498] x8 : ffff8000839a0120 x7 : 0000000000000000 x6 : 0000000000000e9f
[ 1786.387512] x5 : ffff8000839a00c8 x4 : ffff8000837157c0 x3 : 0000000000000000
[ 1786.387526] x2 : ffff8000839a00b0 x1 : 0000000000000000 x0 : ffff8000830e3f58
[ 1786.387542] Kernel panic - not syncing: kernel stack overflow
[ 1786.387549] SMP: stopping secondary CPUs
[ 1787.510055] SMP: failed to stop secondary CPUs 0,4
[ 1787.510065] Kernel Offset: disabled
[ 1787.510068] CPU features: 0x4,00001061,e0100000,0200421b
[ 1787.510076] Memory Limit: none
[ 1787.680436] ---[ end Kernel panic - not syncing: kernel stack overflow ]---

1)
- https://qa-reports.linaro.org/lkft/linux-stable-rc-linux-6.9.y/build/v6.9.5-282-g93f303762da5/testrun/24410131/suite/log-parser-test/test/check-kernel-panic/log
- https://qa-reports.linaro.org/lkft/linux-stable-rc-linux-6.9.y/build/v6.9.5-282-g93f303762da5/testrun/24410131/suite/log-parser-test/test/check-kernel-panic-a44367e5836148d6e94412d6de8ab7a0ca37c18d2bfb6a639947ecd2704ad6b1/details/
- https://tuxapi.tuxsuite.com/v1/groups/linaro/projects/lkft/tests/2i6h1Ah6I8CP7ABUzTl9shfaW60
- https://lkft.validation.linaro.org/scheduler/job/7687060#L23314

- Naresh

Quoted 6 lines

--
Cheers,
David / dhildenb

David Hildenbrand

2024-06-20 14:20 UTC #306 lore raw

Quoted 53 lines · Naresh Kamboju

Quoted 48 lines · David Hildenbrand
Quoted 39 lines · Naresh Kamboju
Quoted 37 lines · Greg Kroah-Hartman
Quoted 35 lines · Naresh Kamboju
Quoted 10 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 6.9.6 release. There are 281 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, 21 Jun 2024 12:55:11 +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/v6.x/stable-review/patch-6.9.6-rc1.gz
or in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-6.9.y
and the diffstat can be found below.
thanks,
greg k-h
There are two major issues on arm64 Juno-r2 on Linux stable-rc 6.9.6-rc1
Reported-by Linux Kernel Functional Testing <[email protected]>
1)
The LTP controllers cgroup_fj_stress test cases causing kernel crash on arm64 Juno-r2 with
compat mode testing with stable-rc 6.9 kernel.
In the recent past I have reported this issues on Linux mainline.
LTP: fork13: kernel panic on rk3399-rock-pi-4 running mainline 6.10.rc3
- https://lore.kernel.org/all/CA+G9fYvKmr84WzTArmfaypKM9+=Aw0uXCtuUKHQKFCNMGJyOgQ@mail.gmail.com/
Quoted 6 lines
Quoted 6 lines
Quoted 6 lines
it goes like this,
    Unable to handle kernel NULL pointer dereference at virtual address
    ...
    Insufficient stack space to handle exception!
    end Kernel panic - not syncing: kernel stack overflow
Quoted 3 lines
How is that related to 6.9.6-rc1? That report is from mainline (6.10.rc3).
Can you share a similar kernel dmesg output from the issue on 6.9.6-rc1?

Quoted 9 lines

I request you to use this link for detailed boot log, test log and crash log.
- https://lkft.validation.linaro.org/scheduler/job/7687060#L23314
Few more logs related to build artifacts links provided in the original email thread and bottom of this email.
crash log:
---

Thanks, so this is something different than the

"BUG: Bad page map in process fork13

 BUG: Bad rss-counter state mm:"

stuff on mainline you referenced.

Looks like some recursive exception until we exhausted the stack.

Trying to connect the dots here, can you enlighten me how this is related to the fork13 mainline report?

Quoted 48 lines

[ 0.000000] Booting Linux on physical CPU 0x0000000100 [0x410fd033]
[ 0.000000] Linux version 6.9.6-rc1 (tuxmake@tuxmake)
(aarch64-linux-gnu-gcc (Debian 13.2.0-12) 13.2.0, GNU ld (GNU Binutils
for Debian) 2.42) #1 SMP PREEMPT @1718817000
...
[ 1786.336761] Unable to handle kernel NULL pointer dereference at
virtual address 0000000000000070
[ 1786.345564] Mem abort info:
[ 1786.348359]   ESR = 0x0000000096000004
[ 1786.352112]   EC = 0x25: DABT (current EL), IL = 32 bits
[ 1786.357434]   SET = 0, FnV = 0
[ 1786.360492]   EA = 0, S1PTW = 0
[ 1786.363637]   FSC = 0x04: level 0 translation fault
[ 1786.368523] Data abort info:
[ 1786.371405]   ISV = 0, ISS = 0x00000004, ISS2 = 0x00000000
[ 1786.376900]   CM = 0, WnR = 0, TnD = 0, TagAccess = 0
[ 1786.381960]   GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0
[ 1786.387284] Unable to handle kernel NULL pointer dereference at
virtual address 0000000000000070
[ 1786.387293] Insufficient stack space to handle exception!
[ 1786.387296] ESR: 0x0000000096000047 -- DABT (current EL)
[ 1786.387302] FAR: 0xffff80008399ffe0
[ 1786.387306] Task stack:     [0xffff8000839a0000..0xffff8000839a4000]
[ 1786.387312] IRQ stack:      [0xffff8000837f8000..0xffff8000837fc000]
[ 1786.387319] Overflow stack: [0xffff00097ec95320..0xffff00097ec96320]
[ 1786.387327] CPU: 4 PID: 0 Comm: swapper/4 Not tainted 6.9.6-rc1 #1
[ 1786.387338] Hardware name: ARM Juno development board (r2) (DT)
[ 1786.387344] pstate: a00003c5 (NzCv DAIF -PAN -UAO -TCO -DIT -SSBS BTYPE=--)
[ 1786.387355] pc : _prb_read_valid (kernel/printk/printk_ringbuffer.c:2109)
[ 1786.387374] lr : prb_read_valid (kernel/printk/printk_ringbuffer.c:2183)
[ 1786.387385] sp : ffff80008399ffe0
[ 1786.387390] x29: ffff8000839a0030 x28: ffff000800365f00 x27: ffff800082530008
[ 1786.387407] x26: ffff8000834e33b8 x25: ffff8000839a00b0 x24: 0000000000000001
[ 1786.387423] x23: ffff8000839a00a8 x22: ffff8000830e3e40 x21: 0000000000001e9e
[ 1786.387438] x20: 0000000000000000 x19: ffff8000839a01c8 x18: 0000000000000010
[ 1786.387453] x17: 72646461206c6175 x16: 7472697620746120 x15: 65636e6572656665
[ 1786.387468] x14: 726564207265746e x13: 3037303030303030 x12: 3030303030303030
[ 1786.387483] x11: 2073736572646461 x10: ffff800083151ea0 x9 : ffff80008014273c
[ 1786.387498] x8 : ffff8000839a0120 x7 : 0000000000000000 x6 : 0000000000000e9f
[ 1786.387512] x5 : ffff8000839a00c8 x4 : ffff8000837157c0 x3 : 0000000000000000
[ 1786.387526] x2 : ffff8000839a00b0 x1 : 0000000000000000 x0 : ffff8000830e3f58
[ 1786.387542] Kernel panic - not syncing: kernel stack overflow
[ 1786.387549] SMP: stopping secondary CPUs
[ 1787.510055] SMP: failed to stop secondary CPUs 0,4
[ 1787.510065] Kernel Offset: disabled
[ 1787.510068] CPU features: 0x4,00001061,e0100000,0200421b
[ 1787.510076] Memory Limit: none
[ 1787.680436] ---[ end Kernel panic - not syncing: kernel stack overflow ]---

Signature · 3 lines

Cheers,

David / dhildenb

Naresh Kamboju

2024-06-20 15:39 UTC #307 lore raw

Quoted 58 lines · David Hildenbrand

Quoted 56 lines · Naresh Kamboju
Quoted 48 lines · David Hildenbrand
Quoted 39 lines · Naresh Kamboju
Quoted 37 lines · Greg Kroah-Hartman
Quoted 35 lines · Naresh Kamboju
Quoted 10 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 6.9.6 release. There are 281 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, 21 Jun 2024 12:55:11 +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/v6.x/stable-review/patch-6.9.6-rc1.gz
or in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-6.9.y
and the diffstat can be found below.
thanks,
greg k-h
There are two major issues on arm64 Juno-r2 on Linux stable-rc 6.9.6-rc1
Reported-by Linux Kernel Functional Testing <[email protected]>
1)
The LTP controllers cgroup_fj_stress test cases causing kernel crash on arm64 Juno-r2 with
compat mode testing with stable-rc 6.9 kernel.
In the recent past I have reported this issues on Linux mainline.
LTP: fork13: kernel panic on rk3399-rock-pi-4 running mainline 6.10.rc3
- https://lore.kernel.org/all/CA+G9fYvKmr84WzTArmfaypKM9+=Aw0uXCtuUKHQKFCNMGJyOgQ@mail.gmail.com/
Quoted 6 lines
Quoted 6 lines
Quoted 6 lines
it goes like this,
    Unable to handle kernel NULL pointer dereference at virtual address
    ...
    Insufficient stack space to handle exception!
    end Kernel panic - not syncing: kernel stack overflow
Quoted 3 lines
How is that related to 6.9.6-rc1? That report is from mainline (6.10.rc3).
Can you share a similar kernel dmesg output from the issue on 6.9.6-rc1?
I request you to use this link for detailed boot log, test log and crash log.
- https://lkft.validation.linaro.org/scheduler/job/7687060#L23314

Quoted 6 lines

Quoted 6 lines
Few more logs related to build artifacts links provided in the original email thread and bottom of this email.
crash log:
---

Thanks for investigating this crash report.

Quoted 8 lines

Thanks, so this is something different than the
"BUG: Bad page map in process fork13
  BUG: Bad rss-counter state mm:"
stuff on mainline you referenced.
Looks like some recursive exception until we exhausted the stack.

You are right !
I see only one common case is, exhaust the stack.

Quoted 4 lines

Trying to connect the dots here, can you enlighten me how this is related to the fork13 mainline report?

I am not sure about the relation between these two reports. But as a common practice I have shared that report information.

Quoted 50 lines

Quoted 40 lines

[ 0.000000] Booting Linux on physical CPU 0x0000000100 [0x410fd033]
[ 0.000000] Linux version 6.9.6-rc1 (tuxmake@tuxmake)
(aarch64-linux-gnu-gcc (Debian 13.2.0-12) 13.2.0, GNU ld (GNU Binutils
for Debian) 2.42) #1 SMP PREEMPT @1718817000
...
[ 1786.336761] Unable to handle kernel NULL pointer dereference at
virtual address 0000000000000070
[ 1786.345564] Mem abort info:
[ 1786.348359]   ESR = 0x0000000096000004
[ 1786.352112]   EC = 0x25: DABT (current EL), IL = 32 bits
[ 1786.357434]   SET = 0, FnV = 0
[ 1786.360492]   EA = 0, S1PTW = 0
[ 1786.363637]   FSC = 0x04: level 0 translation fault
[ 1786.368523] Data abort info:
[ 1786.371405]   ISV = 0, ISS = 0x00000004, ISS2 = 0x00000000
[ 1786.376900]   CM = 0, WnR = 0, TnD = 0, TagAccess = 0
[ 1786.381960]   GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0
[ 1786.387284] Unable to handle kernel NULL pointer dereference at
virtual address 0000000000000070
[ 1786.387293] Insufficient stack space to handle exception!
[ 1786.387296] ESR: 0x0000000096000047 -- DABT (current EL)
[ 1786.387302] FAR: 0xffff80008399ffe0
[ 1786.387306] Task stack:     [0xffff8000839a0000..0xffff8000839a4000]
[ 1786.387312] IRQ stack:      [0xffff8000837f8000..0xffff8000837fc000]
[ 1786.387319] Overflow stack: [0xffff00097ec95320..0xffff00097ec96320]
[ 1786.387327] CPU: 4 PID: 0 Comm: swapper/4 Not tainted 6.9.6-rc1 #1
[ 1786.387338] Hardware name: ARM Juno development board (r2) (DT)
[ 1786.387344] pstate: a00003c5 (NzCv DAIF -PAN -UAO -TCO -DIT -SSBS BTYPE=--)
[ 1786.387355] pc : _prb_read_valid (kernel/printk/printk_ringbuffer.c:2109)
[ 1786.387374] lr : prb_read_valid (kernel/printk/printk_ringbuffer.c:2183)
[ 1786.387385] sp : ffff80008399ffe0
[ 1786.387390] x29: ffff8000839a0030 x28: ffff000800365f00 x27: ffff800082530008
[ 1786.387407] x26: ffff8000834e33b8 x25: ffff8000839a00b0 x24: 0000000000000001
[ 1786.387423] x23: ffff8000839a00a8 x22: ffff8000830e3e40 x21: 0000000000001e9e
[ 1786.387438] x20: 0000000000000000 x19: ffff8000839a01c8 x18: 0000000000000010
[ 1786.387453] x17: 72646461206c6175 x16: 7472697620746120 x15: 65636e6572656665
[ 1786.387468] x14: 726564207265746e x13: 3037303030303030 x12: 3030303030303030
[ 1786.387483] x11: 2073736572646461 x10: ffff800083151ea0 x9 : ffff80008014273c
[ 1786.387498] x8 : ffff8000839a0120 x7 : 0000000000000000 x6 : 0000000000000e9f
[ 1786.387512] x5 : ffff8000839a00c8 x4 : ffff8000837157c0 x3 : 0000000000000000

Quoted 8 lines

[ 1786.387526] x2 : ffff8000839a00b0 x1 : 0000000000000000 x0 : ffff8000830e3f58
[ 1786.387542] Kernel panic - not syncing: kernel stack overflow
[ 1786.387549] SMP: stopping secondary CPUs
[ 1787.510055] SMP: failed to stop secondary CPUs 0,4
[ 1787.510065] Kernel Offset: disabled
[ 1787.510068] CPU features: 0x4,00001061,e0100000,0200421b
[ 1787.510076] Memory Limit: none
[ 1787.680436] ---[ end Kernel panic - not syncing: kernel stack overflow ]---

Quoted 4 lines

--
Cheers,
David / dhildenb

- Naresh

David Hildenbrand

2024-06-20 19:31 UTC #308 lore raw

Quoted 7 lines

Quoted 4 lines
Quoted 2 lines
Quoted 2 lines
Trying to connect the dots here, can you enlighten me how this is related to the fork13 mainline report?
I am not sure about the relation between these two reports. But as a common practice I have shared that report information.

Yes, I was just briefly concerned that we are seeing the same issue as we saw once on 6.10-rc3 also on a 6.9 kernel -- also because the patch list don't contain that much MM stuff.

Signature · 3 lines

Cheers,

David / dhildenb

Ron Economos

Tested-by on the v1 series

2024-06-20 14:18 UTC #309 lore raw

In reply to Greg Kroah-Hartman

Quoted 9 lines · Greg Kroah-Hartman

This is the start of the stable review cycle for the 6.9.6 release. There are 281 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, 21 Jun 2024 12:55:11 +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/v6.x/stable-review/patch-6.9.6-rc1.gz
or in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-6.9.y
and the diffstat can be found below.
thanks,
greg k-h

Built and booted successfully on RISC-V RV64 (HiFive Unmatched).

Tested-by Ron Economos <[email protected]>

Shuah Khan

Tested-by on the v1 series

2024-06-20 21:34 UTC #310 lore raw

In reply to Greg Kroah-Hartman

Quoted 9 lines · Greg Kroah-Hartman

This is the start of the stable review cycle for the 6.9.6 release. There are 281 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, 21 Jun 2024 12:55:11 +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/v6.x/stable-review/patch-6.9.6-rc1.gz
or in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-6.9.y
and the diffstat can be found below.
thanks,
greg k-h

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

Tested-by Shuah Khan <[email protected]>

thanks,
-- Shuah