On 4/18/2019 1:55 PM, Rafał Miłecki wrote:
On Fri, 15 Feb 2019 at 07:15, Rafał Miłecki <zajec5@xxxxxxxxx> wrote:
On Thu, 14 Feb 2019 at 23:37, Arend Van Spriel
<arend.vanspriel@xxxxxxxxxxxx> wrote:
On 2/14/2019 11:30 PM, Rafał Miłecki wrote:
I've just found a well reproducible brcmfmac crash (NULL pointer
dereference).
Steps:
1. Wait for or trigger a FullMAC firmware crash
2. Wait for some skb to get queued on a flowring
3. Call rmmod brcmfmac
Problem:
There is a NULL pointer dereference in one of the brcmf_detach() calls.
Explanation:
brcmf_detach() first frees all "ifp"s and then deletes flowrings. If any
flowring has a skb it results in calling brcmf_txfinalize() which tries
to access "ifp" (struct brcmf_if) which is a NULL.
Hi Rafał,
Thanks for diving in. That was my suspicion. Does it mean you are
working on a patch or shall I take care of it.
It would be nice to have someone more experienced with detaching &
rings look at it. Is adding a simple
if (ifp)
enough? Or should that code get redesigned? Should we e.g. reorder detach order?
Hi Arend, would you find a moment to look at that crash, please?
Hi Rafał,
Sorry for getting back on this so late. The driver tries to gracefully
teardown stuff by sending firmware commands to the device. I think that
makes no sense as that level of communication is not possible once our
driver .remove() callback is called. So I think upon calling
brcmf_detach() we should cleanup everything bottom-up. I will rework the
code and see how that goes.
Thanks,
Arend
