Re: [PATCH 1/3] staging: rtl8712: change the type of _r8712_init_recv_priv()

[Greg KH <gregkh@linuxfoundation.org>]

On Fri, Apr 01, 2022 at 01:06:35AM +0800, xkernel.wang@foxmail.com wrote:
> From: Xiaoke Wang <xkernel.wang@foxmail.com>
> 
> There is a memory allocation in _r8712_init_recv_priv(). Since the
> original type of this function is void, now it is changed to int to
> make the error of allocation failures propagate to its caller easily.
> 
> Signed-off-by: Xiaoke Wang <xkernel.wang@foxmail.com>
> ---
>  drivers/staging/rtl8712/recv_osdep.h   | 2 +-
>  drivers/staging/rtl8712/rtl871x_recv.c | 5 +++--
>  2 files changed, 4 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/staging/rtl8712/recv_osdep.h b/drivers/staging/rtl8712/recv_osdep.h
> index d8c1fa7..f5b97c5 100644
> --- a/drivers/staging/rtl8712/recv_osdep.h
> +++ b/drivers/staging/rtl8712/recv_osdep.h
> @@ -18,7 +18,7 @@
>  #include "drv_types.h"
>  #include <linux/skbuff.h>
>  
> -void _r8712_init_recv_priv(struct recv_priv *precvpriv,
> +int _r8712_init_recv_priv(struct recv_priv *precvpriv,
>  			   struct _adapter *padapter);
>  void _r8712_free_recv_priv(struct recv_priv *precvpriv);
>  void r8712_recv_entry(union recv_frame *precv_frame);
> diff --git a/drivers/staging/rtl8712/rtl871x_recv.c b/drivers/staging/rtl8712/rtl871x_recv.c
> index c23f6b3..dd8cb07 100644
> --- a/drivers/staging/rtl8712/rtl871x_recv.c
> +++ b/drivers/staging/rtl8712/rtl871x_recv.c
> @@ -44,7 +44,7 @@ void _r8712_init_sta_recv_priv(struct sta_recv_priv *psta_recvpriv)
>  	_init_queue(&psta_recvpriv->defrag_q);
>  }
>  
> -void _r8712_init_recv_priv(struct recv_priv *precvpriv,
> +int _r8712_init_recv_priv(struct recv_priv *precvpriv,
>  			   struct _adapter *padapter)
>  {
>  	sint i;
> @@ -60,7 +60,7 @@ void _r8712_init_recv_priv(struct recv_priv *precvpriv,
>  				sizeof(union recv_frame) + RXFRAME_ALIGN_SZ,
>  				GFP_ATOMIC);
>  	if (!precvpriv->pallocated_frame_buf)
> -		return;
> +		return -ENOMEM;
>  	kmemleak_not_leak(precvpriv->pallocated_frame_buf);

Why are you still telling kmemleak that this was not a leak if you
properly handle it?

thanks,

greg k-h