Date: Fri, 6 Sep 2024 10:15:46 -0700 From: Steve Kargl <sgk@troutmask.apl.washington.edu> To: Kristof Provost <kp@freebsd.org> Cc: freebsd-hackers@freebsd.org Subject: Re: New lock-order reversal Message-ID: <Zts4wtn7f8Twlops@troutmask.apl.washington.edu> In-Reply-To: <72AF10E0-CB5A-4CB6-A50A-30A06DB7EA03@FreeBSD.org> References: <ZtslrWXXaSL74v0A@troutmask.apl.washington.edu> <72AF10E0-CB5A-4CB6-A50A-30A06DB7EA03@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Zts4wtn7f8Twlops>