Hi David,
🤖 This review was drafted with assistance from Claude (Anthropic) and reviewed
by me before posting.
In mlx5_nl_mac_addr_sync() (drivers/common/mlx5/linux/mlx5_nl.c), `n` is
now the caller-supplied array size rather than the old fixed
MLX5_MAX_MAC_ADDRESSES (256):
struct rte_ether_addr macs[n];
This VLA scales with whatever `n` the caller passes, and by the end of
the series that can be as large as the device-reported unicast MAC
capability (up to ~4096 per the release note added later in the series)
-- roughly 25KB on the stack versus ~1.5KB before this series.
mlx5_nl_mac_addr_sync() can be reached from interrupt/alarm-thread or
hotplug contexts where stack budgets are tighter than the main lcore
stack, so this can overflow the stack. Could you switch this to a heap
allocation (or a bounded scratch buffer) now that `n` is no longer a
small compile-time constant?
--
Raslan Darawsheh
