Skip to contentSkip to conversation

6.6.55-rc1 review

PATCH In review Greg Kroah-Hartman 16 participants 408 messages Oct 8, 2024 – Oct 11, 2024 Page 4 of 4

Subsystems (2)
lore
Share & tools
lore
author maintainer
#387 lore raw

PATCH 380/386 vhost/scsi: null-ptr-dereference in vhost_scsi_get_req()

In reply to Greg Kroah-Hartman

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

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

From: Haoran Zhang <[email protected]>

commit 221af82f606d928ccef19a16d35633c63026f1be upstream.

Since commit 3f8ca2e115e5 ("vhost/scsi: Extract common handling code from control queue handler") a null pointer dereference bug can be triggered when guest sends an SCSI AN request.

In vhost_scsi_ctl_handle_vq(), vc.target is assigned with &v_req.tmf.lun[1] within a switch-case block and is then passed to vhost_scsi_get_req() which extracts vc->req and tpg. However, for a VIRTIO_SCSI_T_AN_* request, tpg is not required, so vc.target is set to NULL in this branch. Later, in vhost_scsi_get_req(), vc->target is dereferenced without being checked, leading to a null pointer dereference bug. This bug can be triggered from guest.

When this bug occurs, the vhost_worker process is killed while holding vq->mutex and the corresponding tpg will remain occupied indefinitely.

Below is the KASAN report:

Oops: general protection fault, probably for non-canonical address
0xdffffc0000000000: 0000 [#1] PREEMPT SMP KASAN NOPTI
KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007]
CPU: 1 PID: 840 Comm: poc Not tainted 6.10.0+ #1
Hardware name: QEMU Ubuntu 24.04 PC (i440FX + PIIX, 1996), BIOS
1.16.3-debian-1.16.3-2 04/01/2014
RIP: 0010:vhost_scsi_get_req+0x165/0x3a0
Code: 00 fc ff df 48 89 fa 48 c1 ea 03 80 3c 02 00 0f 85 2b 02 00 00
48 b8 00 00 00 00 00 fc ff df 4d 8b 65 30 4c 89 e2 48 c1 ea 03 <0f> b6
04 02 4c 89 e2 83 e2 07 38 d0 7f 08 84 c0 0f 85 be 01 00 00
RSP: 0018:ffff888017affb50 EFLAGS: 00010246
RAX: dffffc0000000000 RBX: ffff88801b000000 RCX: 0000000000000000
RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffff888017affcb8
RBP: ffff888017affb80 R08: 0000000000000000 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000000000
R13: ffff888017affc88 R14: ffff888017affd1c R15: ffff888017993000
FS:  000055556e076500(0000) GS:ffff88806b100000(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00000000200027c0 CR3: 0000000010ed0004 CR4: 0000000000370ef0
Call Trace:
 <TASK>
 ? show_regs+0x86/0xa0
 ? die_addr+0x4b/0xd0
 ? exc_general_protection+0x163/0x260
 ? asm_exc_general_protection+0x27/0x30
 ? vhost_scsi_get_req+0x165/0x3a0
 vhost_scsi_ctl_handle_vq+0x2a4/0xca0
 ? __pfx_vhost_scsi_ctl_handle_vq+0x10/0x10
 ? __switch_to+0x721/0xeb0
 ? __schedule+0xda5/0x5710
 ? __kasan_check_write+0x14/0x30
 ? _raw_spin_lock+0x82/0xf0
 vhost_scsi_ctl_handle_kick+0x52/0x90
 vhost_run_work_list+0x134/0x1b0
 vhost_task_fn+0x121/0x350
...
 </TASK>
---[ end trace 0000000000000000 ]---

Let's add a check in vhost_scsi_get_req.

Fixes 3f8ca2e115e5 ("vhost/scsi: Extract common handling code from control queue handler")
[whitespace fixes]

Message-Id: <[email protected]>

---
 drivers/vhost/scsi.c |   25 ++++++++++++++-----------
 1 file changed, 14 insertions(+), 11 deletions(-)
drivers/vhost/scsi.c +14 -11
@@ -1018,20 +1018,23 @@ vhost_scsi_get_req(struct vhost_virtqueu
 		/* virtio-scsi spec requires byte 0 of the lun to be 1 */
 		vq_err(vq, "Illegal virtio-scsi lun: %u\n", *vc->lunp);
 	} else {
-		struct vhost_scsi_tpg **vs_tpg, *tpg;
+		struct vhost_scsi_tpg **vs_tpg, *tpg = NULL;
 
-		vs_tpg = vhost_vq_get_backend(vq);	/* validated at handler entry */
-
-		tpg = READ_ONCE(vs_tpg[*vc->target]);
-		if (unlikely(!tpg)) {
-			vq_err(vq, "Target 0x%x does not exist\n", *vc->target);
-		} else {
-			if (tpgp)
-				*tpgp = tpg;
-			ret = 0;
+		if (vc->target) {
+			/* validated at handler entry */
+			vs_tpg = vhost_vq_get_backend(vq);
+			tpg = READ_ONCE(vs_tpg[*vc->target]);
+			if (unlikely(!tpg)) {
+				vq_err(vq, "Target 0x%x does not exist\n", *vc->target);
+				goto out;
+			}
 		}
-	}
 
+		if (tpgp)
+			*tpgp = tpg;
+		ret = 0;
+	}
+out:
 	return ret;
 }
 
