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
On Tuesday, August 3, 2021 9:21:30 AM CEST Fabio Aiuto wrote:
>
> 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
Hi Fabio,
On Tue, Aug 03, 2021 at 02:23:25PM +0200, Fabio M. De Francesco wrote:
> On Tuesday, August 3, 2021 9:21:30 AM CEST Fabio Aiuto wrote:
> >
> > 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);
I think you are right :)
I didn't noticed rtw_buf_free's first argument is
a double star pointer.
>
> 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