[PATCH v4 0/3] Fix control flow in sas_ex_add_parent_port()

[PATCH v4 0/3] Fix control flow in sas_ex_add_parent_port()

[Eshaan Deshmukh]

Fix label control flow for the function sas_ex_add_parent_port(). Remove
labels and move the code back to their original places.

Eshaan Deshmukh (3):
  scsi: libsas: Handle errors in sas_ex_add_parent_port()
  scsi: libsas: Handle errors in sas_set_ex_phy()
  scsi: libsas: Handle errors in  sas_ex_discover_expander()

 drivers/scsi/libsas/sas_expander.c | 75 ++++++++++++++++++++----------
 1 file changed, 50 insertions(+), 25 deletions(-)

-- 
2.55.0

[PATCH v4 1/3] scsi: libsas: Handle errors in sas_ex_add_parent_port()

[Eshaan Deshmukh]

The function sas_ex_add_parent_port() uses BUG_ON() if sas_port_alloc()
or sas_port_add() fails. Change sas_ex_add_parent_port() to return error
codes to the caller and free the sas_port_alloc() allocation. Also
change sas_ex_discover_dev() to handle errors returned by
sas_ex_add_parent_port().

Signed-off-by: Eshaan Deshmukh <eshaan2031@icloud.com>
---
 drivers/scsi/libsas/sas_expander.c | 30 +++++++++++++++++++++---------
 1 file changed, 21 insertions(+), 9 deletions(-)

diff --git a/drivers/scsi/libsas/sas_expander.c b/drivers/scsi/libsas/sas_expander.c
index f471ab464..f1a1417b0 100644
--- a/drivers/scsi/libsas/sas_expander.c
+++ b/drivers/scsi/libsas/sas_expander.c
@@ -33,19 +33,29 @@ static void sas_port_add_ex_phy(struct sas_port *port, struct ex_phy *ex_phy)
 	ex_phy->phy_state = PHY_DEVICE_DISCOVERED;
 }
 
-static void sas_ex_add_parent_port(struct domain_device *dev, int phy_id)
+static int sas_ex_add_parent_port(struct domain_device *dev, int phy_id)
 {
 	struct expander_device *ex = &dev->ex_dev;
 	struct ex_phy *ex_phy = &ex->ex_phy[phy_id];
+	int error;
 
 	if (!ex->parent_port) {
 		ex->parent_port = sas_port_alloc(&dev->rphy->dev, phy_id);
-		/* FIXME: error handling */
-		BUG_ON(!ex->parent_port);
-		BUG_ON(sas_port_add(ex->parent_port));
+		if (!ex->parent_port)
+			return -ENOMEM;
+
+		error = sas_port_add(ex->parent_port);
+		if (error) {
+			sas_port_free(ex->parent_port);
+			ex->parent_port = NULL;
+			return error;
+		}
+
 		sas_port_mark_backlink(ex->parent_port);
 	}
 	sas_port_add_ex_phy(ex->parent_port, ex_phy);
+
+	return 0;
 }
 
 /* ---------- SMP task management ---------- */
@@ -981,12 +991,14 @@ static int sas_ex_discover_dev(struct domain_device *dev, int phy_id)
 	}
 
 	/* Parent and domain coherency */
