On Sat, Jan 28, 2017 at 3:37 AM, Gleb Smirnoff <gleb...@freebsd.org> wrote: > Andrew, > > On Thu, Jan 26, 2017 at 08:24:43PM +0300, Andrew Rybchenko wrote: > A> I'd like to double-check that it is intended/known limitation on ifmedia > A> status callback to be non-sleepable. > A> The limitation is imposed by usage of the ifmedia ioctl to get status > A> from lacp/lagg code on port creation (it holds non-sleepable rm_wlock). > A> > A> Backtrace of the corresponding panic: > A> > A> Sleeping thread (tid 100578, pid 10653) owns a non-sleepable lock > A> KDB: stack backtrace of thread 100578: > A> #0 0xffffffff80ae46e2 at mi_switch+0xd2 > A> #1 0xffffffff80b31e6a at sleepq_wait+0x3a > A> #2 0xffffffff80ae34e2 at _sx_xlock_hard+0x592 > A> #3 0xffffffff8222fd7e at sfxge_media_status+0x2e > A> #4 0xffffffff80be7b90 at ifmedia_ioctl+0x170 > A> #5 0xffffffff8222c3d0 at sfxge_if_ioctl+0x1f0 > A> #6 0xffffffff82277fbe at lagg_port_ioctl+0xde > A> #7 0xffffffff82278f9b at lacp_linkstate+0x4b > A> #8 0xffffffff822794c2 at lacp_port_create+0x1e2 > A> #9 0xffffffff82276a73 at lagg_ioctl+0x1243 > A> #10 0xffffffff80bdcbec at ifioctl+0xfbc > A> #11 0xffffffff80b41ab4 at kern_ioctl+0x2d4 > A> #12 0xffffffff80b41771 at sys_ioctl+0x171 > A> #13 0xffffffff80fa16ae at amd64_syscall+0x4ce > A> #14 0xffffffff80f8442b at Xfast_syscall+0xfb > A> panic: sleeping thread > A> cpuid = 23 > > I would say that this is bug in lagg(4). We shouldn't put constraint > of non-sleepability for ioctl(2).
In additional to the ifmedia interface, the ADDMULTI/DELMULTI and setting IFF_PROMISC (through bpf, not sure about IFF_ALLMULTI) requires the driver to be non-sleepable. I currently work around this by looping sx_try_xlock(), and set a driver flag to force using DELAY instead of sleep APIs. Thanks, sephe _______________________________________________ freebsd-net@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
