From: Xingui Yang yangxingui@huawei.com
[ Upstream commit 278712d20bc8ec29d1ad6ef9bdae9000ef2c220c ]
This reverts commit ab2068a6fb84751836a84c26ca72b3beb349619d.
When probing the exp-attached sata device, libsas/libata will issue a hard reset in sas_probe_sata() -> ata_sas_async_probe(), then a broadcast event will be received after the disk probe fails, and this commit causes the probe will be re-executed on the disk, and a faulty disk may get into an indefinite loop of probe.
Therefore, revert this commit, although it can fix some temporary issues with disk probe failure.
Signed-off-by: Xingui Yang yangxingui@huawei.com Reviewed-by: Jason Yan yanaijie@huawei.com Reviewed-by: John Garry john.g.garry@oracle.com Link: https://patch.msgid.link/20251202065627.140361-1-yangxingui@huawei.com Signed-off-by: Martin K. Petersen martin.petersen@oracle.com Signed-off-by: Sasha Levin sashal@kernel.org ---
LLM Generated explanations, may be completely bogus:
## Analysis Summary
### 1. Bug Description This revert fixes an **infinite probe loop** regression introduced by commit `ab2068a6fb84`. The original commit cleared the expander phy attached address when device probe failed, intending to prevent "flutter" detection. However, this creates an infinite loop:
1. Expander-attached SATA device probe fails 2. Hard reset issued in `sas_probe_sata()` → `ata_sas_async_probe()` 3. Broadcast event received after probe failure 4. Because address was cleared, device appears "new" 5. Probe re-executed → goto step 1
**Result**: Faulty disks get stuck in indefinite probe loops.
### 2. Stable Kernel Rules Assessment | Criterion | Assessment | |-----------|------------| | Fixes real bug | ✅ YES - infinite loop (severe) | | Obviously correct | ✅ YES - pure revert, restores known-working behavior | | Small and contained | ✅ YES - removes ~14 lines from one function in one file | | No new features | ✅ YES - removes code, adds nothing | | Tested | ✅ YES - Reviewed-by from Jason Yan and John Garry |
### 3. Affected Stable Trees - Original problematic commit first appeared in **v6.10-rc7** - Present in: v6.10.x, v6.11.x, v6.12.x, v6.13.x, v6.14.x, v6.15.x, v6.16.x stable trees - **NOT** in v6.1.x or v6.6.x LTS trees (they don't need this fix)
### 4. Risk Assessment **Very Low Risk**: - Pure revert restoring pre-v6.10 behavior that worked for years - No complex logic changes - simply removes the problematic code - Isolated to `sas_fail_probe()` function in `sas_internal.h` - Same author (Xingui Yang) who wrote the original is now reverting it - Multiple reviewers approved (John Garry from Oracle is a SCSI maintainer)
### 5. User Impact - **High impact** for users with SAS expanders and faulty/failing SATA drives - Enterprise storage systems commonly use SAS expanders - Infinite loops during device probe can render systems unusable - The trade-off (accepting "flutter" detection vs. infinite loops) clearly favors the revert
### 6. Dependencies None - this is a self-contained revert that requires no other commits.
## Conclusion
This is a textbook case for stable backporting: - Fixes a **severe regression** (infinite loop) - **Pure revert** with minimal risk - **Well-reviewed** by subsystem experts - Clearly affects real users with SAS/SATA storage configurations - Original author acknowledges the bug is worse than the original issue it tried to fix
The commit should be backported to all stable trees v6.10.x and newer that contain the original problematic commit.
**YES**
drivers/scsi/libsas/sas_internal.h | 14 -------------- 1 file changed, 14 deletions(-)
diff --git a/drivers/scsi/libsas/sas_internal.h b/drivers/scsi/libsas/sas_internal.h index 6706f2be8d274..da5408c701cdd 100644 --- a/drivers/scsi/libsas/sas_internal.h +++ b/drivers/scsi/libsas/sas_internal.h @@ -145,20 +145,6 @@ static inline void sas_fail_probe(struct domain_device *dev, const char *func, i func, dev->parent ? "exp-attached" : "direct-attached", SAS_ADDR(dev->sas_addr), err); - - /* - * If the device probe failed, the expander phy attached address - * needs to be reset so that the phy will not be treated as flutter - * in the next revalidation - */ - if (dev->parent && !dev_is_expander(dev->dev_type)) { - struct sas_phy *phy = dev->phy; - struct domain_device *parent = dev->parent; - struct ex_phy *ex_phy = &parent->ex_dev.ex_phy[phy->number]; - - memset(ex_phy->attached_sas_addr, 0, SAS_ADDR_SIZE); - } - sas_unregister_dev(dev->port, dev); }