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 malloc() at malloc+0x406 import_identity() at import_identity+0x30 import_identities() at import_identities+0x62 pfkeyv2_send() at pfkeyv2_send+0x1074 pfkey_output() at pfkey_output+0x87 raw_usrreq() at raw_usrreq+0x232 sosend() at sosend+0x2ec dofilewritev() at dofilewritev+0x205 sys_writev() at sys_writev+0x6d syscall() at syscall+0x27b --- syscall (number 121) --- end of kernel end trace frame: 0x1ef4e34e5300, count: 246 0x1ef227c2f3aa: End of stack trace.