author maintainer
#388 lore raw

PATCH 381/386 crypto: octeontx* - Select CRYPTO_AUTHENC

In reply to Greg Kroah-Hartman

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

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

From: Herbert Xu <[email protected]>

commit c398cb8eb0a263a1b7a18892d9f244751689675c upstream.

Select CRYPTO_AUTHENC as the function crypto_authenec_extractkeys may not be available without it.

Fixes 311eea7e37c4 ("crypto: octeontx - Fix authenc setkey")
Fixes 7ccb750dcac8 ("crypto: octeontx2 - Fix authenc setkey")
---
 drivers/crypto/marvell/Kconfig | 2 ++
 1 file changed, 2 insertions(+)
drivers/crypto/marvell/Kconfig +2 -0
index a48591af12d0..78217577aa54 100644
@@ -28,6 +28,7 @@ config CRYPTO_DEV_OCTEONTX_CPT
 	select CRYPTO_SKCIPHER
 	select CRYPTO_HASH
 	select CRYPTO_AEAD
+	select CRYPTO_AUTHENC
 	select CRYPTO_DEV_MARVELL
 	help
 		This driver allows you to utilize the Marvell Cryptographic
@@ -47,6 +48,7 @@ config CRYPTO_DEV_OCTEONTX2_CPT
 	select CRYPTO_SKCIPHER
 	select CRYPTO_HASH
 	select CRYPTO_AEAD
+	select CRYPTO_AUTHENC
 	select NET_DEVLINK
 	help
 		This driver allows you to utilize the Marvell Cryptographic
Signature · 1 line
2.46.2
author maintainer
#389 lore raw

PATCH 382/386 drm/amd/display: Revert Avoid overflow assignment

In reply to Greg Kroah-Hartman

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

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

From: Gabe Teeger <[email protected]>

commit e80f8f491df873ea2e07c941c747831234814612 upstream.

This reverts commit a15268787b79 ("drm/amd/display: Avoid overflow assignment in link_dp_cts") Due to regression causing DPMS hang.

---
 drivers/gpu/drm/amd/display/dc/dc_dp_types.h                  |    2 +-
 drivers/gpu/drm/amd/display/dc/link/accessories/link_dp_cts.c |    3 +--
 drivers/gpu/drm/amd/display/include/dpcd_defs.h               |    1 -
 3 files changed, 2 insertions(+), 4 deletions(-)
