On June 13, 2022 2:33:51 PM Danny van Heumen <danny@xxxxxxxxxxxxxxxxx> wrote:
Hi Arend, Franky, ------- Original Message -------On Tuesday, June 7th, 2022 at 21:45, Danny van Heumen <danny@xxxxxxxxxxxxxxxxx> wrote:Hi Arend, ------- Original Message -------On Tuesday, June 7th, 2022 at 21:00, Arend van Spriel arend.vanspriel@xxxxxxxxxxxx wrote:[..]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 apointer, 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.I am pretty sure you found a can of worms indeed :-) So, a few things to note: - do you have a reliable way to test this behavior? - from my PoV: I have encountered various compositions of firmware and uCode for the BCM4345/9 (43456-sdio). Earlier versions may occasionally exhibit the crashing-behavior, but not reliably. - do you want to tackle this as a separate effort, given that there is already benefit in merging the earlier patch proposal? Let me try to give my impression of the code, that I get from my cursory scans through the brcmfmac code: it seems that the device as a whole (the "root") gets activated. From what I remember, there seems to be a callback that triggers subsequent initialization. So, it makes somewhat sense to me if a hardware-reset could flow (back) into the existing initialization flow.(Again, don't trust info below, as I have very limited knowledge in this domain.I'm trying to check the extent to which I can make sense of it.)What would be the next steps?
You should send a proper patch to the linux-wireless list, ie. not in an attachment but the commit message and patch diff in plain text email message. Please refer to [1] for guidelines.
I reinstated SDIO card in my test setup so I can test your patch. Regards, Arend[1] https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
Attachment:
smime.p7s
Description: S/MIME Cryptographic Signature
