Re: [PATCH v2] nfp: flower: handle acti_netdevs allocation failure

[Louis Peens]

On Fri, Mar 08, 2024 at 10:25:40PM +0800, Duoming Zhou wrote:
> [Some people who received this message don't often get email from duoming@xxxxxxxxxx. Learn why this is important at https://aka.ms/LearnAboutSenderIdentification ]
> 
> The kmalloc_array() in nfp_fl_lag_do_work() will return null, if
> the physical memory has run out. As a result, if we dereference
> the acti_netdevs, the null pointer dereference bugs will happen.
> 
> This patch adds a check to judge whether allocation failure occurs.
> If it happens, the delayed work will be rescheduled and try again.
> 
> Fixes: bb9a8d031140 ("nfp: flower: monitor and offload LAG groups")
> Signed-off-by: Duoming Zhou <duoming@xxxxxxxxxx>
> ---
> Changes in v2:
>   - Remove print warnings on allocation failures.
Thanks Duoming. Just a reminder for next time, it is recommended to add
the tree name to the patch summary ([PATCH net] or [PATCH net-next])
when submitting to netdev. Since this contains a "Fixes" tag it should
probably have been aimed at 'net'.

Reviewed-by: Louis Peens <louis.peens@xxxxxxxxxxxx>
> 
>  drivers/net/ethernet/netronome/nfp/flower/lag_conf.c | 5 +++++
>  1 file changed, 5 insertions(+)
> 
> diff --git a/drivers/net/ethernet/netronome/nfp/flower/lag_conf.c b/drivers/net/ethernet/netronome/nfp/flower/lag_conf.c
> index 361d7c495e2..2c7bd6e80d9 100644
> --- a/drivers/net/ethernet/netronome/nfp/flower/lag_conf.c
> +++ b/drivers/net/ethernet/netronome/nfp/flower/lag_conf.c
> @@ -337,6 +337,11 @@ static void nfp_fl_lag_do_work(struct work_struct *work)
> 
>                 acti_netdevs = kmalloc_array(entry->slave_cnt,
>                                              sizeof(*acti_netdevs), GFP_KERNEL);
> +               if (!acti_netdevs) {
> +                       schedule_delayed_work(&lag->work,
> +                                             NFP_FL_LAG_DELAY);
> +                       continue;
> +               }
> 
>                 /* Include sanity check in the loop. It may be that a bond has
>                  * changed between processing the last notification and the
> --
> 2.17.1
>