-	if (!dev->parent && sas_phy_match_port_addr(dev->port, ex_phy)) {
-		sas_ex_add_parent_port(dev, phy_id);
-		return 0;
-	}
+	if (!dev->parent && sas_phy_match_port_addr(dev->port, ex_phy))
+		return sas_ex_add_parent_port(dev, phy_id);
+
 	if (dev->parent && sas_phy_match_dev_addr(dev->parent, ex_phy)) {
-		sas_ex_add_parent_port(dev, phy_id);
+		res = sas_ex_add_parent_port(dev, phy_id);
+		if (res)
+			return res;
+
 		if (ex_phy->routing_attr == TABLE_ROUTING)
 			sas_configure_phy(dev, phy_id, dev->port->sas_addr, 1);
 		return 0;
-- 
2.55.0

[PATCH v4 2/3] scsi: libsas: Handle errors in sas_set_ex_phy()

[Eshaan Deshmukh]

The function sas_set_ex_phy() uses BUG_ON() if sas_phy_alloc() fails.
Change it to return -ENOMEM error code if that happens. Change all the
other returns in sas_set_ex_phy() to return 0 to preserve current
functionality, or to return an error. Change all uses of sas_set_ex_phy
to handle the returned error codes.

Signed-off-by: Eshaan Deshmukh <eshaan2031@icloud.com>
---
 drivers/scsi/libsas/sas_expander.c | 28 +++++++++++++++++-----------
 1 file changed, 17 insertions(+), 11 deletions(-)

diff --git a/drivers/scsi/libsas/sas_expander.c b/drivers/scsi/libsas/sas_expander.c
index f1a1417b0..ab6afbad3 100644
--- a/drivers/scsi/libsas/sas_expander.c
+++ b/drivers/scsi/libsas/sas_expander.c
@@ -207,7 +207,7 @@ static enum sas_device_type to_dev_type(struct discover_resp *dr)
 		return dr->attached_dev_type;
 }
 
