2024-03-07 14:11:38

by Duoming Zhou

[permalink] [raw]
Subject: [PATCH] nfp: flower: handle acti_netdevs allocation failure

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 <[email protected]>
---
drivers/net/ethernet/netronome/nfp/flower/lag_conf.c | 7 +++++++
1 file changed, 7 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..07759296c71 100644
--- a/drivers/net/ethernet/netronome/nfp/flower/lag_conf.c
+++ b/drivers/net/ethernet/netronome/nfp/flower/lag_conf.c
@@ -337,6 +337,13 @@ 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) {
+ nfp_flower_cmsg_warn(priv->app,
+ "memory allocate failed\n");
+ 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



2024-03-08 08:40:39

by Yinjun Zhang

[permalink] [raw]
Subject: RE: [PATCH] nfp: flower: handle acti_netdevs allocation failure

On Thursday, March 7, 2024 9:54 PM, Duoming Zhou wrote:
<...>
>
> acti_netdevs = kmalloc_array(entry->slave_cnt,
> sizeof(*acti_netdevs), GFP_KERNEL);
> + if (!acti_netdevs) {
> + nfp_flower_cmsg_warn(priv->app,
> + "memory allocate failed\n");
> + schedule_delayed_work(&lag->work,
> + NFP_FL_LAG_DELAY);
> + continue;
> + }

It reminds me that this issue was reported and tried to fix in
https://lore.kernel.org/netdev/ZVsFBACC05VrrCfw@LouisNoVo/T/#t
However there's no followed v2 to address the review comments.
Based on that discussion, we don't need warn "allocate failed" locally.

>
> /* Include sanity check in the loop. It may be that a bond has
> * changed between processing the last notification and the
> --
> 2.17.1