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 wrote: > > Hi Franky, > > ------- Original Message ------- > On Saturday, June 4th, 2022 at 00:58, Franky Lin 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. 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 > > 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.