Skip to contentSkip to conversation

6.4.5-rc1 review

PATCH In review Greg Kroah-Hartman 17 participants 320 messages Jul 21, 2023 – Jul 27, 2023 Page 3 of 3

Subsystems (9)
Stable branch Memory management SCSI Arm Qualcomm mailing list +5 more subsystems
lore
Share & tools
lore
author maintainer
#291 lore raw

PATCH 284/292 scsi: qla2xxx: Fix potential NULL pointer dereference

In reply to Greg Kroah-Hartman

From: Bikash Hazarika <[email protected]>

commit 464ea494a40c6e3e0e8f91dd325408aaf21515ba upstream.

Klocwork tool reported 'cur_dsd' may be dereferenced. Add fix to validate pointer before dereferencing the pointer.

Cc [email protected]
Signed-off-by Bikash Hazarika <[email protected]>
Signed-off-by Nilesh Javali <[email protected]>
Link https://lore.kernel.org/r/[email protected] open here
Reviewed-by Himanshu Madhani <[email protected]>
Signed-off-by Martin K. Petersen <[email protected]>
Signed-off-by Greg Kroah-Hartman <[email protected]>
---
 drivers/scsi/qla2xxx/qla_iocb.c |    3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)
drivers/scsi/qla2xxx/qla_iocb.c +2 -1
@@ -607,7 +607,8 @@ qla24xx_build_scsi_type_6_iocbs(srb_t *s
 	put_unaligned_le32(COMMAND_TYPE_6, &cmd_pkt->entry_type);
 
 	/* No data transfer */
-	if (!scsi_bufflen(cmd) || cmd->sc_data_direction == DMA_NONE) {
+	if (!scsi_bufflen(cmd) || cmd->sc_data_direction == DMA_NONE ||
+	    tot_dsds == 0) {
 		cmd_pkt->byte_count = cpu_to_le32(0);
 		return 0;
 	}
author maintainer
#292 lore raw

PATCH 285/292 scsi: qla2xxx: Check valid rport returned by fc_bsg_to_rport()

In reply to Greg Kroah-Hartman

From: Nilesh Javali <[email protected]>

commit af73f23a27206ffb3c477cac75b5fcf03410556e upstream.

Klocwork reported warning of rport maybe NULL and will be dereferenced. rport returned by call to fc_bsg_to_rport() could be NULL and dereferenced.

Check valid rport returned by fc_bsg_to_rport().

Cc [email protected]
Signed-off-by Nilesh Javali <[email protected]>
Link https://lore.kernel.org/r/[email protected] open here
Reviewed-by Himanshu Madhani <[email protected]>
Signed-off-by Martin K. Petersen <[email protected]>
Signed-off-by Greg Kroah-Hartman <[email protected]>
---
 drivers/scsi/qla2xxx/qla_bsg.c |    4 ++++
 1 file changed, 4 insertions(+)
drivers/scsi/qla2xxx/qla_bsg.c +4 -0
@@ -283,6 +283,10 @@ qla2x00_process_els(struct bsg_job *bsg_
 
 	if (bsg_request->msgcode == FC_BSG_RPT_ELS) {
 		rport = fc_bsg_to_rport(bsg_job);
+		if (!rport) {
+			rval = -ENOMEM;
+			goto done;
+		}
 		fcport = *(fc_port_t **) rport->dd_data;
 		host = rport_to_shost(rport);
 		vha = shost_priv(host);
author maintainer
#293 lore raw

PATCH 286/292 scsi: qla2xxx: Correct the index of array

In reply to Greg Kroah-Hartman

From: Bikash Hazarika <[email protected]>

commit b1b9d3825df4c757d653d0b1df66f084835db9c3 upstream.

Klocwork reported array 'port_dstate_str' of size 10 may use index value(s) 10..15.

Add a fix to correct the index of array.

Cc [email protected]
Signed-off-by Bikash Hazarika <[email protected]>
Signed-off-by Nilesh Javali <[email protected]>
Link https://lore.kernel.org/r/[email protected] open here
Reviewed-by Himanshu Madhani <[email protected]>
Signed-off-by Martin K. Petersen <[email protected]>
Signed-off-by Greg Kroah-Hartman <[email protected]>
---
 drivers/scsi/qla2xxx/qla_inline.h |    5 ++++-
 1 file changed, 4 insertions(+), 1 deletion(-)
drivers/scsi/qla2xxx/qla_inline.h +4 -1
@@ -109,11 +109,13 @@ qla2x00_set_fcport_disc_state(fc_port_t
 {
 	int old_val;
 	uint8_t shiftbits, mask;
+	uint8_t port_dstate_str_sz;
 
 	/* This will have to change when the max no. of states > 16 */
 	shiftbits = 4;
 	mask = (1 << shiftbits) - 1;
 
+	port_dstate_str_sz = sizeof(port_dstate_str) / sizeof(char *);
 	fcport->disc_state = state;
 	while (1) {
 		old_val = atomic_read(&fcport->shadow_disc_state);

@@ -121,7 +123,8 @@ qla2x00_set_fcport_disc_state(fc_port_t
 		    old_val, (old_val << shiftbits) | state)) {
 			ql_dbg(ql_dbg_disc, fcport->vha, 0x2134,
 			    "FCPort %8phC disc_state transition: %s to %s - portid=%06x.\n",
-			    fcport->port_name, port_dstate_str[old_val & mask],
+			    fcport->port_name, (old_val & mask) < port_dstate_str_sz ?
+				    port_dstate_str[old_val & mask] : "Unknown",
 			    port_dstate_str[state], fcport->d_id.b24);
 			return;
 		}
author maintainer
#294 lore raw

PATCH 287/292 scsi: qla2xxx: Pointer may be dereferenced

In reply to Greg Kroah-Hartman

From: Shreyas Deodhar <[email protected]>

commit 00eca15319d9ce8c31cdf22f32a3467775423df4 upstream.

Klocwork tool reported pointer 'rport' returned from call to function fc_bsg_to_rport() may be NULL and will be dereferenced.

Add a fix to validate rport before dereferencing.

Cc [email protected]
Signed-off-by Shreyas Deodhar <[email protected]>
Signed-off-by Nilesh Javali <[email protected]>
Link https://lore.kernel.org/r/[email protected] open here
Reviewed-by Himanshu Madhani <[email protected]>
Signed-off-by Martin K. Petersen <[email protected]>
Signed-off-by Greg Kroah-Hartman <[email protected]>
---
 drivers/scsi/qla2xxx/qla_bsg.c |    2 ++
 1 file changed, 2 insertions(+)
drivers/scsi/qla2xxx/qla_bsg.c +2 -0
@@ -2996,6 +2996,8 @@ qla24xx_bsg_request(struct bsg_job *bsg_
 
 	if (bsg_request->msgcode == FC_BSG_RPT_ELS) {
 		rport = fc_bsg_to_rport(bsg_job);
+		if (!rport)
+			return ret;
 		host = rport_to_shost(rport);
 		vha = shost_priv(host);
 	} else {
author maintainer
#295 lore raw

PATCH 288/292 scsi: qla2xxx: Remove unused nvme_ls_waitq wait queue

In reply to Greg Kroah-Hartman

From: Manish Rangankar <[email protected]>

commit 20fce500b232b970e40312a9c97e7f3b6d7a709c upstream.

System crash when qla2x00_start_sp(sp) returns error code EGAIN and wake_up gets called for uninitialized wait queue sp->nvme_ls_waitq.

    qla2xxx [0000:37:00.1]-2121:5: Returning existing qpair of ffff8ae2c0513400 for idx=0
    qla2xxx [0000:37:00.1]-700e:5: qla2x00_start_sp failed = 11
    BUG: unable to handle kernel NULL pointer dereference at 0000000000000000
    PGD 0 P4D 0
    Oops: 0000 [#1] SMP NOPTI
    Hardware name: HPE ProLiant DL360 Gen10/ProLiant DL360 Gen10, BIOS U32 09/03/2021
    Workqueue: nvme-wq nvme_fc_connect_ctrl_work [nvme_fc]
    RIP: 0010:__wake_up_common+0x4c/0x190
    RSP: 0018:ffff95f3e0cb7cd0 EFLAGS: 00010086
    RAX: 0000000000000000 RBX: ffff8b08d3b26328 RCX: 0000000000000000
    RDX: 0000000000000001 RSI: 0000000000000003 RDI: ffff8b08d3b26320
    RBP: 0000000000000001 R08: 0000000000000000 R09: ffffffffffffffe8
    R10: 0000000000000000 R11: ffff95f3e0cb7a60 R12: ffff95f3e0cb7d20
    R13: 0000000000000003 R14: 0000000000000000 R15: 0000000000000000
    FS:  0000000000000000(0000) GS:ffff8b2fdf6c0000(0000) knlGS:0000000000000000
    CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
    CR2: 0000000000000000 CR3: 0000002f1e410002 CR4: 00000000007706e0
    DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
    DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
    PKRU: 55555554
    Call Trace:
     __wake_up_common_lock+0x7c/0xc0
     qla_nvme_ls_req+0x355/0x4c0 [qla2xxx]
     ? __nvme_fc_send_ls_req+0x260/0x380 [nvme_fc]
     ? nvme_fc_send_ls_req.constprop.42+0x1a/0x45 [nvme_fc]
     ? nvme_fc_connect_ctrl_work.cold.63+0x1e3/0xa7d [nvme_fc]

Remove unused nvme_ls_waitq wait queue. nvme_ls_waitq logic was removed previously in the commits tagged Fixed: below.

Fixes 219d27d7147e ("scsi: qla2xxx: Fix race conditions in the code for aborting SCSI commands")
Fixes 5621b0dd7453 ("scsi: qla2xxx: Simpify unregistration of FC-NVMe local/remote ports")
Cc [email protected]
Signed-off-by Manish Rangankar <[email protected]>
Signed-off-by Nilesh Javali <[email protected]>
Link https://lore.kernel.org/r/[email protected] open here
Signed-off-by Martin K. Petersen <[email protected]>
Signed-off-by Greg Kroah-Hartman <[email protected]>
---
 drivers/scsi/qla2xxx/qla_def.h  |    1 -
 drivers/scsi/qla2xxx/qla_nvme.c |    3 ---
 2 files changed, 4 deletions(-)
drivers/scsi/qla2xxx/qla_def.h +0 -1
@@ -703,7 +703,6 @@ typedef struct srb {
 	struct iocb_resource iores;
 	struct kref cmd_kref;	/* need to migrate ref_count over to this */
 	void *priv;
-	wait_queue_head_t nvme_ls_waitq;
 	struct fc_port *fcport;
 	struct scsi_qla_host *vha;
 	unsigned int start_timer:1;
drivers/scsi/qla2xxx/qla_nvme.c +0 -3
@@ -360,7 +360,6 @@ static int qla_nvme_ls_req(struct nvme_f
 	if (rval != QLA_SUCCESS) {
 		ql_log(ql_log_warn, vha, 0x700e,
 		    "qla2x00_start_sp failed = %d\n", rval);
-		wake_up(&sp->nvme_ls_waitq);
 		sp->priv = NULL;
 		priv->sp = NULL;
 		qla2x00_rel_sp(sp);

@@ -652,7 +651,6 @@ static int qla_nvme_post_cmd(struct nvme
 	if (!sp)
 		return -EBUSY;
 
-	init_waitqueue_head(&sp->nvme_ls_waitq);
 	kref_init(&sp->cmd_kref);
 	spin_lock_init(&priv->cmd_lock);
 	sp->priv = priv;

@@ -671,7 +669,6 @@ static int qla_nvme_post_cmd(struct nvme
 	if (rval != QLA_SUCCESS) {
 		ql_log(ql_log_warn, vha, 0x212d,
 		    "qla2x00_start_nvme_mq failed = %d\n", rval);
-		wake_up(&sp->nvme_ls_waitq);
 		sp->priv = NULL;
 		priv->sp = NULL;
 		qla2xxx_rel_qpair_sp(sp->qpair, sp);
author maintainer
#296 lore raw

PATCH 289/292 scsi: qla2xxx: Fix end of loop test

In reply to Greg Kroah-Hartman

From: Dan Carpenter <[email protected]>

commit 339020091e246e708c1381acf74c5f8e3fe4d2b5 upstream.

This loop will exit successfully when "found" is false or in the failure case it times out with "wait_iter" set to -1. The test for timeouts is impossible as is.

Fixes b843adde8d49 ("scsi: qla2xxx: Fix mem access after free")
Signed-off-by Dan Carpenter <[email protected]>
Link https://lore.kernel.org/r/[email protected] open here
Signed-off-by Martin K. Petersen <[email protected]>
Signed-off-by Greg Kroah-Hartman <[email protected]>
---
 drivers/scsi/qla2xxx/qla_os.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/scsi/qla2xxx/qla_os.c +1 -1
@@ -1409,7 +1409,7 @@ __qla2x00_eh_wait_for_pending_commands(s
 			break;
 	}
 
-	if (!wait_iter && found)
+	if (wait_iter == -1)
 		status = QLA_FUNCTION_FAILED;
 
 	return status;
author maintainer
#297 lore raw

PATCH 290/292 net: dsa: ocelot: unlock on error in vsc9959_qos_port_tas_set()

In reply to Greg Kroah-Hartman

From: Dan Carpenter <[email protected]>

commit cad7526f33ce1e7d387d1d0568a089e41deec5c2 upstream.

This error path needs call mutex_unlock(&ocelot->tas_lock) before returning.

Fixes 2d800bc500fb ("net/sched: taprio: replace tc_taprio_qopt_offload :: enable with a "cmd" enum")
Signed-off-by Dan Carpenter <[email protected]>
Reviewed-by Vladimir Oltean <[email protected]>
Signed-off-by David S. Miller <[email protected]>
Signed-off-by Greg Kroah-Hartman <[email protected]>
---
 drivers/net/dsa/ocelot/felix_vsc9959.c |    3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)
drivers/net/dsa/ocelot/felix_vsc9959.c +2 -1
@@ -1449,7 +1449,8 @@ static int vsc9959_qos_port_tas_set(stru
 		mutex_unlock(&ocelot->tas_lock);
 		return 0;
 	} else if (taprio->cmd != TAPRIO_CMD_REPLACE) {
-		return -EOPNOTSUPP;
+		ret = -EOPNOTSUPP;
+		goto err_unlock;
 	}
 
 	ret = ocelot_port_mqprio(ocelot, port, &taprio->mqprio);
author maintainer
#298 lore raw

PATCH 291/292 MIPS: kvm: Fix build error with KVM_MIPS_DEBUG_COP0_COUNTERS enabled

In reply to Greg Kroah-Hartman

From: Thomas Bogendoerfer <[email protected]>

commit 3a6dbb691782e88e07e5c70b327495dbd58a2e7f upstream.

Commit e4de20576986 ("MIPS: KVM: Fix NULL pointer dereference") missed converting one place accessing cop0 registers, which results in a build error, if KVM_MIPS_DEBUG_COP0_COUNTERS is enabled.

Fixes e4de20576986 ("MIPS: KVM: Fix NULL pointer dereference")
Signed-off-by Thomas Bogendoerfer <[email protected]>
Reviewed-by Philippe Mathieu-Daudé <[email protected]>
Signed-off-by Greg Kroah-Hartman <[email protected]>
---
 arch/mips/kvm/stats.c |    4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)
arch/mips/kvm/stats.c +2 -2
@@ -54,9 +54,9 @@ void kvm_mips_dump_stats(struct kvm_vcpu
 	kvm_info("\nKVM VCPU[%d] COP0 Access Profile:\n", vcpu->vcpu_id);
 	for (i = 0; i < N_MIPS_COPROC_REGS; i++) {
 		for (j = 0; j < N_MIPS_COPROC_SEL; j++) {
-			if (vcpu->arch.cop0->stat[i][j])
+			if (vcpu->arch.cop0.stat[i][j])
 				kvm_info("%s[%d]: %lu\n", kvm_cop0_str[i], j,
-					 vcpu->arch.cop0->stat[i][j]);
+					 vcpu->arch.cop0.stat[i][j]);
 		}
 	}
 #endif
author maintainer
#299 lore raw

PATCH 292/292 Revert "drm/amd: Disable PSR-SU on Parade 0803 TCON"

In reply to Greg Kroah-Hartman

From: Mario Limonciello <[email protected]>

commit 1e66a17ce546eabad753178bbd4175cb52bafca8 upstream.

This reverts commit 072030b1783056b5de8b0fac5303a5e9dbc6cfde. This is no longer necessary when using newer DMUB F/W.

Cc [email protected]
Cc Sean Wang <[email protected]>
Cc Marc Rossi <[email protected]>
Cc Hamza Mahfooz <[email protected]>
Cc Tsung-hua (Ryan) Lin <[email protected]>
Reviewed-by Leo Li <[email protected]>
Signed-off-by Mario Limonciello <[email protected]>
Signed-off-by Alex Deucher <[email protected]>
Signed-off-by Greg Kroah-Hartman <[email protected]>
---
 drivers/gpu/drm/amd/display/modules/power/power_helpers.c |    2 --
 1 file changed, 2 deletions(-)
drivers/gpu/drm/amd/display/modules/power/power_helpers.c +0 -2
@@ -818,8 +818,6 @@ bool is_psr_su_specific_panel(struct dc_
 				((dpcd_caps->sink_dev_id_str[1] == 0x08 && dpcd_caps->sink_dev_id_str[0] == 0x08) ||
 				(dpcd_caps->sink_dev_id_str[1] == 0x08 && dpcd_caps->sink_dev_id_str[0] == 0x07)))
 				isPSRSUSupported = false;
-			else if (dpcd_caps->sink_dev_id_str[1] == 0x08 && dpcd_caps->sink_dev_id_str[0] == 0x03)
-				isPSRSUSupported = false;
 			else if (dpcd_caps->psr_info.force_psrsu_cap == 0x1)
 				isPSRSUSupported = true;
 		}
Tested-by on the v1 series
#300 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.4.5 release. There are 292 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 Sun, 23 Jul 2023 16:04:29 +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.4.5-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.4.y
and the diffstat can be found below.

thanks,

greg k-h

Tested rc1 against the Fedora build system (aarch64, ppc64le, s390x, x86_64), and boot tested x86_64. No regressions noted.

Tested-by Justin M. Forbes <[email protected]>
Tested-by on the v1 series
#301 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.4.5 release. There are 292 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 Sun, 23 Jul 2023 16:04:29 +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.4.5-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.4.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]>
Tested-by on the v1 series
#302 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.4.5 release. There are 292 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 bindeb-pkgs 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
Tested-by Linux Kernel Functional Testing on the v1 series
#303 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.4.5 release. There are 292 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 Sun, 23 Jul 2023 16:04:29 +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.4.5-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.4.y
and the diffstat can be found below.

thanks,

greg k-h

Results from Linaro’s test farm.
No regressions on arm64, arm, x86_64, and i386.

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

NOTE:
The following kernel warning was noticed while booting qemu-arm64 with these configs enabled on stable rc 6.4.5-rc1.

CONFIG_ARM64_64K_PAGES=y
CONFIG_KFENCE=y

This crash is not easily reproducible.

boot logs:
--------

[    0.000000] Booting Linux on physical CPU 0x0000000000 [0x000f0510]
[    0.000000] Linux version 6.4.5-rc1 (tuxmake@tuxmake)
(aarch64-linux-gnu-gcc (Debian 12.2.0-14) 12.2.0, GNU ld (GNU Binutils
for Debian) 2.40) #1 SMP PREEMPT @1689957802
[    0.000000] random: crng init done
[    0.000000] Machine model: linux,dummy-virt
...
<6>[    0.006821] kfence: initialized - using 33554432 bytes for 255
objects at 0x(____ptrval____)-0x(____ptrval____)
...
<4>[    7.726994] ------------[ cut here ]------------
<4>[    7.727704] WARNING: CPU: 1 PID: 1 at mm/kfence/core.c:1097
__kfence_free+0x84/0xc8
<4>[    7.730078] Modules linked in: ip_tables x_tables
<4>[    7.732637] CPU: 1 PID: 1 Comm: systemd Not tainted 6.4.5-rc1 #1
<4>[    7.733334] Hardware name: linux,dummy-virt (DT)
<4>[    7.734765] pstate: 83400009 (Nzcv daif +PAN -UAO +TCO +DIT
-SSBS BTYPE=--)
<4>[    7.735323] pc : __kfence_free+0x84/0xc8
<4>[    7.736036] lr : __slab_free+0x490/0x508
<4>[    7.736374] sp : ffff8000080afb40
<4>[    7.736657] x29: ffff8000080afb40 x28: ffffffc0003fa100 x27:
0000000000000000
<4>[    7.738294] x26: 0000000000000000 x25: 0000000000000001 x24:
0000000000000000
<4>[    7.739138] x23: ffffcd8ea7099000 x22: ffffcd8ea45cac38 x21:
ffff0000fe840000
<4>[    7.739961] x20: ffffcd8ea45cac38 x19: ffff0000c0012300 x18:
0000000000000000
<4>[    7.740778] x17: 0000000000000000 x16: 0000000000000000 x15:
0000000000000000
<4>[    7.741636] x14: 0000000000000000 x13: 0000000000000000 x12:
0000000000000000
<4>[    7.742474] x11: 0000000000000000 x10: 0000000000000000 x9 :
ffffcd8ea45601e0
<4>[    7.743407] x8 : ffff8000080afc20 x7 : 0000000000000000 x6 :
0000000000009901
<4>[    7.744268] x5 : ffffcd8ea45cac38 x4 : ffffcd8ea7099000 x3 :
ffffcd8ea76e7aa0
<4>[    7.745093] x2 : ffff0000c162e000 x1 : ffffcd8ea76fa5b0 x0 :
ffff0000fe840000
<4>[    7.746478] Call trace:
<4>[    7.746776]  __kfence_free+0x84/0xc8
<4>[    7.747134]  __slab_free+0x490/0x508
<4>[    7.748063]  __kmem_cache_free+0x2b4/0x2d0
<4>[    7.748377]  kfree+0x78/0x140
<4>[    7.748638]  single_release+0x40/0x60
<4>[    7.750664]  __fput+0x78/0x260
<4>[    7.751065]  ____fput+0x18/0x30
<4>[    7.752086]  task_work_run+0x80/0xe0
<4>[    7.753122]  do_notify_resume+0x200/0x1398
<4>[    7.754292]  el0_svc+0xec/0x100
<4>[    7.754573]  el0t_64_sync_handler+0xf4/0x120
<4>[    7.755559]  el0t_64_sync+0x190/0x198
<4>[    7.756643] ---[ end trace 0000000000000000 ]---

Links
- https://qa-reports.linaro.org/lkft/linux-stable-rc-linux-6.4.y/build/v6.4.4-293-g4f44255da83d/testrun/18526234/suite/log-parser-boot/test/check-kernel-exception/log
- https://qa-reports.linaro.org/lkft/linux-stable-rc-linux-6.4.y/build/v6.4.4-293-g4f44255da83d/testrun/18526234/suite/log-parser-boot/tests/
- https://storage.tuxsuite.com/public/linaro/lkft/builds/2StEPFnEfoD076PRu8fIxjexhnM/

## Build
* kernel: 6.4.5-rc1
* git: https://gitlab.com/Linaro/lkft/mirrors/stable/linux-stable-rc
* git branch: linux-6.4.y
* git commit: 4f44255da83d4e0d6c39114e6d90f43705c9159d
* git describe: v6.4.4-293-g4f44255da83d
* test details:
https://qa-reports.linaro.org/lkft/linux-stable-rc-linux-6.4.y/build/v6.4.4-293-g4f44255da83d

## Test Regressions (compared to v6.4.4-150-g698271d38e0b)

## Metric Regressions (compared to v6.4.4-150-g698271d38e0b)

## Test Fixes (compared to v6.4.4-150-g698271d38e0b)

## Metric Fixes (compared to v6.4.4-150-g698271d38e0b)

## Test result summary
total: 165616, pass: 143054, fail: 2212, skip: 20190, xfail: 160

## Build Summary
* arc: 5 total, 5 passed, 0 failed
* arm: 141 total, 141 passed, 0 failed
* arm64: 50 total, 50 passed, 0 failed
* i386: 37 total, 37 passed, 0 failed
* mips: 26 total, 26 passed, 0 failed
* parisc: 3 total, 3 passed, 0 failed
* powerpc: 34 total, 34 passed, 0 failed
* riscv: 22 total, 22 passed, 0 failed
* s390: 12 total, 12 passed, 0 failed
* sh: 12 total, 12 passed, 0 failed
* sparc: 6 total, 6 passed, 0 failed
* x86_64: 42 total, 42 passed, 0 failed

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

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

#304 lore raw

[ Removed the stable reviewers, bringing in the kfence people ]

See

https://lore.kernel.org/lkml/CA+G9fYvgy22wiY=c3wLOrCM6o33636abhtEynXhJkqxJh4ca0A@mail.gmail.com/

for the original report. The warning was introduced in 8f0b36497303 ("mm: kfence: fix objcgs vector allocation"), and Google doesn't find any other cases of this.

Anybody?

Linus

Quoted 30 lines · Naresh Kamboju

Results from Linaro’s test farm.
No regressions on arm64, arm, x86_64, and i386.

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

NOTE:
The following kernel warning was noticed while booting qemu-arm64 with these configs enabled on stable rc 6.4.5-rc1.

CONFIG_ARM64_64K_PAGES=y
CONFIG_KFENCE=y

This crash is not easily reproducible.

boot logs:
--------

[    0.000000] Booting Linux on physical CPU 0x0000000000 [0x000f0510]
[    0.000000] Linux version 6.4.5-rc1 (tuxmake@tuxmake)
(aarch64-linux-gnu-gcc (Debian 12.2.0-14) 12.2.0, GNU ld (GNU Binutils
for Debian) 2.40) #1 SMP PREEMPT @1689957802
[    0.000000] random: crng init done
[    0.000000] Machine model: linux,dummy-virt
...
[    0.006821] kfence: initialized - using 33554432 bytes for 255
objects at 0x(____ptrval____)-0x(____ptrval____)
...
[    7.726994] ------------[ cut here ]------------
[    7.727704] WARNING: CPU: 1 PID: 1 at mm/kfence/core.c:1097

__kfence_free+0x84/0xc8

...

Quoted 13 lines
[    7.746478] Call trace:
[    7.746776]  __kfence_free+0x84/0xc8
[    7.747134]  __slab_free+0x490/0x508
[    7.748063]  __kmem_cache_free+0x2b4/0x2d0
[    7.748377]  kfree+0x78/0x140
[    7.748638]  single_release+0x40/0x60
[    7.750664]  __fput+0x78/0x260
[    7.751065]  ____fput+0x18/0x30
[    7.752086]  task_work_run+0x80/0xe0
[    7.753122]  do_notify_resume+0x200/0x1398
[    7.754292]  el0_svc+0xec/0x100
[    7.754573]  el0t_64_sync_handler+0xf4/0x120
[    7.755559]  el0t_64_sync+0x190/0x198
maintainer
#305 lore raw
Quoted 7 lines · Linus Torvalds

[ Removed the stable reviewers, bringing in the kfence people ]

See

https://lore.kernel.org/lkml/CA+G9fYvgy22wiY=c3wLOrCM6o33636abhtEynXhJkqxJh4ca0A@mail.gmail.com/

Quoted 16 lines

for the original report. The warning was introduced in 8f0b36497303 ("mm: kfence: fix objcgs vector allocation"), and Google doesn't find any other cases of this.

Anybody?

Linus

Quoted 6 lines

NOTE:
The following kernel warning was noticed while booting qemu-arm64 with these configs enabled on stable rc 6.4.5-rc1.

CONFIG_ARM64_64K_PAGES=y
CONFIG_KFENCE=y

Is there a full config somewhere?

Quoted 1 line
Quoted 1 line

This crash is not easily reproducible.

CONFIG_KFENCE_SAMPLE_INTERVAL=10
CONFIG_KFENCE_NUM_OBJECTS=2048

might improve reproducibility.

Quoted 17 lines
Quoted 16 lines

boot logs:
--------

[    0.000000] Booting Linux on physical CPU 0x0000000000 [0x000f0510]
[    0.000000] Linux version 6.4.5-rc1 (tuxmake@tuxmake)
(aarch64-linux-gnu-gcc (Debian 12.2.0-14) 12.2.0, GNU ld (GNU Binutils
for Debian) 2.40) #1 SMP PREEMPT @1689957802
[    0.000000] random: crng init done
[    0.000000] Machine model: linux,dummy-virt
...
[    0.006821] kfence: initialized - using 33554432 bytes for 255
objects at 0x(____ptrval____)-0x(____ptrval____)
...
[    7.726994] ------------[ cut here ]------------
[    7.727704] WARNING: CPU: 1 PID: 1 at mm/kfence/core.c:1097

__kfence_free+0x84/0xc8

...

Quoted 13 lines
Quoted 5 lines
[    7.746478] Call trace:
[    7.746776]  __kfence_free+0x84/0xc8
[    7.747134]  __slab_free+0x490/0x508
[    7.748063]  __kmem_cache_free+0x2b4/0x2d0
[    7.748377]  kfree+0x78/0x140
Quoted 8 lines
[    7.748638]  single_release+0x40/0x60
[    7.750664]  __fput+0x78/0x260
[    7.751065]  ____fput+0x18/0x30
[    7.752086]  task_work_run+0x80/0xe0
[    7.753122]  do_notify_resume+0x200/0x1398
[    7.754292]  el0_svc+0xec/0x100
[    7.754573]  el0t_64_sync_handler+0xf4/0x120
[    7.755559]  el0t_64_sync+0x190/0x198

It would be interesting to see the contents of /sys/kernel/debug/kfence/objects together with the object address. Would it be possible to boot the kernel with no_hash_pointers and add a line printing the object address:

mm/kfence/core.c +4 -1
index dad3c0eb70a01..23f27f6cb18cf 100644
@@ -1094,7 +1094,10 @@ void __kfence_free(void *addr)
        struct kfence_metadata *meta = addr_to_metadata((unsigned long)addr);
 
 #ifdef CONFIG_MEMCG
-       KFENCE_WARN_ON(meta->objcg);
+       if (meta->objcg) {
+               pr_err("ADDR: %px\n", addr);
+               KFENCE_WARN_ON(1);
+       }
 #endif
        /*
         * If the objects of the cache are SLAB_TYPESAFE_BY_RCU, defer freeing

, and then dump /sys/kernel/debug/kfence/objects?

Knowing the kfence pool location (the line starting with "kfence:
initialized") and the object address, we can probably understand from the allocation stack in sysfs, whether the object is supposed to be deleted.

#306 lore raw
Quoted 20 lines · Alexander Potapenko
Quoted 15 lines · Linus Torvalds

[ Removed the stable reviewers, bringing in the kfence people ]

See

https://lore.kernel.org/lkml/CA+G9fYvgy22wiY=c3wLOrCM6o33636abhtEynXhJkqxJh4ca0A@mail.gmail.com/

for the original report. The warning was introduced in 8f0b36497303 ("mm: kfence: fix objcgs vector allocation"), and Google doesn't find any other cases of this.

Anybody?

Linus

Quoted 8 lines
Quoted 6 lines
Quoted 6 lines

NOTE:
The following kernel warning was noticed while booting qemu-arm64 with these configs enabled on stable rc 6.4.5-rc1.

CONFIG_ARM64_64K_PAGES=y
CONFIG_KFENCE=y

Is there a full config somewhere?

Please find build details
- https://storage.tuxsuite.com/public/linaro/lkft/builds/2StEPFnEfoD076PRu8fIxjexhnM/
- https://storage.tuxsuite.com/public/linaro/lkft/builds/2StEPFnEfoD076PRu8fIxjexhnM/config
- https://storage.tuxsuite.com/public/linaro/lkft/builds/2StEPFnEfoD076PRu8fIxjexhnM/vmlinux.xz
- https://storage.tuxsuite.com/public/linaro/lkft/builds/2StEPFnEfoD076PRu8fIxjexhnM/System.map
- https://storage.tuxsuite.com/public/linaro/lkft/builds/2StEPFnEfoD076PRu8fIxjexhnM/Image.gz

Quoted 7 lines
Quoted 2 lines
Quoted 2 lines

This crash is not easily reproducible.

CONFIG_KFENCE_SAMPLE_INTERVAL=10
CONFIG_KFENCE_NUM_OBJECTS=2048

might improve reproducibility.

The above test have following Kconfigs enabled.

CONFIG_HAVE_ARCH_KASAN=y
CONFIG_HAVE_ARCH_KASAN_SW_TAGS=y
CONFIG_HAVE_ARCH_KASAN_HW_TAGS=y
CONFIG_HAVE_ARCH_KASAN_VMALLOC=y
CONFIG_CC_HAS_KASAN_GENERIC=y
CONFIG_CC_HAS_KASAN_SW_TAGS=y
CONFIG_CC_HAS_WORKING_NOSANITIZE_ADDRESS=y
# CONFIG_KASAN is not set
CONFIG_HAVE_ARCH_KFENCE=y
CONFIG_KFENCE=y
CONFIG_KFENCE_SAMPLE_INTERVAL=100
CONFIG_KFENCE_NUM_OBJECTS=255
# CONFIG_KFENCE_DEFERRABLE is not set
CONFIG_KFENCE_STRESS_TEST_FAULTS=0

Quoted 54 lines
Quoted 18 lines
Quoted 17 lines

boot logs:
--------

[    0.000000] Booting Linux on physical CPU 0x0000000000 [0x000f0510]
[    0.000000] Linux version 6.4.5-rc1 (tuxmake@tuxmake)
(aarch64-linux-gnu-gcc (Debian 12.2.0-14) 12.2.0, GNU ld (GNU Binutils
for Debian) 2.40) #1 SMP PREEMPT @1689957802
[    0.000000] random: crng init done
[    0.000000] Machine model: linux,dummy-virt
...
[    0.006821] kfence: initialized - using 33554432 bytes for 255
objects at 0x(____ptrval____)-0x(____ptrval____)
...
[    7.726994] ------------[ cut here ]------------
[    7.727704] WARNING: CPU: 1 PID: 1 at mm/kfence/core.c:1097

__kfence_free+0x84/0xc8

...

Quoted 13 lines
Quoted 5 lines
[    7.746478] Call trace:
[    7.746776]  __kfence_free+0x84/0xc8
[    7.747134]  __slab_free+0x490/0x508
[    7.748063]  __kmem_cache_free+0x2b4/0x2d0
[    7.748377]  kfree+0x78/0x140
Quoted 8 lines
[    7.748638]  single_release+0x40/0x60
[    7.750664]  __fput+0x78/0x260
[    7.751065]  ____fput+0x18/0x30
[    7.752086]  task_work_run+0x80/0xe0
[    7.753122]  do_notify_resume+0x200/0x1398
[    7.754292]  el0_svc+0xec/0x100
[    7.754573]  el0t_64_sync_handler+0xf4/0x120
[    7.755559]  el0t_64_sync+0x190/0x198

It would be interesting to see the contents of /sys/kernel/debug/kfence/objects together with the object address. Would it be possible to boot the kernel with no_hash_pointers and add a line printing the object address:

mm/kfence/core.c +4 -1
index dad3c0eb70a01..23f27f6cb18cf 100644
@@ -1094,7 +1094,10 @@ void __kfence_free(void *addr)
        struct kfence_metadata *meta = addr_to_metadata((unsigned long)addr);
 
 #ifdef CONFIG_MEMCG
-       KFENCE_WARN_ON(meta->objcg);
+       if (meta->objcg) {
+               pr_err("ADDR: %px\n", addr);
+               KFENCE_WARN_ON(1);
+       }
 #endif
        /*
         * If the objects of the cache are SLAB_TYPESAFE_BY_RCU, defer freeing
Quoted 2 lines

, and then dump /sys/kernel/debug/kfence/objects?

This testing is running on CI loops and however, I will try to reproduce this locally.

Quoted 4 lines

Knowing the kfence pool location (the line starting with "kfence:
initialized") and the object address, we can probably understand from the allocation stack in sysfs, whether the object is supposed to be deleted.

- Naresh

#307 lore raw

Hi Alexander,

Quoted 117 lines · Naresh Kamboju
Quoted 20 lines · Alexander Potapenko
Quoted 15 lines · Linus Torvalds

[ Removed the stable reviewers, bringing in the kfence people ]

See

https://lore.kernel.org/lkml/CA+G9fYvgy22wiY=c3wLOrCM6o33636abhtEynXhJkqxJh4ca0A@mail.gmail.com/

for the original report. The warning was introduced in 8f0b36497303 ("mm: kfence: fix objcgs vector allocation"), and Google doesn't find any other cases of this.

Anybody?

Linus

Quoted 8 lines
Quoted 6 lines
Quoted 6 lines

NOTE:
The following kernel warning was noticed while booting qemu-arm64 with these configs enabled on stable rc 6.4.5-rc1.

CONFIG_ARM64_64K_PAGES=y
CONFIG_KFENCE=y

Is there a full config somewhere?

Please find build details
- https://storage.tuxsuite.com/public/linaro/lkft/builds/2StEPFnEfoD076PRu8fIxjexhnM/
- https://storage.tuxsuite.com/public/linaro/lkft/builds/2StEPFnEfoD076PRu8fIxjexhnM/config
- https://storage.tuxsuite.com/public/linaro/lkft/builds/2StEPFnEfoD076PRu8fIxjexhnM/vmlinux.xz
- https://storage.tuxsuite.com/public/linaro/lkft/builds/2StEPFnEfoD076PRu8fIxjexhnM/System.map
- https://storage.tuxsuite.com/public/linaro/lkft/builds/2StEPFnEfoD076PRu8fIxjexhnM/Image.gz

Quoted 7 lines
Quoted 2 lines
Quoted 2 lines

This crash is not easily reproducible.

CONFIG_KFENCE_SAMPLE_INTERVAL=10
CONFIG_KFENCE_NUM_OBJECTS=2048

might improve reproducibility.

The above test have following Kconfigs enabled.

CONFIG_HAVE_ARCH_KASAN=y
CONFIG_HAVE_ARCH_KASAN_SW_TAGS=y
CONFIG_HAVE_ARCH_KASAN_HW_TAGS=y
CONFIG_HAVE_ARCH_KASAN_VMALLOC=y
CONFIG_CC_HAS_KASAN_GENERIC=y
CONFIG_CC_HAS_KASAN_SW_TAGS=y
CONFIG_CC_HAS_WORKING_NOSANITIZE_ADDRESS=y
# CONFIG_KASAN is not set
CONFIG_HAVE_ARCH_KFENCE=y
CONFIG_KFENCE=y
CONFIG_KFENCE_SAMPLE_INTERVAL=100
CONFIG_KFENCE_NUM_OBJECTS=255
# CONFIG_KFENCE_DEFERRABLE is not set
CONFIG_KFENCE_STRESS_TEST_FAULTS=0

Quoted 54 lines
Quoted 18 lines
Quoted 17 lines

boot logs:
--------

[    0.000000] Booting Linux on physical CPU 0x0000000000 [0x000f0510]
[    0.000000] Linux version 6.4.5-rc1 (tuxmake@tuxmake)
(aarch64-linux-gnu-gcc (Debian 12.2.0-14) 12.2.0, GNU ld (GNU Binutils
for Debian) 2.40) #1 SMP PREEMPT @1689957802
[    0.000000] random: crng init done
[    0.000000] Machine model: linux,dummy-virt
...
[    0.006821] kfence: initialized - using 33554432 bytes for 255
objects at 0x(____ptrval____)-0x(____ptrval____)
...
[    7.726994] ------------[ cut here ]------------
[    7.727704] WARNING: CPU: 1 PID: 1 at mm/kfence/core.c:1097

__kfence_free+0x84/0xc8

...

Quoted 13 lines
Quoted 5 lines
[    7.746478] Call trace:
[    7.746776]  __kfence_free+0x84/0xc8
[    7.747134]  __slab_free+0x490/0x508
[    7.748063]  __kmem_cache_free+0x2b4/0x2d0
[    7.748377]  kfree+0x78/0x140
Quoted 8 lines
[    7.748638]  single_release+0x40/0x60
[    7.750664]  __fput+0x78/0x260
[    7.751065]  ____fput+0x18/0x30
[    7.752086]  task_work_run+0x80/0xe0
[    7.753122]  do_notify_resume+0x200/0x1398
[    7.754292]  el0_svc+0xec/0x100
[    7.754573]  el0t_64_sync_handler+0xf4/0x120
[    7.755559]  el0t_64_sync+0x190/0x198

It would be interesting to see the contents of /sys/kernel/debug/kfence/objects together with the object address. Would it be possible to boot the kernel with no_hash_pointers and add a line printing the object address:

mm/kfence/core.c +4 -1
index dad3c0eb70a01..23f27f6cb18cf 100644
@@ -1094,7 +1094,10 @@ void __kfence_free(void *addr)
        struct kfence_metadata *meta = addr_to_metadata((unsigned long)addr);
 
 #ifdef CONFIG_MEMCG
-       KFENCE_WARN_ON(meta->objcg);
+       if (meta->objcg) {
+               pr_err("ADDR: %px\n", addr);
+               KFENCE_WARN_ON(1);
+       }
 #endif
        /*
         * If the objects of the cache are SLAB_TYPESAFE_BY_RCU, defer freeing
Quoted 5 lines
Quoted 2 lines

, and then dump /sys/kernel/debug/kfence/objects?

This testing is running on CI loops and however, I will try to reproduce this locally.

I have applied the above debug patch and tested in a loop but the issues did not reproduce yet.

- Naresh

maintainer
#308 lore raw
In reply to Naresh Kamboju
Quoted 29 lines · Naresh Kamboju
Quoted 27 lines · Alexander Potapenko
Quoted 23 lines · Linus Torvalds

[ Removed the stable reviewers, bringing in the kfence people ]

See

https://lore.kernel.org/lkml/CA+G9fYvgy22wiY=c3wLOrCM6o33636abhtEynXhJkqxJh4ca0A@mail.gmail.com/

for the original report. The warning was introduced in 8f0b36497303 ("mm: kfence: fix objcgs vector allocation"), and Google doesn't find any other cases of this.

Anybody?

Linus

Quoted 6 lines

NOTE:
The following kernel warning was noticed while booting qemu-arm64 with these configs enabled on stable rc 6.4.5-rc1.

CONFIG_ARM64_64K_PAGES=y
CONFIG_KFENCE=y

Quoted 8 lines
Quoted 1 line

Is there a full config somewhere?

Please find build details
- https://storage.tuxsuite.com/public/linaro/lkft/builds/2StEPFnEfoD076PRu8fIxjexhnM/
- https://storage.tuxsuite.com/public/linaro/lkft/builds/2StEPFnEfoD076PRu8fIxjexhnM/config
- https://storage.tuxsuite.com/public/linaro/lkft/builds/2StEPFnEfoD076PRu8fIxjexhnM/vmlinux.xz
- https://storage.tuxsuite.com/public/linaro/lkft/builds/2StEPFnEfoD076PRu8fIxjexhnM/System.map
- https://storage.tuxsuite.com/public/linaro/lkft/builds/2StEPFnEfoD076PRu8fIxjexhnM/Image.gz

I am afraid it still doesn't help much.
I installed tuxmake into a virtualenv and tried running:

 $ tuxmake --runtime podman --target-arch arm64 --toolchain gcc-12
--kconfig https://storage.tuxsuite.com/public/linaro/lkft/builds/2StEPFnEfoD076PRu8fIxjexhnM/config

, but after downloading some Docker stuff it died with the following error:

Error: copying system image from manifest list: writing blob: adding layer with blob "sha256:faef57eae888cbe4a5613eca6741b5e48d768b83f6088858aee9a5a2834f8151":
processing tar file(potentially insufficient UIDs or GIDs available in user namespace (requested 0:42 for /etc/gshadow): Check /etc/subuid and /etc/subgid if configured locally and run podman-system-migrate:
lchown /etc/gshadow: invalid argument): exit status 1

I also tried building with the config you provided, but the resulting kernel didn't boot with my existing rootfs.

The third attempt was to take a config that's known to work, and enable CONFIG_ARM64_64K_PAGES=y in it, and boot on a rootfs that's known to work, but it didn't boot either, claiming that "/sbin/init exists but couldn't execute it".

Are there any additional requirements to rootfs related to 64k pages? Or maybe there's a system image somewhere at tuxsite.com that I can use?

maintainer
#309 lore raw
Quoted 41 lines · Alexander Potapenko
Quoted 29 lines · Naresh Kamboju
Quoted 27 lines · Alexander Potapenko
Quoted 23 lines · Linus Torvalds

[ Removed the stable reviewers, bringing in the kfence people ]

See

https://lore.kernel.org/lkml/CA+G9fYvgy22wiY=c3wLOrCM6o33636abhtEynXhJkqxJh4ca0A@mail.gmail.com/

for the original report. The warning was introduced in 8f0b36497303 ("mm: kfence: fix objcgs vector allocation"), and Google doesn't find any other cases of this.

Anybody?

Linus

Quoted 6 lines

NOTE:
The following kernel warning was noticed while booting qemu-arm64 with these configs enabled on stable rc 6.4.5-rc1.

CONFIG_ARM64_64K_PAGES=y
CONFIG_KFENCE=y

Quoted 8 lines
Quoted 1 line

Is there a full config somewhere?

Please find build details
- https://storage.tuxsuite.com/public/linaro/lkft/builds/2StEPFnEfoD076PRu8fIxjexhnM/
- https://storage.tuxsuite.com/public/linaro/lkft/builds/2StEPFnEfoD076PRu8fIxjexhnM/config
- https://storage.tuxsuite.com/public/linaro/lkft/builds/2StEPFnEfoD076PRu8fIxjexhnM/vmlinux.xz
- https://storage.tuxsuite.com/public/linaro/lkft/builds/2StEPFnEfoD076PRu8fIxjexhnM/System.map
- https://storage.tuxsuite.com/public/linaro/lkft/builds/2StEPFnEfoD076PRu8fIxjexhnM/Image.gz

Quoted 2 lines

I am afraid it still doesn't help much.
I installed tuxmake into a virtualenv and tried running:

Ok, my buildroot indeed lacked the BR2_ARM64_PAGE_SIZE_64K. I am now able to boot a kernel with your config, trying to reproduce the problem locally...

#310 lore raw
Quoted 43 lines · Alexander Potapenko
Quoted 41 lines · Alexander Potapenko
Quoted 37 lines · Naresh Kamboju
Quoted 20 lines · Alexander Potapenko
Quoted 15 lines · Linus Torvalds

[ Removed the stable reviewers, bringing in the kfence people ]

See

https://lore.kernel.org/lkml/CA+G9fYvgy22wiY=c3wLOrCM6o33636abhtEynXhJkqxJh4ca0A@mail.gmail.com/

for the original report. The warning was introduced in 8f0b36497303 ("mm: kfence: fix objcgs vector allocation"), and Google doesn't find any other cases of this.

Anybody?

Linus

Quoted 8 lines
Quoted 6 lines
Quoted 6 lines

NOTE:
The following kernel warning was noticed while booting qemu-arm64 with these configs enabled on stable rc 6.4.5-rc1.

CONFIG_ARM64_64K_PAGES=y
CONFIG_KFENCE=y

Is there a full config somewhere?

Please find build details
- https://storage.tuxsuite.com/public/linaro/lkft/builds/2StEPFnEfoD076PRu8fIxjexhnM/
- https://storage.tuxsuite.com/public/linaro/lkft/builds/2StEPFnEfoD076PRu8fIxjexhnM/config
- https://storage.tuxsuite.com/public/linaro/lkft/builds/2StEPFnEfoD076PRu8fIxjexhnM/vmlinux.xz
- https://storage.tuxsuite.com/public/linaro/lkft/builds/2StEPFnEfoD076PRu8fIxjexhnM/System.map
- https://storage.tuxsuite.com/public/linaro/lkft/builds/2StEPFnEfoD076PRu8fIxjexhnM/Image.gz

Quoted 5 lines
Quoted 2 lines

I am afraid it still doesn't help much.
I installed tuxmake into a virtualenv and tried running:

Ok, my buildroot indeed lacked the BR2_ARM64_PAGE_SIZE_64K. I am now able to boot a kernel with your config, trying to reproduce the problem locally...

Great to know that, boot successfully with a 64k page size kernel image.

- Naresh

maintainer
#311 lore raw
Quoted 23 lines · Naresh Kamboju
Quoted 21 lines · Alexander Potapenko
Quoted 19 lines · Alexander Potapenko
Quoted 16 lines · Naresh Kamboju
Quoted 14 lines · Alexander Potapenko
Quoted 11 lines · Linus Torvalds

[ Removed the stable reviewers, bringing in the kfence people ]

See

https://lore.kernel.org/lkml/CA+G9fYvgy22wiY=c3wLOrCM6o33636abhtEynXhJkqxJh4ca0A@mail.gmail.com/

for the original report. The warning was introduced in 8f0b36497303 ("mm: kfence: fix objcgs vector allocation"), and Google doesn't find any other cases of this.

Quoted 5 lines
Quoted 5 lines
Quoted 5 lines
Quoted 5 lines
Quoted 5 lines
Quoted 4 lines

Anybody?

Linus

Muchun, any chance you know under what circumstances a KFENCE object has its meta->objcg set to a non-NULL value?
It seems to be a quite rare case, and I've only seen it in live radix_tree_node objects.
Since the check here:
https://elixir.bootlin.com/linux/latest/source/mm/kfence/core.c#L1097
ensures that this value is NULL when the object is freed, where is the code that is supposed to zero it?
Could there be a race somewhere?

maintainer
#312 lore raw
Quoted 32 lines · Alexander Potapenko
Quoted 23 lines · Naresh Kamboju
Quoted 21 lines · Alexander Potapenko
Quoted 19 lines · Alexander Potapenko
Quoted 16 lines · Naresh Kamboju
Quoted 14 lines · Alexander Potapenko
Quoted 11 lines · Linus Torvalds

[ Removed the stable reviewers, bringing in the kfence people ]

See

https://lore.kernel.org/lkml/CA+G9fYvgy22wiY=c3wLOrCM6o33636abhtEynXhJkqxJh4ca0A@mail.gmail.com/

for the original report. The warning was introduced in 8f0b36497303 ("mm: kfence: fix objcgs vector allocation"), and Google doesn't find any other cases of this.

Quoted 5 lines
Quoted 5 lines
Quoted 5 lines
Quoted 5 lines
Quoted 5 lines
Quoted 4 lines

Anybody?

Linus

Quoted 9 lines

Muchun, any chance you know under what circumstances a KFENCE object has its meta->objcg set to a non-NULL value?
It seems to be a quite rare case, and I've only seen it in live radix_tree_node objects.
Since the check here:
https://elixir.bootlin.com/linux/latest/source/mm/kfence/core.c#L1097
ensures that this value is NULL when the object is freed, where is the code that is supposed to zero it?
Could there be a race somewhere?

I am still puzzled about what is going on.

As far as I can see, when KFENCE pool is initialized, for ith object page in the pool its page_slab()->memcg_data is set to a value derived from kfence_metadata[i].objcg
Because KFENCE objects always occupy one page, no two objects are expected to share memcg_data at any time.

When slab_alloc_node() is called, it first invokes slab_pre_alloc_hook(), figures out the obj_cgroup and charges it for the allocated memory. The obj_cgroup is returned to slab_alloc_node() and after KFENCE allocation succeeds is passed to slab_post_alloc_hook(), which then writes obj_cgroup to *(page_slab(object)->memcg_data).

When an object is deallocated, slab_free() calls memcg_slab_free_hook(), which zeroes *(page_slab(object)->memcg_data) and passes the object to kfence_free().
At this point the object's meta->objcg must be NULL, so the warning should not be firing.

--
Alexander Potapenko
Software Engineer

Google Germany GmbH
Erika-Mann-Straße, 33
80636 München

Geschäftsführer: Paul Manicle, Liana Sebastian
Registergericht und -nummer: Hamburg, HRB 86891
Sitz der Gesellschaft: Hamburg

#313 lore raw
Quoted 63 lines · Alexander Potapenko
Quoted 32 lines · Alexander Potapenko
Quoted 23 lines · Naresh Kamboju
Quoted 21 lines · Alexander Potapenko
Quoted 19 lines · Alexander Potapenko
Quoted 16 lines · Naresh Kamboju
Quoted 14 lines · Alexander Potapenko
Quoted 11 lines · Linus Torvalds

[ Removed the stable reviewers, bringing in the kfence people ]

See

https://lore.kernel.org/lkml/CA+G9fYvgy22wiY=c3wLOrCM6o33636abhtEynXhJkqxJh4ca0A@mail.gmail.com/

for the original report. The warning was introduced in 8f0b36497303 ("mm: kfence: fix objcgs vector allocation"), and Google doesn't find any other cases of this.

Quoted 5 lines
Quoted 5 lines
Quoted 5 lines
Quoted 5 lines
Quoted 5 lines
Quoted 4 lines

Anybody?

Linus

Quoted 9 lines

Muchun, any chance you know under what circumstances a KFENCE object has its meta->objcg set to a non-NULL value?
It seems to be a quite rare case, and I've only seen it in live radix_tree_node objects.
Since the check here:
https://elixir.bootlin.com/linux/latest/source/mm/kfence/core.c#L1097
ensures that this value is NULL when the object is freed, where is the code that is supposed to zero it?
Could there be a race somewhere?

I am still puzzled about what is going on.

As far as I can see, when KFENCE pool is initialized, for ith object page in the pool its page_slab()->memcg_data is set to a value derived from kfence_metadata[i].objcg
Because KFENCE objects always occupy one page, no two objects are expected to share memcg_data at any time.

When slab_alloc_node() is called, it first invokes slab_pre_alloc_hook(), figures out the obj_cgroup and charges it for the allocated memory. The obj_cgroup is returned to slab_alloc_node() and after KFENCE allocation succeeds is passed to slab_post_alloc_hook(), which then writes obj_cgroup to *(page_slab(object)->memcg_data).

Quoted 5 lines

When an object is deallocated, slab_free() calls memcg_slab_free_hook(), which zeroes *(page_slab(object)->memcg_data) and passes the object to kfence_free().
At this point the object's meta->objcg must be NULL, so the warning should not be firing.

At least, totally agree. This call stack comes from slab_free() which makes sure memcg_slab_free_hook() is called before kfence_free(), so meta->objcg must be NULL. Otherwise, seems something is corrupted. So I really want to know what's the value of "meta->objcg" when the warning is firing (e.g. whether it is a valid pointer or does the last bit is set with MEMCG_DATA_OBJCGS). Maybe we could improve the warning message, e.g. print the current value of "meta->objcg".

Thanks.

#314 lore raw
Quoted 73 lines · Muchun Song
Quoted 64 lines · Alexander Potapenko
Quoted 32 lines · Alexander Potapenko
Quoted 23 lines · Naresh Kamboju
Quoted 21 lines · Alexander Potapenko
Quoted 19 lines · Alexander Potapenko
Quoted 16 lines · Naresh Kamboju
Quoted 14 lines · Alexander Potapenko
Quoted 11 lines · Linus Torvalds

[ Removed the stable reviewers, bringing in the kfence people ]

See

https://lore.kernel.org/lkml/CA+G9fYvgy22wiY=c3wLOrCM6o33636abhtEynXhJkqxJh4ca0A@mail.gmail.com/

for the original report. The warning was introduced in 8f0b36497303 ("mm: kfence: fix objcgs vector allocation"), and Google doesn't find any other cases of this.

Quoted 5 lines
Quoted 5 lines
Quoted 5 lines
Quoted 5 lines
Quoted 5 lines
Quoted 4 lines

Anybody?

Linus

Quoted 9 lines

Muchun, any chance you know under what circumstances a KFENCE object has its meta->objcg set to a non-NULL value?
It seems to be a quite rare case, and I've only seen it in live radix_tree_node objects.
Since the check here:
https://elixir.bootlin.com/linux/latest/source/mm/kfence/core.c#L1097
ensures that this value is NULL when the object is freed, where is the code that is supposed to zero it?
Could there be a race somewhere?

I am still puzzled about what is going on.

As far as I can see, when KFENCE pool is initialized, for ith object page in the pool its page_slab()->memcg_data is set to a value derived from kfence_metadata[i].objcg
Because KFENCE objects always occupy one page, no two objects are expected to share memcg_data at any time.

When slab_alloc_node() is called, it first invokes slab_pre_alloc_hook(), figures out the obj_cgroup and charges it for the allocated memory. The obj_cgroup is returned to slab_alloc_node() and after KFENCE allocation succeeds is passed to slab_post_alloc_hook(), which then writes obj_cgroup to *(page_slab(object)->memcg_data).

Quoted 5 lines

When an object is deallocated, slab_free() calls memcg_slab_free_hook(), which zeroes *(page_slab(object)->memcg_data) and passes the object to kfence_free().
At this point the object's meta->objcg must be NULL, so the warning should not be firing.

Quoted 6 lines

At least, totally agree. This call stack comes from slab_free() which makes sure memcg_slab_free_hook() is called before kfence_free(), so meta->objcg must be NULL. Otherwise, seems something is corrupted. So I really want to know what's the value of "meta->objcg" when the warning is firing (e.g. whether it is a valid pointer or does the last bit is set with MEMCG_DATA_OBJCGS). Maybe we could improve the warning message,

Sorry for the confusing, meta->objcg should be a objcg pointer, it cannot be set with MEMCG_DATA_OBJCGS.

Quoted 3 lines

e.g. print the current value of "meta->objcg".

Thanks.

#315 lore raw
In reply to Alexander Potapenko
Quoted 49 lines · Alexander Potapenko
Quoted 29 lines · Naresh Kamboju
Quoted 27 lines · Alexander Potapenko
Quoted 23 lines · Linus Torvalds

[ Removed the stable reviewers, bringing in the kfence people ]

See

https://lore.kernel.org/lkml/CA+G9fYvgy22wiY=c3wLOrCM6o33636abhtEynXhJkqxJh4ca0A@mail.gmail.com/

for the original report. The warning was introduced in 8f0b36497303 ("mm: kfence: fix objcgs vector allocation"), and Google doesn't find any other cases of this.

Anybody?

Linus

Quoted 6 lines

NOTE:
The following kernel warning was noticed while booting qemu-arm64 with these configs enabled on stable rc 6.4.5-rc1.

CONFIG_ARM64_64K_PAGES=y
CONFIG_KFENCE=y

Quoted 8 lines
Quoted 1 line

Is there a full config somewhere?

Please find build details
- https://storage.tuxsuite.com/public/linaro/lkft/builds/2StEPFnEfoD076PRu8fIxjexhnM/
- https://storage.tuxsuite.com/public/linaro/lkft/builds/2StEPFnEfoD076PRu8fIxjexhnM/config
- https://storage.tuxsuite.com/public/linaro/lkft/builds/2StEPFnEfoD076PRu8fIxjexhnM/vmlinux.xz
- https://storage.tuxsuite.com/public/linaro/lkft/builds/2StEPFnEfoD076PRu8fIxjexhnM/System.map
- https://storage.tuxsuite.com/public/linaro/lkft/builds/2StEPFnEfoD076PRu8fIxjexhnM/Image.gz

I am afraid it still doesn't help much.
I installed tuxmake into a virtualenv and tried running:

 $ tuxmake --runtime podman --target-arch arm64 --toolchain gcc-12
--kconfig https://storage.tuxsuite.com/public/linaro/lkft/builds/2StEPFnEfoD076PRu8fIxjexhnM/config

, but after downloading some Docker stuff it died with the following error:

Quoted 7 lines

Error: copying system image from manifest list: writing blob: adding layer with blob "sha256:faef57eae888cbe4a5613eca6741b5e48d768b83f6088858aee9a5a2834f8151":
processing tar file(potentially insufficient UIDs or GIDs available in user namespace (requested 0:42 for /etc/gshadow): Check /etc/subuid and /etc/subgid if configured locally and run podman-system-migrate:
lchown /etc/gshadow: invalid argument): exit status 1

This might helpful,

# Some images require this range in the user namespace

echo "{username}:4000:165535" > /etc/subuid
echo "{username}:4000:165535" > /etc/subgid

Replace {username} with the username in your machine.

- Naresh

Tested-by on the v1 series
#316 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.4.5 release. There are 292 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 Sun, 23 Jul 2023 16:04:29 +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.4.5-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.4.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
Tested-by on the v1 series
#317 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.4.5 release. There are 292 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 Sun, 23 Jul 2023 16:04:29 +0000. Anything received after that time might be too late.

Build results:

	total: 157 pass: 157 fail: 0
Qemu test results:
	total: 523 pass: 523 fail: 0
Tested-by Guenter Roeck <[email protected]>

Guenter

maintainer Tested-by on the v1 series
#318 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.4.5 release. There are 292 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 Sun, 23 Jul 2023 16:04:29 +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.4.5-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.4.y
and the diffstat can be found below.

thanks,

greg k-h

All tests passing for Tegra ...

Test results for stable-v6.4:

    11 builds:	11 pass, 0 fail
    28 boots:	28 pass, 0 fail
    130 tests:	130 pass, 0 fail

Linux version: 6.4.5-rc1-g698271d38e0b
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