drivers/gpu/drm/amd/display/dc/dc_dp_types.h +1 -1
@@ -721,7 +721,7 @@ struct dp_audio_test_data_flags {
 struct dp_audio_test_data {
 
 	struct dp_audio_test_data_flags flags;
-	uint32_t sampling_rate;
+	uint8_t sampling_rate;
 	uint8_t channel_count;
 	uint8_t pattern_type;
 	uint8_t pattern_period[8];
drivers/gpu/drm/amd/display/dc/link/accessories/link_dp_cts.c +1 -2
@@ -849,8 +849,7 @@ bool dp_set_test_pattern(
 			core_link_read_dpcd(link, DP_TRAINING_PATTERN_SET,
 					    &training_pattern.raw,
 					    sizeof(training_pattern));
-			if (pattern <= PHY_TEST_PATTERN_END_DP11)
-				training_pattern.v1_3.LINK_QUAL_PATTERN_SET = pattern;
+			training_pattern.v1_3.LINK_QUAL_PATTERN_SET = pattern;
 			core_link_write_dpcd(link, DP_TRAINING_PATTERN_SET,
 					     &training_pattern.raw,
 					     sizeof(training_pattern));
drivers/gpu/drm/amd/display/include/dpcd_defs.h +0 -1
@@ -76,7 +76,6 @@ enum dpcd_phy_test_patterns {
 	PHY_TEST_PATTERN_D10_2,
 	PHY_TEST_PATTERN_SYMBOL_ERROR,
 	PHY_TEST_PATTERN_PRBS7,
-	PHY_TEST_PATTERN_END_DP11 = PHY_TEST_PATTERN_PRBS7,
 	PHY_TEST_PATTERN_80BIT_CUSTOM,/* For DP1.2 only */
 	PHY_TEST_PATTERN_CP2520_1,
 	PHY_TEST_PATTERN_CP2520_2,
author maintainer
#390 lore raw

PATCH 383/386 perf report: Fix segfault when sym sort key is not used

In reply to Greg Kroah-Hartman

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

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

From: Namhyung Kim <[email protected]>

commit 9af2efee41b27a0f386fb5aa95d8d0b4b5d9fede upstream.

The fields in the hist_entry are filled on-demand which means they only have meaningful values when relevant sort keys are used.

So if neither of 'dso' nor 'sym' sort keys are used, the map/symbols in the hist entry can be garbage. So it shouldn't access it unconditionally.

I got a segfault, when I wanted to see cgroup profiles.

  $ sudo perf record -a --all-cgroups --synth=cgroup true
  $ sudo perf report -s cgroup

Program received signal SIGSEGV, Segmentation fault. 0x00005555557a8d90 in map__dso (map=0x0) at util/map.h:48
48 return RC_CHK_ACCESS(map)->dso;
(gdb) bt

  #0  0x00005555557a8d90 in map__dso (map=0x0) at util/map.h:48
  #1  0x00005555557aa39b in map__load (map=0x0) at util/map.c:344
  #2  0x00005555557aa592 in map__find_symbol (map=0x0, addr=140736115941088) at util/map.c:385
  #3  0x00005555557ef000 in hists__findnew_entry (hists=0x555556039d60, entry=0x7fffffffa4c0, al=0x7fffffffa8c0, sample_self=true)
      at util/hist.c:644
  #4  0x00005555557ef61c in __hists__add_entry (hists=0x555556039d60, al=0x7fffffffa8c0, sym_parent=0x0, bi=0x0, mi=0x0, ki=0x0,
      block_info=0x0, sample=0x7fffffffaa90, sample_self=true, ops=0x0) at util/hist.c:761
  #5  0x00005555557ef71f in hists__add_entry (hists=0x555556039d60, al=0x7fffffffa8c0, sym_parent=0x0, bi=0x0, mi=0x0, ki=0x0,
      sample=0x7fffffffaa90, sample_self=true) at util/hist.c:779
  #6  0x00005555557f00fb in iter_add_single_normal_entry (iter=0x7fffffffa900, al=0x7fffffffa8c0) at util/hist.c:1015
  #7  0x00005555557f09a7 in hist_entry_iter__add (iter=0x7fffffffa900, al=0x7fffffffa8c0, max_stack_depth=127, arg=0x7fffffffbce0)
      at util/hist.c:1260
  #8  0x00005555555ba7ce in process_sample_event (tool=0x7fffffffbce0, event=0x7ffff7c14128, sample=0x7fffffffaa90, evsel=0x555556039ad0,
      machine=0x5555560388e8) at builtin-report.c:334
  #9  0x00005555557b30c8 in evlist__deliver_sample (evlist=0x555556039010, tool=0x7fffffffbce0, event=0x7ffff7c14128,
      sample=0x7fffffffaa90, evsel=0x555556039ad0, machine=0x5555560388e8) at util/session.c:1232
  #10 0x00005555557b32bc in machines__deliver_event (machines=0x5555560388e8, evlist=0x555556039010, event=0x7ffff7c14128,
      sample=0x7fffffffaa90, tool=0x7fffffffbce0, file_offset=110888, file_path=0x555556038ff0 "perf.data") at util/session.c:1271
  #11 0x00005555557b3848 in perf_session__deliver_event (session=0x5555560386d0, event=0x7ffff7c14128, tool=0x7fffffffbce0,
      file_offset=110888, file_path=0x555556038ff0 "perf.data") at util/session.c:1354
  #12 0x00005555557affaf in ordered_events__deliver_event (oe=0x555556038e60, event=0x555556135aa0) at util/session.c:132
  #13 0x00005555557bb605 in do_flush (oe=0x555556038e60, show_progress=false) at util/ordered-events.c:245
  #14 0x00005555557bb95c in __ordered_events__flush (oe=0x555556038e60, how=OE_FLUSH__ROUND, timestamp=0) at util/ordered-events.c:324
  #15 0x00005555557bba46 in ordered_events__flush (oe=0x555556038e60, how=OE_FLUSH__ROUND) at util/ordered-events.c:342
  #16 0x00005555557b1b3b in perf_event__process_finished_round (tool=0x7fffffffbce0, event=0x7ffff7c15bb8, oe=0x555556038e60)
      at util/session.c:780
  #17 0x00005555557b3b27 in perf_session__process_user_event (session=0x5555560386d0, event=0x7ffff7c15bb8, file_offset=117688,
      file_path=0x555556038ff0 "perf.data") at util/session.c:1406