-static void sas_set_ex_phy(struct domain_device *dev, int phy_id,
+static int sas_set_ex_phy(struct domain_device *dev, int phy_id,
 			   struct smp_disc_resp *disc_resp)
 {
 	enum sas_device_type dev_type;
@@ -220,14 +220,15 @@ static void sas_set_ex_phy(struct domain_device *dev, int phy_id,
 	struct sas_rphy *rphy = dev->rphy;
 	bool new_phy = !phy->phy;
 	char *type;
+	int error;
 
 	if (new_phy) {
 		if (WARN_ON_ONCE(test_bit(SAS_HA_ATA_EH_ACTIVE, &ha->state)))
-			return;
+			return -EBUSY;
 		phy->phy = sas_phy_alloc(&rphy->dev, phy_id);
 
-		/* FIXME: error_handling */
-		BUG_ON(!phy->phy);
+		if (!phy->phy)
+			return -ENOMEM;
 	}
 
 	switch (disc_resp->result) {
@@ -296,11 +297,14 @@ static void sas_set_ex_phy(struct domain_device *dev, int phy_id,
 	phy->phy->enabled = (phy->linkrate != SAS_PHY_DISABLED);
 
  skip:
-	if (new_phy)
-		if (sas_phy_add(phy->phy)) {
+	if (new_phy) {
+		error = sas_phy_add(phy->phy);
+		if (error) {
 			sas_phy_free(phy->phy);
-			return;
+			phy->phy = NULL;
+			return error;
 		}
+	}
 
  out:
 	switch (phy->attached_dev_type) {
@@ -339,7 +343,7 @@ static void sas_set_ex_phy(struct domain_device *dev, int phy_id,
 	    SAS_ADDR(phy->attached_sas_addr) != SAS_ADDR(sas_addr))
 		/* pass */;
 	else
-		return;
+		return 0;
 
 	/* if the attached device type changed and ata_eh is active,
 	 * make sure we run revalidation when eh completes (see:
@@ -353,6 +357,8 @@ static void sas_set_ex_phy(struct domain_device *dev, int phy_id,
 		 SAS_ADDR(dev->sas_addr), phy->phy_id,
 		 sas_route_char(dev, phy), phy->linkrate,
 		 SAS_ADDR(phy->attached_sas_addr), type);
+
+	return 0;
 }
 
 /* check if we have an existing attached ata device on this expander phy */
@@ -397,8 +403,8 @@ static int sas_ex_phy_discover_helper(struct domain_device *dev, u8 *disc_req,
 		pr_notice("Found loopback topology, just ignore it!\n");
 		return 0;
 	}
-	sas_set_ex_phy(dev, single, disc_resp);
-	return 0;
+
+	return sas_set_ex_phy(dev, single, disc_resp);
 }
 
 int sas_ex_phy_discover(struct domain_device *dev, int single)
@@ -2021,7 +2027,7 @@ static int sas_rediscover_dev(struct domain_device *dev, int phy_id,
 		 * the PHY info, like negotiated linkrate.
 		 */
 		if (res == 0)
-			sas_set_ex_phy(dev, phy_id, disc_resp);
+			res = sas_set_ex_phy(dev, phy_id, disc_resp);
 		goto out_free_resp;
 	} else if (SAS_ADDR(sas_addr) == SAS_ADDR(phy->attached_sas_addr) &&
 		   dev_type_flutter(type, phy->attached_dev_type)) {
-- 
2.55.0

[PATCH v4 3/3] scsi: libsas: Handle errors in sas_ex_discover_expander()

[Eshaan Deshmukh]

The function sas_ex_discover_expander() does not account for the
potential failure of sas_port_alloc() for phy->port. It also calls
BUG_ON in case sas_port_add fails for phy->port. Add a check for
phy->port after sas_port_alloc() where if it is NULL, it cleans up the
child allocated device and returns NULL. Add another check for
sas_port_add() where if it returns an error code it frees phy->port,
sets it to NULL, cleans up the child allocated device, and returns NULL.

Signed-off-by: Eshaan Deshmukh <eshaan2031@icloud.com>
---
Changes in v4:
- Removed goto labels from v3 and moved the code back to their original
  spots

 drivers/scsi/libsas/sas_expander.c | 17 ++++++++++++-----
 1 file changed, 12 insertions(+), 5 deletions(-)

diff --git a/drivers/scsi/libsas/sas_expander.c b/drivers/scsi/libsas/sas_expander.c
index ab6afbad3..429ea2bdc 100644
--- a/drivers/scsi/libsas/sas_expander.c
+++ b/drivers/scsi/libsas/sas_expander.c
@@ -911,7 +911,6 @@ static struct domain_device *sas_ex_discover_expander(
 	struct sas_rphy *rphy;
 	struct sas_expander_device *edev;
 	struct asd_sas_port *port;
-	int res;
 
 	if (phy->routing_attr == DIRECT_ROUTING) {
 		pr_warn("ex %016llx:%02d:D <--> ex %016llx:0x%x is not allowed\n",
@@ -925,9 +924,17 @@ static struct domain_device *sas_ex_discover_expander(
 		return NULL;
 
 	phy->port = sas_port_alloc(&parent->rphy->dev, phy_id);
-	/* FIXME: better error handling */
-	BUG_ON(sas_port_add(phy->port) != 0);
+	if (!phy->port) {
+		sas_put_device(child);
+		return NULL;
+	}
 
+	if (sas_port_add(phy->port)) {
+		sas_port_free(phy->port);
+		phy->port = NULL;
+		sas_put_device(child);
+		return NULL;
+	}
 
 	switch (phy->attached_dev_type) {
 	case SAS_EDGE_EXPANDER_DEVICE:
@@ -966,8 +973,7 @@ static struct domain_device *sas_ex_discover_expander(
 	list_add_tail(&child->dev_list_node, &parent->port->dev_list);
 	spin_unlock_irq(&parent->port->dev_list_lock);
 
-	res = sas_discover_expander(child);
-	if (res) {
+	if (sas_discover_expander(child)) {
 		sas_rphy_delete(rphy);
 		spin_lock_irq(&parent->port->dev_list_lock);
 		list_del(&child->dev_list_node);
@@ -977,6 +983,7 @@ static struct domain_device *sas_ex_discover_expander(
 		phy->port = NULL;
 		return NULL;
 	}
+
 	list_add_tail(&child->siblings, &parent->ex_dev.children);
 	return child;
 }
-- 
2.55.0

Re: [PATCH v4 1/3] scsi: libsas: Handle errors in sas_ex_add_parent_port()

[sashiko-bot]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:

Pre-existing issues:
- [High] Pre-existing lack of error handling causes a kernel panic on port allocation or addition failure during edge/fanout expander discovery.
--

--- Patch [1]: [PATCH v4 1/3] scsi: libsas: Handle errors in sas_ex_add_parent_port() ---
commit bc14b1e6a1d6e30259a7082de185251e075a15fc
Author: Eshaan Deshmukh <eshaan2031@icloud.com>

    scsi: libsas: Handle errors in sas_ex_add_parent_port()

This commit changes sas_ex_add_parent_port() to properly handle failures from
sas_port_alloc() and sas_port_add() by returning error codes rather than using
BUG_ON(). It also updates sas_ex_discover_dev() to check and return these new
error codes.

> diff --git a/drivers/scsi/libsas/sas_expander.c b/drivers/scsi/libsas/sas_expander.c
> index f471ab464a78b..f1a1417b09819 100644
> --- a/drivers/scsi/libsas/sas_expander.c
> +++ b/drivers/scsi/libsas/sas_expander.c
> @@ -33,19 +33,29 @@ static void sas_port_add_ex_phy(struct sas_port *port, struct ex_phy *ex_phy)
>  	ex_phy->phy_state = PHY_DEVICE_DISCOVERED;
>  }
>  
> -static void sas_ex_add_parent_port(struct domain_device *dev, int phy_id)
> +static int sas_ex_add_parent_port(struct domain_device *dev, int phy_id)
>  {
>  	struct expander_device *ex = &dev->ex_dev;
>  	struct ex_phy *ex_phy = &ex->ex_phy[phy_id];
> +	int error;
>  
>  	if (!ex->parent_port) {
>  		ex->parent_port = sas_port_alloc(&dev->rphy->dev, phy_id);
> -		/* FIXME: error handling */
> -		BUG_ON(!ex->parent_port);
> -		BUG_ON(sas_port_add(ex->parent_port));
> +		if (!ex->parent_port)
> +			return -ENOMEM;
> +
> +		error = sas_port_add(ex->parent_port);
> +		if (error) {
> +			sas_port_free(ex->parent_port);
> +			ex->parent_port = NULL;
> +			return error;
> +		}
> +
>  		sas_port_mark_backlink(ex->parent_port);
>  	}
>  	sas_port_add_ex_phy(ex->parent_port, ex_phy);
> +
> +	return 0;
>  }

[Severity: High]
This isn't a bug introduced by this patch, but since this patch updates the
error handling for sas_port_alloc() and sas_port_add(), could the identical
pattern remaining in sas_ex_discover_expander() be addressed as well?

drivers/scsi/libsas/sas_expander.c:sas_ex_discover_expander() {
    ...
	child = sas_alloc_device();
	if (!child)
		return NULL;

	phy->port = sas_port_alloc(&parent->rphy->dev, phy_id);
	/* FIXME: better error handling */
	BUG_ON(sas_port_add(phy->port) != 0);
    ...
}

If sas_port_alloc() fails under memory pressure during edge or fanout expander
discovery, it returns a NULL pointer. This NULL pointer is directly passed to
sas_port_add(), leading to a NULL pointer dereference and a kernel panic.
Additionally, if sas_port_add() fails, the BUG_ON() triggers a kernel panic. 

Would it make sense to implement graceful error handling here as well instead
of crashing the system?

[ ... ]

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260819032321.493746-1-eshaan2031@icloud.com?part=1

Re: [PATCH v4 2/3] scsi: libsas: Handle errors in sas_set_ex_phy()

[sashiko-bot]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] Propagating errors from sas_set_ex_phy() aborts the entire expander discovery loop, leading to unintended and complete topology loss.
--

--- Patch [2]: [PATCH v4 2/3] scsi: libsas: Handle errors in sas_set_ex_phy() ---
commit 5c1f09068df832f5cb0e690bb6d4560d1c0cf52e
Author: Eshaan Deshmukh <eshaan2031@icloud.com>

scsi: libsas: Handle errors in sas_set_ex_phy()

This commit modifies sas_set_ex_phy() to return an error instead of
using BUG_ON() or returning void. It updates the callers of
sas_set_ex_phy() to propagate the newly returned error codes.

> diff --git a/drivers/scsi/libsas/sas_expander.c b/drivers/scsi/libsas/sas_expander.c
> index f1a1417b09819..ab6afbad37feb 100644
> --- a/drivers/scsi/libsas/sas_expander.c
> +++ b/drivers/scsi/libsas/sas_expander.c

[ ... ]

> @@ -220,14 +220,15 @@ static void sas_set_ex_phy(struct domain_device *dev, int phy_id,
>  	struct sas_rphy *rphy = dev->rphy;
>  	bool new_phy = !phy->phy;
>  	char *type;
> +	int error;
>  
>  	if (new_phy) {
>  		if (WARN_ON_ONCE(test_bit(SAS_HA_ATA_EH_ACTIVE, &ha->state)))
> -			return;
> +			return -EBUSY;
>  		phy->phy = sas_phy_alloc(&rphy->dev, phy_id);
>  
> -		/* FIXME: error_handling */
> -		BUG_ON(!phy->phy);
> +		if (!phy->phy)
> +			return -ENOMEM;
>  	}
>  
>  	switch (disc_resp->result) {

[ ... ]

> @@ -397,8 +403,8 @@ static int sas_ex_phy_discover_helper(struct domain_device *dev, u8 *disc_req,
>  		pr_notice("Found loopback topology, just ignore it!\n");
>  		return 0;
>  	}
> -	sas_set_ex_phy(dev, single, disc_resp);
> -	return 0;
> +
> +	return sas_set_ex_phy(dev, single, disc_resp);
>  }

[Severity: High]
Does propagating this error up abort the entire expander discovery loop?

If sas_set_ex_phy() returns -EBUSY (e.g. when SATA error recovery is active)
or -ENOMEM, sas_ex_phy_discover_helper() will pass that error back to
sas_ex_phy_discover().

sas_ex_phy_discover() iterates over all PHYs in the expander:

drivers/scsi/libsas/sas_expander.c:sas_ex_phy_discover() {
        ...
        for (i = 0; i < ex->num_phys; i++) {
                res = sas_ex_phy_discover_helper(dev, disc_req,
                                                 disc_resp, i);
                if (res)
                        goto out_err;
        }
        ...
}

Could this cause the entire expander discovery to fail and tear down the
expander if a single PHY fails to initialize, instead of just skipping the
problematic PHY as it did previously?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260819032321.493746-1-eshaan2031@icloud.com?part=2

Re: [PATCH v4 3/3] scsi: libsas: Handle errors in sas_ex_discover_expander()

[sashiko-bot]

Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:

Pre-existing issues:
- [High] Unchecked return value from `sas_expander_alloc()` causes a fatal out-of-bounds write/kernel panic when accessing `edev->level`.
- [High] Ignoring the return value of `sas_rphy_add(rphy)` leads to driver core crashes and invalid subsystem state.
--

--- Patch [3]: [PATCH v4 3/3] scsi: libsas: Handle errors in  sas_ex_discover_expander() ---
(Note: Due to system recitation restrictions, this review uses a free-form summary format instead of inline patch quoting.)

commit 44af8b2a020232c7d2be451e3b31502443d8fc4d
Author: Eshaan Deshmukh <eshaan2031@icloud.com>

scsi: libsas: Handle errors in sas_ex_discover_expander()

This commit improves error handling in sas_ex_discover_expander() by checking
the return values of sas_port_alloc() and sas_port_add(). If either function
fails, it performs proper cleanup and returns NULL.

In drivers/scsi/libsas/sas_expander.c:sas_ex_discover_expander()

[Severity: High]
This is a pre-existing issue, but does this code risk a panic under memory
pressure?

The function calls sas_expander_alloc() to allocate rphy, but does not
check if the return value is NULL. Later, it calls
rphy_to_expander_device(rphy) which uses container_of() and subtracts the
offset of rphy. If rphy is NULL, edev becomes a negative pointer. The
subsequent write to edev->level = parent_ex->level + 1 would then
unconditionally panic the kernel.

[Severity: High]
This isn't a bug introduced by this patch, but does ignoring the return
value of sas_rphy_add() lead to a crash during error recovery?

The code calls sas_rphy_add(rphy) without checking its return value. If
sas_rphy_add() fails, the internal device_add() fails, meaning the device
was never actually added to the system. 

If the subsequent call to sas_discover_expander(child) also fails, the
error handling path calls sas_rphy_delete(rphy). This attempts to call
device_del() on a device that was never successfully added, which will
dereference uninitialized fields and crash the driver core.

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260819032321.493746-1-eshaan2031@icloud.com?part=3