Date: Thu, 26 Jan 2017 15:54:55 -0800 From: Navdeep Parhar <nparhar@gmail.com> To: Andrew Rybchenko <arybchik@freebsd.org> Cc: "freebsd-net@freebsd.org" <net@freebsd.org> Subject: Re: ifmedia status callback is non-sleepable Message-ID: <CAPFoGT-ezj6=QLZxuAkc26BiPHm34bf_SRio_N0edPju5Yp8vg@mail.gmail.com> In-Reply-To: <5278f854-4f6f-2ff3-b6d3-f95e23b26ded@freebsd.org> References: <5278f854-4f6f-2ff3-b6d3-f95e23b26ded@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
I think it's a bad idea in general for the kernel to be holding non-sleepable locks around driver ioctls. Regards, Navdeep On Thu, Jan 26, 2017 at 9:19 AM, Andrew Rybchenko <arybchik@freebsd.org> wrote: > Hello, > > I'd like to double-check that it is intended/known limitation on ifmedia > status callback to be non-sleepable. > The limitation is imposed by usage of the ifmedia ioctl to get status from > lacp/lagg code on port creation (it holds non-sleepable rm_wlock). > > Backtrace of the corresponding panic: > > Sleeping thread (tid 100578, pid 10653) owns a non-sleepable lock > KDB: stack backtrace of thread 100578: > #0 0xffffffff80ae46e2 at mi_switch+0xd2 > #1 0xffffffff80b31e6a at sleepq_wait+0x3a > #2 0xffffffff80ae34e2 at _sx_xlock_hard+0x592 > #3 0xffffffff8222fd7e at sfxge_media_status+0x2e > #4 0xffffffff80be7b90 at ifmedia_ioctl+0x170 > #5 0xffffffff8222c3d0 at sfxge_if_ioctl+0x1f0 > #6 0xffffffff82277fbe at lagg_port_ioctl+0xde > #7 0xffffffff82278f9b at lacp_linkstate+0x4b > #8 0xffffffff822794c2 at lacp_port_create+0x1e2 > #9 0xffffffff82276a73 at lagg_ioctl+0x1243 > #10 0xffffffff80bdcbec at ifioctl+0xfbc > #11 0xffffffff80b41ab4 at kern_ioctl+0x2d4 > #12 0xffffffff80b41771 at sys_ioctl+0x171 > #13 0xffffffff80fa16ae at amd64_syscall+0x4ce > #14 0xffffffff80f8442b at Xfast_syscall+0xfb > panic: sleeping thread > cpuid = 23 > KDB: stack backtrace: > #0 0xffffffff80b24077 at kdb_backtrace+0x67 > #1 0xffffffff80ad93e2 at vpanic+0x182 > #2 0xffffffff80ad9253 at panic+0x43 > #3 0xffffffff80b39a99 at propagate_priority+0x299 > #4 0xffffffff80b3a59f at turnstile_wait+0x3ef > #5 0xffffffff80ab493d at __mtx_lock_sleep+0x13d > #6 0xffffffff80ad39f2 at _rm_wlock+0xb2 > #7 0xffffffff82275479 at lagg_port_setlladdr+0x29 > #8 0xffffffff80b363ca at taskqueue_run_locked+0x14a > #9 0xffffffff80b361bf at taskqueue_run+0xbf > #10 0xffffffff80a9340f at intr_event_execute_handlers+0x20f > #11 0xffffffff80a93676 at ithread_loop+0xc6 > #12 0xffffffff80a90055 at fork_exit+0x85 > #13 0xffffffff80f8467e at fork_trampoline+0xe > > I think vnic driver has the problem as well since it grabs sx_lock from > ifmedia status callback. > > Andrew. > _______________________________________________ > freebsd-net@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org"
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAPFoGT-ezj6=QLZxuAkc26BiPHm34bf_SRio_N0edPju5Yp8vg>