On Tue, Mar 11, 2025 at 09:08:49PM +0000, Cosmin Ratiu wrote: > On Fri, 2025-03-07 at 09:03 -0800, Jakub Kicinski wrote: > > On Fri, 7 Mar 2025 09:42:49 +0200 Nikolay Aleksandrov wrote: > > > TBH, keeping buggy code with a comment doesn't sound good to me. > > > I'd rather remove this > > > support than tell people "good luck, it might crash". It's better > > > to be safe until a > > > correct design is in place which takes care of these issues. > > > > That's my feeling too, FWIW. I think we knew about this issue > > for a while now, the longer we wait the more users we may disrupt > > with the revert. > > These are preexisting races between the bond link failover and the user > removing the xfrm states. Unless the user wants to intentionally > trigger these bugs, chances are nobody has ever encountered them in the > wild in normal operation. In steady state, bond link failover works, > and adding/removing states works. It's the combination of the two > control plane events that may have a chance to double free or leak > states. > > I would not pull everything out just yet. > > Today, I managed to find a solution for these races (I think), based on > a patch series I am preparing against ipsec-next with other changes > related to real_dev. > > Hangbin, do you mind if I take over fixing the locking issue as part of > my series? I plan to send it upstream the following days. No, I don't mind. Please go ahead to fixing the locking issue. And thanks a lot for your reviewing. Regards Hangbin
