On Mon, Jun 16, 2025 at 10:30 AM Dumitru Ceara <dce...@redhat.com> wrote:
> On 6/13/25 4:32 PM, Ales Musil wrote: > >>> I wanted to apply the series, but I discovered a serious issue during > >>> testing. There is use-after-free happening during controller exit, the > >>> engine data is freed while the pinctrl thread is still running so we > >>> need a way to ensure this won't happen. > >>> > >> Good catch! > >> > >>> We could return NULL from garp_rarp_get_data() after engine_cleanup > >>> and have extra check in pinctrl, it seems the we are only accessing > >>> the cmap in pinctrl so maybe the function can return pointer to cmap > >>> instead. > >>> > >>> I was thinking about adding atomic_bool into inc-proc-eng to indicate > >>> that the engine data are safe to access, we could use that in the > >>> garp_rarp and possibly other nodes to check if it is safe to access > >>> those data in pinctrl or not. > >>> > >>> Let me know what are your thoughts, if that sounds feasible I will > >>> post a patch then we could rebase this one on top of it. > >>> > >> What if we delay engine_cleanup() until after pinctrl_destroy()? That > >> would wait (pthread_join()) for the pinctrl thread to finish. > >> > >> Isn't that enough? > >> > >> > > Good point, that should be enough, yes. > > > > > >>> There is also missing cmap_destroy() in garp_rarp_cleanup(). > >>> > >> Yes, let's add that to v13 once we fix the race (as you point out > >> offline, it's an already existing problem that we could hit with DNS > too). > >> > > If the above is the case then the patch should be minimal and > > I could still use the amended v12 that I had prepared, let's wait > > for the use-after-free fix. we might not need v13 afterall. > > Hi Ales, > > Sounds good to me. If you plan to address that when applying the v12 > then we don't need v13. > > Regards, > Dumitru > > Thank you Felix, Martin, Dumitru and Lorenzo, I have taken care of all the problems that we have discussed and applied this to main. Regards, Ales _______________________________________________ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev
