From: Bharat Bhushan bbhushan2@marvell.com
[ Upstream commit 2157e50f65d2030f07ea27ef7ac4cfba772e98ac ]
Adds timeout to exit from possible infinite loop, which polls on CPT instruction(load_fvc) completion.
Signed-off-by: Srujana Challa schalla@marvell.com Signed-off-by: Bharat Bhushan bbhushan2@marvell.com Signed-off-by: Herbert Xu herbert@gondor.apana.org.au Signed-off-by: Sasha Levin sashal@kernel.org ---
LLM Generated explanations, may be completely bogus:
Let me look at the exact code changes from the diff provided:
**YES**
This commit should be backported to stable kernel trees for the following reasons:
## Bug Fix Analysis
1. **Critical Bug Fixed**: The commit fixes a **potential infinite loop** in the `otx2_cpt_discover_eng_capabilities()` function. The original code had: ```c while (lfs->ops->cpt_get_compcode(result) == OTX2_CPT_COMPLETION_CODE_INIT) cpu_relax(); ``` This loop could spin forever if the hardware fails to respond or gets stuck.
2. **Real-World Impact**: An infinite loop in kernel space is a severe issue that can: - Cause system hangs/freezes - Make the CPU core unresponsive - Prevent proper driver initialization - Lead to denial of service conditions
3. **Simple and Contained Fix**: The patch adds: - A timeout counter (10000 iterations with 1μs delay = 10ms timeout) - Proper error handling with `-ENODEV` return - Clear warning message to help diagnose hardware issues - Proper cleanup path (`error_no_response` label)
4. **Minimal Risk**: The changes are: - Limited to a single function - Only add timeout logic without changing the core functionality - Include proper error handling and resource cleanup - Don't introduce new features or architectural changes
5. **Hardware Interaction Context**: This function polls hardware for completion of a CPT (cryptographic processor) instruction. Hardware polling without timeouts is a classic source of kernel hangs, especially when: - Hardware malfunctions - Firmware issues occur - Power management transitions happen - PCIe communication errors occur
6. **Stable Tree Criteria Met**: - ✓ Fixes a real bug (infinite loop) - ✓ Small change (~20 lines) - ✓ No new features added - ✓ Low regression risk - ✓ Fixes a potential system stability issue
The timeout value of 10ms (10000 × 1μs) is reasonable for hardware polling operations, providing sufficient time for normal operations while preventing indefinite hangs in error conditions.
.../crypto/marvell/octeontx2/otx2_cptpf_ucode.c | 16 ++++++++++++++-- 1 file changed, 14 insertions(+), 2 deletions(-)
diff --git a/drivers/crypto/marvell/octeontx2/otx2_cptpf_ucode.c b/drivers/crypto/marvell/octeontx2/otx2_cptpf_ucode.c index 78367849c3d5..9095dea2748d 100644 --- a/drivers/crypto/marvell/octeontx2/otx2_cptpf_ucode.c +++ b/drivers/crypto/marvell/octeontx2/otx2_cptpf_ucode.c @@ -1494,6 +1494,7 @@ int otx2_cpt_discover_eng_capabilities(struct otx2_cptpf_dev *cptpf) dma_addr_t rptr_baddr; struct pci_dev *pdev; u32 len, compl_rlen; + int timeout = 10000; int ret, etype; void *rptr;
@@ -1554,16 +1555,27 @@ int otx2_cpt_discover_eng_capabilities(struct otx2_cptpf_dev *cptpf) etype); otx2_cpt_fill_inst(&inst, &iq_cmd, rptr_baddr); lfs->ops->send_cmd(&inst, 1, &cptpf->lfs.lf[0]); + timeout = 10000;
while (lfs->ops->cpt_get_compcode(result) == - OTX2_CPT_COMPLETION_CODE_INIT) + OTX2_CPT_COMPLETION_CODE_INIT) { cpu_relax(); + udelay(1); + timeout--; + if (!timeout) { + ret = -ENODEV; + cptpf->is_eng_caps_discovered = false; + dev_warn(&pdev->dev, "Timeout on CPT load_fvc completion poll\n"); + goto error_no_response; + } + }
cptpf->eng_caps[etype].u = be64_to_cpup(rptr); } - dma_unmap_single(&pdev->dev, rptr_baddr, len, DMA_BIDIRECTIONAL); cptpf->is_eng_caps_discovered = true;
+error_no_response: + dma_unmap_single(&pdev->dev, rptr_baddr, len, DMA_BIDIRECTIONAL); free_result: kfree(result); lf_cleanup: