[3/6] brcmfmac: fix the incorrect return value in brcmf_inform_single_bss().

Commit Message

Chi-Hsien Lin Feb. 13, 2020, 8:44 a.m. UTC

From: Raveendran Somu <[e-mail]>

The function brcmf_inform_single_bss returns the value as success,
even when the length exceeds the maximum value.
The fix is to send appropriate code on this error.
This issue is observed when SVT reported random fmac crashes
when running their tests and the path was identified from the
crash logs. With this fix the random failure issue in SVT was
resolved.

Signed-off-by: Raveendran Somu <[e-mail]>
Signed-off-by: Chi-hsien Lin <[e-mail]>
---
 drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

Comments

Arend van Spriel Feb. 13, 2020, 9:30 a.m. UTC | #1

On 2/13/2020 9:44 AM, Chi-Hsien Lin wrote:
> From: Raveendran Somu <[e-mail]>
> 
> The function brcmf_inform_single_bss returns the value as success,
> even when the length exceeds the maximum value.
> The fix is to send appropriate code on this error.
> This issue is observed when SVT reported random fmac crashes
> when running their tests and the path was identified from the
> crash logs. With this fix the random failure issue in SVT was
> resolved.

Although I know what SVT is it not clear in a public commit message. 
Just refer to "Broadcom test group" or something similar. It would be 
good to have the crash log in the commit message though. I suspect it 
occurs upon next_bss_le() call, but having the crash log is better than 
having me guess. Anyway, here is my...

Reviewed-by: Arend van Spriel <[e-mail]>

Regards,
Arend

Chi-Hsien Lin Feb. 14, 2020, 2:56 p.m. UTC | #2

On 02/13/2020 5:30, Arend Van Spriel wrote:
> On 2/13/2020 9:44 AM, Chi-Hsien Lin wrote:
>> From: Raveendran Somu <[e-mail]>
>>
>> The function brcmf_inform_single_bss returns the value as success,
>> even when the length exceeds the maximum value.
>> The fix is to send appropriate code on this error.
>> This issue is observed when SVT reported random fmac crashes
>> when running their tests and the path was identified from the
>> crash logs. With this fix the random failure issue in SVT was
>> resolved.
> 
> Although I know what SVT is it not clear in a public commit message. 
> Just refer to "Broadcom test group" or something similar. It would be 
> good to have the crash log in the commit message though. I suspect it 
> occurs upon next_bss_le() call, but having the crash log is better than 
> having me guess. Anyway, here is my...
> 
> Reviewed-by: Arend van Spriel <[e-mail]>

Arend,

Thanks a lot for the feedback. I'll update the comment in V2. This is an 
issue that we solved a while back. I'll do some search and see if I can 
find the crash log.

Regards,
Chi-hsien Lin

> 
> Regards,
> Arend
> .
>

Patch

diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c
index a2328d3eee03..2ba165330038 100644
--- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c
@@ -2953,7 +2953,7 @@  static s32 brcmf_inform_single_bss(struct brcmf_cfg80211_info *cfg,
 
 	if (le32_to_cpu(bi->length) > WL_BSS_INFO_MAX) {
 		bphy_err(drvr, "Bss info is larger than buffer. Discarding\n");
-		return 0;
+		return -EINVAL;
 	}
 
 	if (!bi->ctl_ch) {