Re: [PATCH net v2] ethtool: Embed FEC hist ranges as buffer in struct

[Vadim Fedorenko <vadim.fedorenko@linux.dev>]

On 23/07/2026 05:13, Eric Joyner wrote:
> When a driver's .get_fec_stats() handler is called and the driver
> supports FEC histogram stats, the driver supplies the histogram bin
> ranges via a pointer.  This pointer is assigned while under the netdev
> ops lock in fec_prepare_data(), but the actual data is only read after
> the lock is released; so this allows the driver to change the ranges
> (e.g. from another .get_fec_stats() call) while the current call chain
> is reading them in fec_fill_reply().
> 
> Fix this by adding an ethtool core-owned buffer, ranges_buf, to struct
> ethtool_fec_hist. Drivers whose ranges are built dynamically (currently
> just mlx5) fill ranges_buf and then point the existing ranges pointer at
> it, giving ethtool a consistent copy that stays valid after the netdev
> ops lock is dropped and later in fec_fill_reply(). Drivers whose ranges
> are compile-time constants (bnxt, netdevsim) are unaffected by the
> potential race and keep setting the existing ranges pointer to their
> constant array, without making copies.
> 
> Fixes: cc2f08129925 ("ethtool: add FEC bins histogram report")
> Assisted-by: Claude:claude-sonnet-5
> Signed-off-by: Eric Joyner <eric.joyner@amd.com>
> ---
> v2: Take Vadim Fedorenko's suggestion
> (https://lore.kernel.org/netdev/f136bfb9-1756-4668-acc3-68962cdc6069@linux.dev/)
> and keep the ranges pointer for drivers that use constant ranges arrays;
> only use the new memory for dynamically constructed ranges.
> This makes this patch mostly an mlx5 change.

LGTM, but we definitely need a stamp from mlx folks.

Reviewed-by: Vadim Fedorenko <vadim.fedorenko@linux.dev>