On Wed, Jan 25, 2017 at 04:32:25PM +1000, Martin Pieuchot wrote: > I just enabled the NET_LOCK() again and I'm looking for test reports. > Please go build a kernel from sources or wait for the next snapshot, > run it and report back. > > If you're looking for some small coding tasks related to the NET_LOCK() > just do: > > # sysctl kern.splassert=2 > # sysctl kern.pool_debug=2 > > Then watch for the traces on your console. > > You'll see something like: > > Starting stack trace... > yield(0,1,d09dac52,f5549dbc,d94e9378) at yield+0xa4 > yield(d0bc8f40,1,f5549e18,80,14) at yield+0xa4 > pool_get(d0bc8f40,1,f5549ec8,d03ecbfb,d97815f4) at pool_get+0x1ba > m_get(1,3,f5549ec0,d03a9362,d0bc22e0) at m_get+0x30 > doaccept(d977e6c4,3,cf7ee4f8,cf7ee4ec,2000) at doaccept+0x193 > sys_accept(d977e6c4,f5549f5c,f5549f7c,0,f5549fa8) at sys_accept+0x37 > syscall() at syscall+0x250 > > This means accept(2) is doing a memory allocation that can sleep, here > with m_get(9), while holding the NET_LOCK(). Even if these should be > ok, it is easy to avoid them. In the case of doaccept() a mbuf could > be allocated beforehand or simply use the stack for that. > > Cheers, > Martin >
splassert: yield: want 0 have 1 Starting stack trace... yield() at yield+0xac pool_get() at pool_get+0x1ca m_get() at m_get+0x28 ip_ctloutput() at ip_ctloutput+0x4bf sogetopt() at sogetopt+0x7e sys_getsockopt() at sys_getsockopt+0xbf syscall() at syscall+0x27b --- syscall (number 118) --- end of kernel end trace frame: 0x3, count: 250 0x978bdd844a: End of stack trace.
