On Mon, 21 Sept 2026 at 10:32, Raslan Darawsheh <[email protected]> wrote: > 🤖 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?
I don't mind switching to heap, this is control path with netlink involved in any case. -- David Marchand
