On 6/7/2022 3:52 PM, Danny van Heumen wrote:> Hi Franky, > > ------- Original Message -------> On Tuesday, June 7th, 2022 at 01:50, Franky Lin <franky.lin@xxxxxxxxxxxx> wrote:
>> >> >> Hi Danny, >>>> My apology. I didn’t read the thread carefully and failed to notice the rev1 to rev 2 change of the patch.
>>>>> On Jun 4, 2022, at 7:59 AM, Danny van Heumen danny@xxxxxxxxxxxxxxxxx wrote:
>>> >>> Hi Franky, >>> >>> ------- Original Message ------->>> On Saturday, June 4th, 2022 at 00:58, Franky Lin franky.lin@xxxxxxxxxxxx wrote:
>>> >>>> Hi Danny, >>>> >>>> [..] >>>> >>>> Thanks for reporting and sending out a patch to fix this. >>>>>>>> If the problem is double freeing the freezer buffer, it should be addressed from the root by setting pointer to NULL. Same thing might need to be done for sg table as well. Sorry I don’t have any sdio module to reproduce and test. Please see if the below change fixes the problem.
>>>>>> Your suggestion to set the freeze buffer address to zero was also my first proposal. I have since >>> revised, because there are a few things I considered, although I am not sure:
>>>>>> - does zero-ing the address prevent future detection of double-frees with the hardened memory
>>> allocator? (If so, I would prefer to avoid doing this.)>>> - IIUC correctly, 'sdio_set_block_size' does not do any meaningful "activation" or "allocation". >>> Therefore would not need to be undone. (repeated probes would override previous calls) >>> - Starting with the call 'sdio_enable_func', I guess/suspect more elaborate "cleanup" is necessary >>> therefore, leaving the 'goto out' from that point on. I would assume (for lack of evidence to the
>>> contrary) that the logic at 'goto out' provides proper clean-up. >> >>>> While directly return without invoking clean up process makes perfect sense for the issue described here, it doesn’t address the broader issue that sdiodev might hold on to couple stale pointers that might subsequently be used in somewhere down the path because sdiodev is not freed. Setting these pointer to NULL after freeing them could help us to catch such issue which is more catastrophic than a double-free. The perfect solution of course is to rework the code to free sdiodev whenever brcmf_sdiod_remove() is invoked but that can not be done in short-term unfortunately.
> > - True.> - If the two early returns are appropriate -- I think they are -- so we can leave those in. (Again, I'm unfamiliar with the code-base.) > - Setting the pointer to NULL at least has the benefit that behavior (even if bugged) is the same irrespective of memory allocation behavior. > - I checked your suggestion for 'sdiodev->sgtable': it is not a pointer, so setting to NULL will not help. If I read this correctly, 'sg_free_table(..)' is already resistant to multiple freeing attempts with a test of '.sgl'.
>> .. as for the control flow. Sure, rework would be nice, but -- to me at least -- it is not clear if it is really necessary. Maybe I'm mistaken, but there seem to be few entry-points to take into account. The "hardware-reset after firmware-crash"-logic was added later IIUC, so maybe it was an oversight? Regardless, I have updated the patch.
The reset-after-fw-crash was indeed added later. I am wondering is we can leave the remove-reprobe dance to the mmc core. Maybe mmc_hw_reset() could do the trick, ie. simply call mmc_hw_reset() in brcmf_sdio_bus_reset() and be done with it. Maybe opening a can of worms here, but I always felt uncertain about calling .remove and .probe callbacks directly from the driver itself as it may cause issue like this double-free, but also the bus is unaware and I don't know that is a bad thing or not.
Regards, Arend >>>> Also I forgot that our IT attached a legal footer to all emails sent to an external party. I am sorry about that to anyone reading my mail but there is nothing I can do at the moment.
>> >> Thanks, >> - Franky >> I have attached the updated patch. As mentioned before, I will be running the changes myself.
> > Regards, > Danny > > >>>> So, returning immediately with the errorcode seemed more appropriate. Regardless, I have only >>> incidental knowledge from checking the code just for this particular problem. In the end my goal >>> is to have the issues addressed so that I am not forced to reboot my system to get it back in
>>> working order. >>>>>> As for your remark about sg-table: I had not considered that, but if my notes above check out,
>>> maybe this does not need to be treated conditionally at all. >>> >>> Kind regards, >>> Danny >>>>>>> diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/bcmsdh.c b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/bcmsdh.c
>>>> index ac02244a6fdf..e9bad7197ba9 100644 >>>> --- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/bcmsdh.c >>>> +++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/bcmsdh.c>>>> @@ -802,6 +802,7 @@ static void brcmf_sdiod_freezer_detach(struct brcmf_sdio_dev *sdiodev)
>>>> if (sdiodev->freezer) {
>>>>
>>>> WARN_ON(atomic_read(&sdiodev->freezer->freezing));
>>>>
>>>> kfree(sdiodev->freezer);
>>>>
>>>> + sdiodev->freezer = NULL;
>>>>
>>>> }
>>>> }
>>>>
>>>> @@ -885,7 +886,11 @@ int brcmf_sdiod_remove(struct brcmf_sdio_dev
*sdiodev)
>>>> sdio_disable_func(sdiodev->func1);
>>>>
>>>> sdio_release_host(sdiodev->func1);
>>>>
>>>> - sg_free_table(&sdiodev->sgtable);
>>>>
>>>> + if (sdiodev->sgtable) {
>>>>
>>>> + sg_free_table(&sdiodev->sgtable);
>>>>
>>>> + sdiodev->sgtable = NULL;
>>>>
>>>> + }
>>>> +
>>>> sdiodev->sbwad = 0;
>>>>
>>>> pm_runtime_allow(sdiodev->func1->card->host->parent);
>>>>
>>>> As for submitting patch to linux-wireless, please follow the
guideline. [1]
>>>> >>>> Thanks, >>>> - Franky >>>>>>>> [1] https://www.google.com/url?q=https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches&source=gmail-imap&ust=1654959604000000&usg=AOvVaw1Q6aXVZjiKkrq9qmyYVVDa
>> >> >> >> >> >> -->> This electronic communication and the information and any files transmitted
>> with it, or attached to it, are confidential and are intended solely for>> the use of the individual or entity to whom it is addressed and may contain >> information that is confidential, legally privileged, protected by privacy
>> laws, or otherwise restricted from disclosure to anyone else. If you are >> not the intended recipient or the person responsible for delivering the >> e-mail to the intended recipient, you are hereby notified that any use,>> copying, distributing, dissemination, forwarding, printing, or copying of >> this e-mail is strictly prohibited. If you received this e-mail in error, >> please return the e-mail to the sender, delete it from your computer, and
>> destroy any printed copy of it.
Attachment:
smime.p7s
Description: S/MIME Cryptographic Signature
