<div dir="auto">On Wed, Mar 6, 2024 at 10:51 PM Jonas Gorski <<a href="mailto:jonas.gorski@gmail.com" target="_blank" rel="noreferrer">jonas.gorski@gmail.com</a>> wrote:<br>
><br>
> Hi<br>
><br>
> The NULL check is what needs to be fixed/removed, not the code<br>
> surrounding it. This function will be called from dev_uevent() [1]<br>
> where dev cannot be NULL. So a NULL dereference cannot happen.<br>
><br>
> Most other implementors of bus_type::uevent have no NULL check. To be<br>
> precise, there is only one other implementor with a NULL check,<br>
> rio_uevent(), and none of the other ones have one. See e.g.<br>
> bcma_device_uevent(), memstick_uevent(), mips_cdmm_uevent(), or<br>
> fsl_mc_bus_uevent().<br>
><br>
> [1] <a href="https://elixir.bootlin.com/linux/v6.7.8/source/drivers/base/core.c#L2590" rel="noreferrer noreferrer" target="_blank">https://elixir.bootlin.com/linux/v6.7.8/source/drivers/base/core.c#L2590</a><br>
<br>
Hi Jonas,<div dir="auto"><br><div dir="auto">Thank you for the feedback. To be precise there are actually 8 other <br>implementors (and potentially more) with a NULL check not just one <br>(parisc_uevent, serio_uevent, ipack_uevent, pci_uevent, pcmcia_bus_uevent, <br>rio_uevent, zorro_uevent, and soundbus_ueven).<br>After a second review, I totally concur with your observations. I quickly <br>judged, I believed there might be an alternative way to call the function <br>because it's not the only one with a null check, and actually the patch <br>version 1 got accknowleded, that's why i'm confused. <br>Given that null is improbable in this context due to the calls being made <br>through uevent, we should eliminate the redundant condition. In light of <br>this, would you recommend sending a new version (v4) of the patch with the <br>correct title and info, or do you think it would be more appropriate to <br>submit an entirely fresh patch? i'll also send patches to all of the <br>implementors.<br></div></div></div>