Skip to contentSkip to conversation

nvme-fc: go straight to connecting state when initializing

PATCH New Sasha Levin 1 participant 6 messages Feb 11, 2025

Subsystems (4)
Stable branch SCSI ACPI NVMe
lore
Share & tools
lore

Sasha Levin

author maintainer
#0 lore raw

PATCH 1/6 nvme-fc: go straight to connecting state when initializing

From: Daniel Wagner <[email protected]>

[ Upstream commit d3d380eded7ee5fc2fc53b3b0e72365ded025c4a ]

The initial controller initialization mimiks the reconnect loop behavior by switching from NEW to RESETTING and then to CONNECTING.

The transition from NEW to CONNECTING is a valid transition, so there is no point entering the RESETTING state. TCP and RDMA also transition directly to CONNECTING state.

Reviewed-by Sagi Grimberg <[email protected]>
Reviewed-by Hannes Reinecke <[email protected]>
Reviewed-by Christoph Hellwig <[email protected]>
Signed-off-by Daniel Wagner <[email protected]>
Signed-off-by Keith Busch <[email protected]>
Signed-off-by Sasha Levin <[email protected]>
---
 drivers/nvme/host/fc.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)
drivers/nvme/host/fc.c +1 -2
index 0d2c22cf12a08..f3c0bff714eba 100644
@@ -3164,8 +3164,7 @@ nvme_fc_init_ctrl(struct device *dev, struct nvmf_ctrl_options *opts,
 	list_add_tail(&ctrl->ctrl_list, &rport->ctrl_list);
 	spin_unlock_irqrestore(&rport->lock, flags);
 
-	if (!nvme_change_ctrl_state(&ctrl->ctrl, NVME_CTRL_RESETTING) ||
-	    !nvme_change_ctrl_state(&ctrl->ctrl, NVME_CTRL_CONNECTING)) {
+	if (!nvme_change_ctrl_state(&ctrl->ctrl, NVME_CTRL_CONNECTING)) {
 		dev_err(ctrl->ctrl.device,
 			"NVME-FC{%d}: failed to init ctrl state\n", ctrl->cnum);
 		goto fail_ctrl;
Signature · 1 line
2.39.5
author maintainer
#1 lore raw

PATCH 2/6 hrtimers: Mark is_migration_base() with __always_inline

From: Andy Shevchenko <[email protected]>

[ Upstream commit 27af31e44949fa85550176520ef7086a0d00fd7b ]

When is_migration_base() is unused, it prevents kernel builds with clang, make W=1 and CONFIG_WERROR=y:

kernel/time/hrtimer.c:156:20: error: unused function 'is_migration_base' [-Werror,-Wunused-function]
156 | static inline bool is_migration_base(struct hrtimer_clock_base *base)

      |                    ^~~~~~~~~~~~~~~~~

Fix this by marking it with __always_inline.

[ tglx: Use __always_inline instead of __maybe_unused and move it into the
usage sites conditional ]

Signed-off-by Andy Shevchenko <[email protected]>
Signed-off-by Thomas Gleixner <[email protected]>
Link https://lore.kernel.org/all/[email protected] open here
Signed-off-by Sasha Levin <[email protected]>
---
 kernel/time/hrtimer.c | 22 ++++++++++++----------
 1 file changed, 12 insertions(+), 10 deletions(-)
kernel/time/hrtimer.c +12 -10
index 539bc80787eeb..69713fa32437b 100644
@@ -140,11 +140,6 @@ static struct hrtimer_cpu_base migration_cpu_base = {
 
 #define migration_base	migration_cpu_base.clock_base[0]
 
-static inline bool is_migration_base(struct hrtimer_clock_base *base)
-{
-	return base == &migration_base;
-}
-
 /*
  * We are using hashed locking: holding per_cpu(hrtimer_bases)[n].lock
  * means that all timers which are tied to this base via timer->base are

@@ -269,11 +264,6 @@ switch_hrtimer_base(struct hrtimer *timer, struct hrtimer_clock_base *base,
 
 #else /* CONFIG_SMP */
 
-static inline bool is_migration_base(struct hrtimer_clock_base *base)
-{
-	return false;
-}
-
 static inline struct hrtimer_clock_base *
 lock_hrtimer_base(const struct hrtimer *timer, unsigned long *flags)
 {

@@ -1276,6 +1266,18 @@ static void hrtimer_sync_wait_running(struct hrtimer_cpu_base *cpu_base,
 	}
 }
 
+#ifdef CONFIG_SMP
+static __always_inline bool is_migration_base(struct hrtimer_clock_base *base)
+{
+	return base == &migration_base;
+}
+#else
+static __always_inline bool is_migration_base(struct hrtimer_clock_base *base)
+{
+	return false;
+}
+#endif
+
 /*
  * This function is called on PREEMPT_RT kernels when the fast path
  * deletion of a timer failed because the timer callback function was
Signature · 1 line
2.39.5
author maintainer
#2 lore raw

PATCH 3/6 powercap: call put_device() on an error path in powercap_register_control_type()

In reply to Sasha Levin

From: Joe Hattori <[email protected]>

[ Upstream commit 93c66fbc280747ea700bd6199633d661e3c819b3 ]

powercap_register_control_type() calls device_register(), but does not release the refcount of the device when it fails.

Call put_device() before returning an error to balance the refcount.

Since the kfree(control_type) will be done by powercap_release(), remove the lines in powercap_register_control_type() before returning the error.

This bug was found by an experimental verifier that I am developing.

Signed-off-by Joe Hattori <[email protected]>
Link https://patch.msgid.link/[email protected] open here
[ rjw: Changelog edits ]
Signed-off-by Rafael J. Wysocki <[email protected]>
Signed-off-by Sasha Levin <[email protected]>
---
 drivers/powercap/powercap_sys.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)
drivers/powercap/powercap_sys.c +1 -2
index 7a3109a538813..fe5d05da7ce7a 100644
@@ -627,8 +627,7 @@ struct powercap_control_type *powercap_register_control_type(
 	dev_set_name(&control_type->dev, "%s", name);
 	result = device_register(&control_type->dev);
 	if (result) {
-		if (control_type->allocated)
-			kfree(control_type);
+		put_device(&control_type->dev);
 		return ERR_PTR(result);
 	}
 	idr_init(&control_type->idr);
Signature · 1 line
2.39.5
author maintainer
#3 lore raw

PATCH 4/6 iscsi_ibft: Fix UBSAN shift-out-of-bounds warning in ibft_attr_show_nic()

In reply to Sasha Levin

From: Chengen Du <[email protected]>

[ Upstream commit 07e0d99a2f701123ad3104c0f1a1e66bce74d6e5 ]

When performing an iSCSI boot using IPv6, iscsistart still reads the /sys/firmware/ibft/ethernetX/subnet-mask entry. Since the IPv6 prefix length is 64, this causes the shift exponent to become negative, triggering a UBSAN warning. As the concept of a subnet mask does not apply to IPv6, the value is set to ~0 to suppress the warning message.

Signed-off-by Chengen Du <[email protected]>
Signed-off-by Konrad Rzeszutek Wilk <[email protected]>
Signed-off-by Sasha Levin <[email protected]>
---
 drivers/firmware/iscsi_ibft.c | 5 ++++-
 1 file changed, 4 insertions(+), 1 deletion(-)
drivers/firmware/iscsi_ibft.c +4 -1
index 7e12cbdf957cc..daf42b5319e89 100644
@@ -311,7 +311,10 @@ static ssize_t ibft_attr_show_nic(void *data, int type, char *buf)
 		str += sprintf_ipaddr(str, nic->ip_addr);
 		break;
 	case ISCSI_BOOT_ETH_SUBNET_MASK:
-		val = cpu_to_be32(~((1 << (32-nic->subnet_mask_prefix))-1));
+		if (nic->subnet_mask_prefix > 32)
+			val = cpu_to_be32(~0);
+		else
+			val = cpu_to_be32(~((1 << (32-nic->subnet_mask_prefix))-1));
 		str += sprintf(str, "%pI4", &val);
 		break;
 	case ISCSI_BOOT_ETH_PREFIX_LEN:
Signature · 1 line
2.39.5
author maintainer
#4 lore raw

PATCH 5/6 scsi: qla1280: Fix kernel oops when debug level > 2

In reply to Sasha Levin

From: Magnus Lindholm <[email protected]>

[ Upstream commit 5233e3235dec3065ccc632729675575dbe3c6b8a ]

A null dereference or oops exception will eventually occur when qla1280.c driver is compiled with DEBUG_QLA1280 enabled and ql_debug_level > 2. I think its clear from the code that the intention here is sg_dma_len(s) not length of sg_next(s) when printing the debug info.

Signed-off-by Magnus Lindholm <[email protected]>
Link https://lore.kernel.org/r/[email protected] open here
Signed-off-by Martin K. Petersen <[email protected]>
Signed-off-by Sasha Levin <[email protected]>
---
 drivers/scsi/qla1280.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/scsi/qla1280.c +1 -1
index 832af42130467..a13db27b04ede 100644
@@ -2871,7 +2871,7 @@ qla1280_64bit_start_scsi(struct scsi_qla_host *ha, struct srb * sp)
 			dprintk(3, "S/G Segment phys_addr=%x %x, len=0x%x\n",
 				cpu_to_le32(upper_32_bits(dma_handle)),
 				cpu_to_le32(lower_32_bits(dma_handle)),
-				cpu_to_le32(sg_dma_len(sg_next(s))));
+				cpu_to_le32(sg_dma_len(s)));
 			remseg--;
 		}
 		dprintk(5, "qla1280_64bit_start_scsi: Scatter/gather "
Signature · 1 line
2.39.5
author maintainer
#5 lore raw

PATCH 6/6 ACPI: resource: IRQ override for Eluktronics MECH-17

In reply to Sasha Levin

From: Gannon Kolding <[email protected]>

[ Upstream commit 607ab6f85f4194b644ea95ac5fe660ef575db3b4 ]

The Eluktronics MECH-17 (GM7RG7N) needs IRQ overriding for the keyboard to work.

Adding a DMI_MATCH entry for this laptop model makes the internal keyboard function normally.

Signed-off-by Gannon Kolding <[email protected]>
Link https://patch.msgid.link/[email protected] open here
Signed-off-by Rafael J. Wysocki <[email protected]>
Signed-off-by Sasha Levin <[email protected]>
---
 drivers/acpi/resource.c | 6 ++++++
 1 file changed, 6 insertions(+)
drivers/acpi/resource.c +6 -0
index 2750518a5d5e1..11264bb4061e7 100644
@@ -482,6 +482,12 @@ static const struct dmi_system_id asus_laptop[] = {
 			DMI_MATCH(DMI_BOARD_NAME, "RP-15"),
 		},
 	},
+	{
+		.matches = {
+			DMI_MATCH(DMI_SYS_VENDOR, "Eluktronics Inc."),
+			DMI_MATCH(DMI_BOARD_NAME, "MECH-17"),
+		},
+	},
 	{
 		/* TongFang GM6XGxX/TUXEDO Stellaris 16 Gen5 AMD */
 		.matches = {
Signature · 1 line
2.39.5