On Mon, Apr 25, 2022 at 05:49:49PM +0300, Vitaliy Makkoveev wrote: > I guess, this race exposes that the IPL_SOFTNET level is not enough for > `ipsec_flows_mtx' mutex(9). This mutex(9) protects multiple objects, so > could get similar panic on other places. I propose to increase the > `ipsec_flows_mtx' mutex(9) priority level to IPL_MPFLOOR.
This code is never called from interrupt. I doubt that it can cause this crash. The problem with IPL above mpfloor is that an interrupt can grab kernel lock. If ipsec_flows_mtx is called anywhere without and anywere else with kenrel lock, we have a lock ordering problem. This can cause a hang or witness panic. Your fix is correct, but I think it is not related to the problem. OK bluhm@ > Index: sys/netinet/ip_ipsp.c > =================================================================== > RCS file: /cvs/src/sys/netinet/ip_ipsp.c,v > retrieving revision 1.269 > diff -u -p -r1.269 ip_ipsp.c > --- sys/netinet/ip_ipsp.c 10 Mar 2022 15:21:08 -0000 1.269 > +++ sys/netinet/ip_ipsp.c 25 Apr 2022 14:29:42 -0000 > @@ -91,7 +91,7 @@ void tdb_hashstats(void); > * F ipsec_flows_mtx > */ > > -struct mutex ipsec_flows_mtx = MUTEX_INITIALIZER(IPL_SOFTNET); > +struct mutex ipsec_flows_mtx = MUTEX_INITIALIZER(IPL_MPFLOOR); > > int tdb_rehash(void); > void tdb_timeout(void *);
