summaryrefslogtreecommitdiff
path: root/tools/perf/scripts/python/stackcollapse.py
diff options
context:
space:
mode:
authorNilesh Javali <njavali@marvell.com>2026-07-30 21:28:24 +0530
committerMartin K. Petersen (Oracle) <mkp@kernel.org>2026-08-06 16:41:10 -0400
commit2ac6a829843cf3df522d19e091276109b94c4c7a (patch)
tree1bef7a2f697c2cc33633ced37b89d1eafee16075 /tools/perf/scripts/python/stackcollapse.py
parent0f41d07d72f2245208c45374ca8d0a1846cad667 (diff)
scsi: qla2xxx: Clamp max_npiv_vports to VP_CTRL bitmap capacity
ha->max_npiv_vports is taken from firmware (mcp->mb[11]) and only constrained so that (max_npiv_vports + 1) is a multiple of MIN_MULTI_ID_FABRIC, which permits values of 63, 127, 191 and 255. NPIV vports are then allocated up to that count. VP enable uses the VP_CONFIG IOCB, which addresses a vport through a plain vp_index byte, so a vp_index beyond 128 is enabled without issue. VP disable, however, uses the VP_CTRL IOCB, which selects target vports through the fixed 128-bit vp_idx_map bitmap. qla24xx_control_vp() rejects a vp_index past that bitmap and the IOCB builder cannot set a bit beyond 127, yet qla24xx_vport_delete() frees the local state regardless. A vport with vp_index > 128 can therefore be created and enabled but never disabled, leaving it permanently active in firmware: a resource leak. Cap ha->max_npiv_vports at init to the vp_idx_map capacity so such vports are never created. This collapses 191/255 to 127 (still modulo-valid) and leaves the real-world 63/127 cases unaffected. Fixes: 4d0ea24769c8 ("[SCSI] qla2xxx: Retrieve max-NPIV support capabilities from FW.") Cc: stable@vger.kernel.org Reported-by: Sashiko <sashiko-dev@google.com> Signed-off-by: Nilesh Javali <njavali@marvell.com> Link: https://patch.msgid.link/20260730155838.2119230-20-njavali@marvell.com Signed-off-by: Martin K. Petersen (Oracle) <mkp@kernel.org>
Diffstat (limited to 'tools/perf/scripts/python/stackcollapse.py')
0 files changed, 0 insertions, 0 deletions