From: Michael Straube <straube.linux@gmail.com>
To: Pavel Skripkin <paskripkin@gmail.com>, gregkh@linuxfoundation.org
Cc: Larry.Finger@lwfinger.net, phil@philpotter.co.uk,
linux-staging@lists.linux.dev, linux-kernel@vger.kernel.org
Subject: Re: [PATCH 12/12] staging: r8188eu: hal_data_sz is set but never used
Date: Sun, 5 Dec 2021 16:14:38 +0100 [thread overview]
Message-ID: <663b392b-67a0-9ce1-6f32-158a72f3262a@gmail.com> (raw)
In-Reply-To: <197e167b-2225-3593-dab3-4f1f61331de9@gmail.com>
On 12/5/21 15:42, Pavel Skripkin wrote:
> On 12/5/21 16:59, Michael Straube wrote:
>> hal_data_sz in struct adapter is set but never used. Remove it.
>>
>> Signed-off-by: Michael Straube <straube.linux@gmail.com>
>> ---
>> drivers/staging/r8188eu/hal/usb_halinit.c | 1 -
>> drivers/staging/r8188eu/include/drv_types.h | 1 -
>> 2 files changed, 2 deletions(-)
>>
>> diff --git a/drivers/staging/r8188eu/hal/usb_halinit.c
>> b/drivers/staging/r8188eu/hal/usb_halinit.c
>> index 641aaf299109..da966538596f 100644
>> --- a/drivers/staging/r8188eu/hal/usb_halinit.c
>> +++ b/drivers/staging/r8188eu/hal/usb_halinit.c
>> @@ -1969,5 +1969,4 @@ void rtl8188eu_alloc_haldata(struct adapter *adapt)
>> adapt->HalData = kzalloc(sizeof(struct hal_data_8188e),
>> GFP_KERNEL);
>> if (!adapt->HalData)
>> DBG_88E("cant not alloc memory for HAL DATA\n");
>> - adapt->hal_data_sz = sizeof(struct hal_data_8188e);
>> }
>
> Not related to your patch, but not returning an error from this function
> looks very dangerous to me.
I agree.
>
> adapt->HalData is used in GET_HAL_DATA() macro all across the driver
> code and nobody checks if it valid or not. If allocation fails here,
> than we will likely hit GPF while accessing hal_data fields.
>
> Maybe we can embed struct hal_data_8188e instead of storing a pointer to
> it?
>
>
>
We could remove rtl8188eu_alloc_haldata() completely and replace its
usage in the function rtw_usb_if1_init().
--- a/drivers/staging/r8188eu/os_dep/usb_intf.c
+++ b/drivers/staging/r8188eu/os_dep/usb_intf.c
@@ -362,7 +362,9 @@ static struct adapter *rtw_usb_if1_init(struct
dvobj_priv *dvobj,
padapter = rtw_netdev_priv(pnetdev);
/* step 2. allocate HalData */
- rtl8188eu_alloc_haldata(padapter);
+ padapter->HalData = kzalloc(sizeof(*padapter->HalData), GFP_KERNEL);
+ if (!padapter->HalData)
+ goto handle_dualmac;
This way rtw_drv_init() would return -ENODEV if the allocation fails.
What do you think?
Regards,
Michael
next prev parent reply other threads:[~2021-12-05 15:14 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-12-05 13:59 [PATCH 00/12] staging: r8188eu: misc cleanups Michael Straube
2021-12-05 13:59 ` [PATCH 01/12] staging: r8188eu: remove RF_PATH_{C,D} Michael Straube
2021-12-05 13:59 ` [PATCH 02/12] staging: r8188eu: struct odm_mac_status_info is not used Michael Straube
2021-12-05 13:59 ` [PATCH 03/12] staging: r8188eu: remove macro PHY_SetRFReg Michael Straube
2021-12-05 13:59 ` [PATCH 04/12] staging: r8188eu: remove macro PHY_QueryRFReg Michael Straube
2021-12-05 13:59 ` [PATCH 05/12] staging: r8188eu: remove macro PHY_SetBBReg Michael Straube
2021-12-05 13:59 ` [PATCH 06/12] staging: r8188eu: remove macro PHY_QueryBBReg Michael Straube
2021-12-05 13:59 ` [PATCH 07/12] staging: r8188eu: remove duplicate defines Michael Straube
2021-12-05 13:59 ` [PATCH 08/12] staging: r8188eu: bWIFI_Direct is set but never used Michael Straube
2021-12-05 13:59 ` [PATCH 09/12] staging: r8188eu: bWIFI_Display " Michael Straube
2021-12-05 13:59 ` [PATCH 10/12] staging: r8188eu: remove unused macro IS_FW_81xxC Michael Straube
2021-12-05 13:59 ` [PATCH 11/12] staging: r8188eu: remove macro GET_HAL_DATA Michael Straube
2021-12-05 13:59 ` [PATCH 12/12] staging: r8188eu: hal_data_sz is set but never used Michael Straube
2021-12-05 14:42 ` Pavel Skripkin
2021-12-05 15:14 ` Michael Straube [this message]
2021-12-05 15:22 ` Michael Straube
2021-12-05 17:23 ` Pavel Skripkin
2021-12-05 18:09 ` Michael Straube
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=663b392b-67a0-9ce1-6f32-158a72f3262a@gmail.com \
--to=straube.linux@gmail.com \
--cc=Larry.Finger@lwfinger.net \
--cc=gregkh@linuxfoundation.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-staging@lists.linux.dev \
--cc=paskripkin@gmail.com \
--cc=phil@philpotter.co.uk \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox