summaryrefslogtreecommitdiff
path: root/include
diff options
context:
space:
mode:
authorErni Sri Satya Vennela <ernis@linux.microsoft.com>2026-04-30 01:36:21 -0700
committerJakub Kicinski <kuba@kernel.org>2026-05-04 19:13:36 -0700
commitf7622e58e8022190774cbbb7724d16f286aeb215 (patch)
tree857f0a9a0d722a129f7a3df7e3d6d8bce8699d72 /include
parent93ca1575dd1f43e24ad85663305e13114f9acdf1 (diff)
net: mana: hardening: Reject zero max_num_queues from GDMA_QUERY_MAX_RESOURCES
In a CVM environment, hardware responses cannot be trusted. The GDMA_QUERY_MAX_RESOURCES command returns resource limits used to determine the maximum number of queues. In mana_gd_query_max_resources(), gc->max_num_queues is initialized from num_online_cpus() and successively clamped by the hardware-reported max_eq, max_cq, max_sq, max_rq, and num_msix_usable values. If any of these hardware values is zero, gc->max_num_queues becomes zero and the function returns success. This leads to a confusing failure later when alloc_etherdev_mq() is called with zero queues, returning NULL and producing a misleading -ENOMEM error. Add an explicit zero check for gc->max_num_queues after all clamping steps and return -ENOSPC for a clear early failure, consistent with the existing gc->num_msix_usable <= 1 guard. Signed-off-by: Erni Sri Satya Vennela <ernis@linux.microsoft.com> Reviewed-by: Shradha Gupta <shradhagupta@linux.microsoft.com> Link: https://patch.msgid.link/20260430083627.1873757-1-ernis@linux.microsoft.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Diffstat (limited to 'include')
0 files changed, 0 insertions, 0 deletions