Skip to contentSkip to conversation

commit c7e88ecbe328 ("staging: r8188eu: remove rtw_buf_free() function")

DISCUSSION Fabio Aiuto 2 participants 3 messages Aug 3, 2021 Staging

lore
Share & tools
lore
#0 lore raw

Dear Greg,

I followed the discussion about the bug that was introduced by commit c7e88ecbe328. But I can't understand why this patch introduced such a bug. In the changelog of the revert patch you wrote that you forgot how pointers work (:-D), but I think I forgot either (if ever known :P).

Do you have any idea of what happened? This topic could give us all deeper understanding of kernel memory management.

Thank you in advance,

fabio

#1 lore raw
Quoted 5 lines · CEST Fabio Aiuto

Do you have any idea of what happened? This
topic could give us all deeper understanding
of kernel memory management.

Hi Fabio,

I've just briefly looked at that c7e88ecbe328. I have no time to dig it deeper but at a first look it seems that the following line is the culprit:

kfree(&pmlmepriv->assoc_req);

It should be:

kfree(pmlmepriv->assoc_req);

The second line frees the memory location whose address is saved in assoc_rec; the first line instead frees assoc_req itself.

Regards,

Fabio

#2 lore raw

Hi Fabio,

Quoted 8 lines · Fabio M. De Francesco
Quoted 5 lines · CEST Fabio Aiuto

Do you have any idea of what happened? This
topic could give us all deeper understanding
of kernel memory management.

Hi Fabio,

Quoted 8 lines

I've just briefly looked at that c7e88ecbe328. I have no time to dig it deeper but at a first look it seems that the following line is the culprit:

kfree(&pmlmepriv->assoc_req);

It should be:

kfree(pmlmepriv->assoc_req);

I think you are right :)

I didn't noticed rtw_buf_free's first argument is
a double star pointer.

Quoted 10 lines

The second line frees the memory location whose address is saved in assoc_rec; the first line instead frees assoc_req itself.

Regards,

Fabio

thank you,

fabio