Re: New lock-order reversal
- Reply: Kristof Provost : "Re: New lock-order reversal"
- In reply to: Kristof Provost : "Re: New lock-order reversal"
- Go to: [ bottom of page ] [ top of archives ] [ this month ]
Date: Fri, 06 Sep 2024 17:15:46 UTC
On Fri, Sep 06, 2024 at 06:49:48PM +0200, Kristof Provost wrote: > Hi Steve, > > On 6 Sep 2024, at 17:54, Steve Kargl wrote: > > FYI (and return hackers to a non-language) > > > > Update my old system to circa Aug 10, 2024 top-of-tree > > and rebuilts all installed ports. I'm now see a new > > lock-order reversal while using openvpn. > > (trace elided) > I don’t think that’s new. It’s an order issue between if_ovpn establishing > the UDP tunnel callback (which requires the UDP lock) and the normal traffic > flow, where the UDP lock is taken, the tunnel function is called and that > then takes the if_ovpn lock. Yeah, I should have looked at bugzilla. There is a report of the LoR. > I’ve had another look at this, and while I can probably avoid this for > setting the tunnel function (basically by assuming setting it never fails or > is already done, which is currently the case), I’m not happy with the only > solution I see on the removal side (i.e. “don’t, just trust that the socket > will be closed soon”). Thanks for the patch. I'll add to my kernel when I rebuild it. Unfortuantely, I have way too little understanding about locking within the kernel to be of much help. -- steve