2017-06-13 05:54:51

by Kalle Valo

[permalink] [raw]
Subject: Re: brcmfmac: Fix kernel oops on resume when request firmware fails.

Enric Balletbo i Serra <[email protected]> wrote:

> When request firmware fails, brcmf_ops_sdio_remove is being called and
> brcmf_bus freed. In such circumstancies if you do a suspend/resume cycle
> the kernel hangs on resume due a NULL pointer dereference in resume
> function.
>
> Steps to reproduce the problem:
> - modprobe brcmfmac without the firmware
> brcmfmac mmc1:0001:1: Direct firmware load for brcm/brcmfmac4354-sdio.bin
> failed with error -2
> - do a suspend/resume cycle (echo mem > /sys/power/state)
>
> Protect against the NULL pointer derefence by checking if dev_get_drvdata
> returned a valid pointer.
>
> Signed-off-by: Enric Balletbo i Serra <[email protected]>

My understanding is that there's a new version of this patch which fixes
the issue. If not, let me know.

Patch set to Superseded.

--
https://patchwork.kernel.org/patch/9743159/

https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches


2017-06-13 10:23:38

by Enric Balletbo Serra

[permalink] [raw]
Subject: Re: brcmfmac: Fix kernel oops on resume when request firmware fails.

Hello Kalle,

2017-06-13 7:54 GMT+02:00 Kalle Valo <[email protected]>:
> Enric Balletbo i Serra <[email protected]> wrote:
>
>> When request firmware fails, brcmf_ops_sdio_remove is being called and
>> brcmf_bus freed. In such circumstancies if you do a suspend/resume cycle
>> the kernel hangs on resume due a NULL pointer dereference in resume
>> function.
>>
>> Steps to reproduce the problem:
>> - modprobe brcmfmac without the firmware
>> brcmfmac mmc1:0001:1: Direct firmware load for brcm/brcmfmac4354-sdio.bin
>> failed with error -2
>> - do a suspend/resume cycle (echo mem > /sys/power/state)
>>
>> Protect against the NULL pointer derefence by checking if dev_get_drvdata
>> returned a valid pointer.
>>
>> Signed-off-by: Enric Balletbo i Serra <[email protected]>
>
> My understanding is that there's a new version of this patch which fixes
> the issue. If not, let me know.
>
> Patch set to Superseded.
>

Yes there are these patch series [1] that fixes the issue, I guess
Arend is working on a v2 to fix a small issue we found.

[1] https://www.spinics.net/lists/linux-wireless/msg162762.html

> --
> https://patchwork.kernel.org/patch/9743159/
>
> https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
>

Regards,
Enric

2017-06-13 10:58:30

by Arend Van Spriel

[permalink] [raw]
Subject: Re: brcmfmac: Fix kernel oops on resume when request firmware fails.

On 13-06-17 12:23, Enric Balletbo Serra wrote:
> Hello Kalle,
>
> 2017-06-13 7:54 GMT+02:00 Kalle Valo <[email protected]>:
>> Enric Balletbo i Serra <[email protected]> wrote:
>>
>>> When request firmware fails, brcmf_ops_sdio_remove is being called and
>>> brcmf_bus freed. In such circumstancies if you do a suspend/resume cycle
>>> the kernel hangs on resume due a NULL pointer dereference in resume
>>> function.
>>>
>>> Steps to reproduce the problem:
>>> - modprobe brcmfmac without the firmware
>>> brcmfmac mmc1:0001:1: Direct firmware load for brcm/brcmfmac4354-sdio.bin
>>> failed with error -2
>>> - do a suspend/resume cycle (echo mem > /sys/power/state)
>>>
>>> Protect against the NULL pointer derefence by checking if dev_get_drvdata
>>> returned a valid pointer.
>>>
>>> Signed-off-by: Enric Balletbo i Serra <[email protected]>
>>
>> My understanding is that there's a new version of this patch which fixes
>> the issue. If not, let me know.
>>
>> Patch set to Superseded.
>>
>
> Yes there are these patch series [1] that fixes the issue, I guess
> Arend is working on a v2 to fix a small issue we found.
>
> [1] https://www.spinics.net/lists/linux-wireless/msg162762.html

That series was actually RFT so not a formal submit. I send out a series
yesterday, which indeed has the small issue fixed [2].

Regards,
Arend

[2] https://patchwork.kernel.org/patch/9780793/

>> --
>> https://patchwork.kernel.org/patch/9743159/
>>
>> https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
>>
>
> Regards,
> Enric
>