As you can see the entry->ms.map was NULL even if he->ms.map has a value. This is because 'sym' sort key is not given, so it cannot assume whether he->ms.sym and entry->ms.sym is the same. I only checked the 'sym' sort key here as it implies 'dso' behavior (so maps are the same).

Fixes ac01c8c4246546fd ("perf hist: Update hist symbol when updating maps")
Cc Adrian Hunter <[email protected]>
Cc Ian Rogers <[email protected]>
Cc Ingo Molnar <[email protected]>
Cc Jiri Olsa <[email protected]>
Cc Kan Liang <[email protected]>
Cc Matt Fleming <[email protected]>
Cc Peter Zijlstra <[email protected]>
Cc Stephane Eranian <[email protected]>
---
 tools/perf/util/hist.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
tools/perf/util/hist.c +1 -1
@@ -637,7 +637,7 @@ static struct hist_entry *hists__findnew
 			 * mis-adjust symbol addresses when computing
 			 * the history counter to increment.
 			 */
-			if (he->ms.map != entry->ms.map) {
+			if (hists__has(hists, sym) && he->ms.map != entry->ms.map) {
 				if (he->ms.sym) {
 					u64 addr = he->ms.sym->start;
 					he->ms.sym = map__find_symbol(entry->ms.map, addr);
author maintainer
#391 lore raw

PATCH 384/386 drm/amd/display: enable_hpo_dp_link_output: Check link_res->hpo_dp_link_enc before using it

In reply to Greg Kroah-Hartman

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

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

From: Alex Hung <[email protected]>

commit d925c04d974c657d10471c0c2dba3bc9c7d994ee upstream.

[WHAT & HOW]
Functions dp_enable_link_phy and dp_disable_link_phy can pass link_res without initializing hpo_dp_link_enc and it is necessary to check for null before dereferencing.

This fixes 1 FORWARD_NULL issue reported by Coverity.

Fixes 0beca868cde8 ("drm/amd/display: Check link_res->hpo_dp_link_enc before using it")
---
 drivers/gpu/drm/amd/display/dc/link/hwss/link_hwss_hpo_dp.c |    5 +++++
 1 file changed, 5 insertions(+)
drivers/gpu/drm/amd/display/dc/link/hwss/link_hwss_hpo_dp.c +5 -0
@@ -110,6 +110,11 @@ void enable_hpo_dp_link_output(struct dc
 		enum clock_source_id clock_source,
 		const struct dc_link_settings *link_settings)
 {
+	if (!link_res->hpo_dp_link_enc) {
+		DC_LOG_ERROR("%s: invalid hpo_dp_link_enc\n", __func__);
+		return;
+	}
+
 	if (link->dc->res_pool->dccg->funcs->set_symclk32_le_root_clock_gating)
 		link->dc->res_pool->dccg->funcs->set_symclk32_le_root_clock_gating(
 				link->dc->res_pool->dccg,
author maintainer
#392 lore raw

PATCH 385/386 null_blk: Fix return value of nullb_device_power_store()

In reply to Greg Kroah-Hartman

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

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

From: Damien Le Moal <[email protected]>

commit d9ff882b54f99f96787fa3df7cd938966843c418 upstream.

When powering on a null_blk device that is not already on, the return value ret that is initialized to be count is reused to check the return value of null_add_dev(), leading to nullb_device_power_store() to return null_add_dev() return value (0 on success) instead of "count". So make sure to set ret to be equal to count when there are no errors.

Fixes a2db328b0839 ("null_blk: fix null-ptr-dereference while configuring 'power' and 'submit_queues'")
---
 drivers/block/null_blk/main.c |    1 +
 1 file changed, 1 insertion(+)
drivers/block/null_blk/main.c +1 -0
@@ -470,6 +470,7 @@ static ssize_t nullb_device_power_store(
 
 		set_bit(NULLB_DEV_FL_CONFIGURED, &dev->flags);
 		dev->power = newp;
+		ret = count;
 	} else if (dev->power && !newp) {
 		if (test_and_clear_bit(NULLB_DEV_FL_UP, &dev->flags)) {
 			dev->power = newp;
author maintainer
#393 lore raw

PATCH 386/386 Revert "ubifs: ubifs_symlink: Fix memleak of inode->i_link in error path"

In reply to Greg Kroah-Hartman

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

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

From: Zhihao Cheng <[email protected]>

commit 7bed61a1cf166b5c113047fc8f60ff22dcb04893 upstream.

This reverts commit 6379b44cdcd67f5f5d986b73953e99700591edfa. Commit 1e022216dcd2 ("ubifs: ubifs_symlink: Fix memleak of inode->i_link in error path") is applied again in commit 6379b44cdcd6 ("ubifs:
ubifs_symlink: Fix memleak of inode->i_link in error path"), which changed ubifs_mknod (It won't become a real problem). Just revert it.

---
 fs/ubifs/dir.c |    2 --
 1 file changed, 2 deletions(-)
fs/ubifs/dir.c +0 -2
@@ -1126,8 +1126,6 @@ out_cancel:
 	dir_ui->ui_size = dir->i_size;
 	mutex_unlock(&dir_ui->ui_mutex);
 out_inode:
-	/* Free inode->i_link before inode is marked as bad. */
-	fscrypt_free_inode(inode);
 	make_bad_inode(inode);
 	iput(inode);
 out_fname:
#394 lore raw
In reply to Greg Kroah-Hartman

Hi Greg,

Quoted 8 lines · Greg Kroah-Hartman

This is the start of the stable review cycle for the 6.6.55 release. There are 386 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.

Responses should be made by Thu, 10 Oct 2024 11:55:15 +0000. Anything received after that time might be too late.

...

Quoted 3 lines

Ian Rogers <[email protected]>
perf callchain: Fix stitch LBR memory leaks

This patch is causing build failures for tools/perf/

util/machine.c: In function 'save_lbr_cursor_node':
util/machine.c:2540:9: error: implicit declaration of function 'map_symbol__exit'; did you mean 'symbol__exit'? [-Werror=implicit-function-declaration]

 2540 |         map_symbol__exit(&lbr_stitch->prev_lbr_cursor[idx].ms);
      |         ^~~~~~~~~~~~~~~~
      |         symbol__exit

...

util/thread.c: In function 'thread__free_stitch_list':
util/thread.c:481:17: error: implicit declaration of function 'map_symbol__exit'; did you mean 'symbol__exit'? [-Werror=implicit-function-declaration]

  481 |                 map_symbol__exit(&pos->cursor.ms);
      |                 ^~~~~~~~~~~~~~~~
      |                 symbol__exit

Thanks,
Harshit

#395 lore raw
Quoted 11 lines · Harshit Mogalapalli

Hi Greg,

Quoted 8 lines · Greg Kroah-Hartman

This is the start of the stable review cycle for the 6.6.55 release. There are 386 patches in this series, all will be posted as a response to this one.  If anyone has any issues with these being applied, please let me know.

Responses should be made by Thu, 10 Oct 2024 11:55:15 +0000. Anything received after that time might be too late.

Quoted 8 lines

...

Quoted 3 lines

Ian Rogers <[email protected]>
     perf callchain: Fix stitch LBR memory leaks

This patch is causing build failures for tools/perf/

Yes, same here.

Quoted 18 lines

util/machine.c: In function 'save_lbr_cursor_node':
util/machine.c:2540:9: error: implicit declaration of function 'map_symbol__exit'; did you mean 'symbol__exit'? [-Werror=implicit- function-declaration]
 2540 |         map_symbol__exit(&lbr_stitch->prev_lbr_cursor[idx].ms);
      |         ^~~~~~~~~~~~~~~~
      |         symbol__exit
...

util/thread.c: In function 'thread__free_stitch_list':
util/thread.c:481:17: error: implicit declaration of function 'map_symbol__exit'; did you mean 'symbol__exit'? [-Werror=implicit- function-declaration]
  481 |                 map_symbol__exit(&pos->cursor.ms);
      |                 ^~~~~~~~~~~~~~~~
      |                 symbol__exit

Thanks,
Harshit

Signature · 1 line
Florian
author maintainer
#396 lore raw
In reply to Harshit Mogalapalli
Quoted 29 lines · Harshit Mogalapalli

Hi Greg,

Quoted 8 lines · Greg Kroah-Hartman

This is the start of the stable review cycle for the 6.6.55 release. There are 386 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.

Responses should be made by Thu, 10 Oct 2024 11:55:15 +0000. Anything received after that time might be too late.

...

Quoted 3 lines

Ian Rogers <[email protected]>
perf callchain: Fix stitch LBR memory leaks

This patch is causing build failures for tools/perf/

util/machine.c: In function 'save_lbr_cursor_node':
util/machine.c:2540:9: error: implicit declaration of function 'map_symbol__exit'; did you mean 'symbol__exit'? [-Werror=implicit-function-declaration]

 2540 |         map_symbol__exit(&lbr_stitch->prev_lbr_cursor[idx].ms);
      |         ^~~~~~~~~~~~~~~~
      |         symbol__exit

...

Quoted 8 lines

util/thread.c: In function 'thread__free_stitch_list':
util/thread.c:481:17: error: implicit declaration of function 'map_symbol__exit'; did you mean 'symbol__exit'? [-Werror=implicit-function-declaration]

  481 |                 map_symbol__exit(&pos->cursor.ms);
      |                 ^~~~~~~~~~~~~~~~
      |                 symbol__exit

Argh, I missed this, let me go revert it in another release now...

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

Am 08.10.2024 um 14:04 schrieb Greg Kroah-Hartman:

Quoted 4 lines

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

Builds, boots and works on my 2-socket Ivy Bridge Xeon E5-2697 v2 server. No dmesg oddities or regressions found.

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]
Tested-by on the v1 series
#399 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.6.55 release. There are 386 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.

Responses should be made by Thu, 10 Oct 2024 11:55:15 +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.6.55-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.6.y
and the diffstat can be found below.

thanks,

greg k-h

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

thanks,
-- Shuah

#400 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.6.55 release. There are 386 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.

Responses should be made by Thu, 10 Oct 2024 11:55:15 +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.6.55-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.6.y
and the diffstat can be found below.

thanks,

greg k-h

The LTP syscalls fanotify22 test failed (broken).
This regression is noticed on linux.6.6.y, linux.6.10.y and linux.6.11.y.

We are bisecting this issue.

ltp-syscalls
- fanotify22

Test log,
-----------
fanotify16.c:751[ 452.527701] EXT4-fs error (device loop0):
__ext4_remount:6522: comm fanotify22: Abort forced by user tst_device.c:96: TINFO: Found free device 0 '/dev/loop0' tst_test.c:1106: TINFO: Formatting /dev/loop0 with ext4 opts='' extra opts='' mke2fs 1.47.1 (20-May-2024)
tst_test.c:1120: TINFO: Mounting /dev/loop0 to /scratch/ltp-6nPLv2EGcV/LTP_fanbDvQcT/test_mnt fstyp=ext4 flags=0 tst_test.c:1733: TINFO: LTP version: 20240524
tst_test.c:1617: TINFO: Timeout per run is 0h 02m 30s fanotify.h:122: TINFO: fid(test_mnt/internal_dir/bad_dir) = 6bd2dab9.86fe4716.7e82.df82837f.0...
fanotify.h:122: TINFO: fid(test_mnt/internal_dir) = 6bd2dab9.86fe4716.7e81.beaa198d.0...
fanotify22.c:278: TINFO: Umounting /scratch/ltp-6nPLv2EGcV/LTP_fanbDvQcT/test_mnt
debugfs 1.47.1 (20-May-2024)
debugfs 1.47.1 (20-May-2024)
fanotify22.c:281: TINFO: Mounting /dev/loop0 to /scratch/ltp-6nPLv2EGcV/LTP_fanbDvQcT/test_mnt fstyp=ext4 flags=0 fanotify.h:122: TINFO: fid(test_mnt) = 6bd2dab9.86fe4716.2.0.0... fanotify22.c:59: TINFO: Mounting /dev/loop0 to /scratch/ltp-6nPLv2EGcV/LTP_fanbDvQcT/test_mnt fstyp=ext4 flags=21 fanotify22.c:59: TBROK: mount(/dev/loop0, test_mnt, ext4, 33, 0x5659a1d5) failed: EROFS (30)

HINT: You _MAY_ be missing kernel fixes:

https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=124e7c61deb2

Summary:

passed   0
failed   0
broken   1

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

#401 lore raw

Hi,

Quoted 3 lines · Naresh Kamboju
Quoted 1 line · Greg Kroah-Hartman

...

Quoted 8 lines

The LTP syscalls fanotify22 test failed (broken).
This regression is noticed on linux.6.6.y, linux.6.10.y and linux.6.11.y.

We are bisecting this issue.

ltp-syscalls
- fanotify22

FYI: I remember seeing a discussion thread on this(atleast very similar):

https://lore.kernel.org/all/Zvp6L+oFnfASaoHl@t14s/

So based on that it should be PATCH 178/386:

Jan Kara <[email protected]>
ext4: don't set SB_RDONLY after filesystem errors

Thanks,
Harshit

Quoted 43 lines

Test log,
-----------
fanotify16.c:751[ 452.527701] EXT4-fs error (device loop0):
__ext4_remount:6522: comm fanotify22: Abort forced by user tst_device.c:96: TINFO: Found free device 0 '/dev/loop0' tst_test.c:1106: TINFO: Formatting /dev/loop0 with ext4 opts='' extra opts='' mke2fs 1.47.1 (20-May-2024)
tst_test.c:1120: TINFO: Mounting /dev/loop0 to /scratch/ltp-6nPLv2EGcV/LTP_fanbDvQcT/test_mnt fstyp=ext4 flags=0 tst_test.c:1733: TINFO: LTP version: 20240524
tst_test.c:1617: TINFO: Timeout per run is 0h 02m 30s fanotify.h:122: TINFO: fid(test_mnt/internal_dir/bad_dir) = 6bd2dab9.86fe4716.7e82.df82837f.0...
fanotify.h:122: TINFO: fid(test_mnt/internal_dir) = 6bd2dab9.86fe4716.7e81.beaa198d.0...
fanotify22.c:278: TINFO: Umounting /scratch/ltp-6nPLv2EGcV/LTP_fanbDvQcT/test_mnt
debugfs 1.47.1 (20-May-2024)
debugfs 1.47.1 (20-May-2024)
fanotify22.c:281: TINFO: Mounting /dev/loop0 to /scratch/ltp-6nPLv2EGcV/LTP_fanbDvQcT/test_mnt fstyp=ext4 flags=0 fanotify.h:122: TINFO: fid(test_mnt) = 6bd2dab9.86fe4716.2.0.0... fanotify22.c:59: TINFO: Mounting /dev/loop0 to /scratch/ltp-6nPLv2EGcV/LTP_fanbDvQcT/test_mnt fstyp=ext4 flags=21 fanotify22.c:59: TBROK: mount(/dev/loop0, test_mnt, ext4, 33, 0x5659a1d5) failed: EROFS (30)

HINT: You _MAY_ be missing kernel fixes:

https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=124e7c61deb2

Summary:

passed   0
failed   0
broken   1

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

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

Hi Greg

Quoted 10 lines · Greg Kroah-Hartman

This is the start of the stable review cycle for the 6.6.55 release. There are 386 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.

Responses should be made by Thu, 10 Oct 2024 11:55:15 +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.6.55-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.6.y
and the diffstat can be found below.

thanks,

greg k-h

6.6.55-rc1 tested.

Build successfully completed.
Boot successfully completed.
No dmesg regressions.
Video output normal.
Sound output normal.

Lenovo ThinkPad X1 Carbon Gen10(Intel i7-1260P(x86_64) arch linux)

[    0.000000] Linux version 6.6.55-rc1rv

(takeshi@ThinkPadX1Gen10J0764) (gcc (GCC) 14.2.1 20240910, GNU ld (GNU Binutils) 2.43.0) #1 SMP PREEMPT_DYNAMIC Wed Oct 9 20:12:56 JST 2024

Thanks

maintainer Tested-by on the v1 series
#403 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.6.55 release. There are 386 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.

Responses should be made by Thu, 10 Oct 2024 11:55:15 +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.6.55-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.6.y
and the diffstat can be found below.

thanks,

greg k-h

All tests passing for Tegra ...

Test results for stable-v6.6:

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

Linux version: 6.6.55-rc1-g75430d7252ba
Boards tested: tegra124-jetson-tk1, tegra186-p2771-0000,

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

Jon

Tested-by on the v1 series
#404 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.6.55 release. There are 386 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.

Responses should be made by Thu, 10 Oct 2024 11:55:15 +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.6.55-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.6.y
and the diffstat can be found below.

thanks,

greg k-h

Building passed on amd64, arm64, loongarch64, ppc64el, and riscv64. Smoke testing passed on 9 amd64 and 1 arm64 test systems.

https://github.com/AOSC-Dev/aosc-os-abbs/pull/8223

Signature · 2 lines
Best Regards,
Kexy Biscuit
Tested-by on the v1 series
#405 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.6.55 release. There are 386 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.

Responses should be made by Thu, 10 Oct 2024 11:55:15 +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.6.55-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.6.y
and the diffstat can be found below.

thanks,

greg k-h

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

Tested-by kernelci.org bot on the v1 series
#406 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.6.55 release. There are 386 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.

Responses should be made by Thu, 10 Oct 2024 11:55:15 +0000. Anything received after that time might be too late.

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

Quoted 10 lines
	https://www.kernel.org/pub/linux/kernel/v6.x/stable-review/patch-6.6.55-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.6.y
and the diffstat can be found below.

thanks,

greg k-h

Hi,

Please find the KernelCI report below :-

OVERVIEW

Builds: 25 passed, 0 failed

Boot tests: 510 passed, 0 failed

CI systems: maestro

REVISION

Commit
name:
hash: 75430d7252ba967f7ca3d11dffa4b90ff5aa0ccd
Checked out from
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-6.6.y

BUILDS

No new build failures found

BOOT TESTS

No new boot failures found

Thanks,
KernelCI team

Tested-by on the v1 series
#407 lore raw
In reply to Greg Kroah-Hartman
Quoted 8 lines · On Tue, 08 Oct 2024 14:04:05 +0200 Greg Kroah-Hartman…

This is the start of the stable review cycle for the 6.6.55 release. There are 386 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.

Responses should be made by Thu, 10 Oct 2024 11:55:15 +0000. Anything received after that time might be too late.

Boot-tested under QEMU for Rust x86_64:

Thanks!

Cheers,
Miguel