On Fri, May 13, 2022 at 05:53:27PM +0200, Alexandr Nedvedicky wrote: > at this point we hold a NET_LOCK(). So basically if there won't > be enough memory we might start sleeping waiting for memory > while we will be holding a NET_LOCK. > > This is something we should try to avoid, however this can be > sorted out later. At this point I just want to point out > this problem, which can be certainly solved in follow up > commit. pf(4) also has its homework to be done around > sleeping mallocs.
I think sleeping with netlock is not a problem in general. In pf(4) ioctl we sleep with netlock and pflock while doing copyin() or copyout(). This results in a lock order reversal due to a hack in uvn_io(). In my opinion we should not sleep within pf lock, so we can convert it to mutex or someting better later. In veb configuration we are holding the netlock and sleep in smr_barrier() and refcnt_finalize(). An additional sleep in malloc() is fine here. Holding the netlock and sleeping in m_get() is worse. There is no recovery after reaching the mbuf limit. Sleeping rules are inconsistent and depend on the area of the stack. Different people have multiple ideas how it should be done. bluhm
