Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 10 Feb 2017 09:57:13 +0800
From:      Sepherosa Ziehau <sepherosa@gmail.com>
To:        Gleb Smirnoff <glebius@freebsd.org>,  "freebsd-net@freebsd.org" <freebsd-net@freebsd.org>
Cc:        Andrew Rybchenko <arybchik@freebsd.org>, FreeBSD developers <developers@freebsd.org>
Subject:   Re: ifmedia status callback is non-sleepable
Message-ID:  <CAMOc5cz%2Bk-R9oJSbnKMPpTjhTD99_fwTKNF_N=qUPm98bvA6Dg@mail.gmail.com>
In-Reply-To: <20170127193723.GT2611@FreeBSD.org>
References:  <790a6da4-2492-d887-8cbc-d9737d3f07d1@freebsd.org> <20170127193723.GT2611@FreeBSD.org>

next in thread | previous in thread | raw e-mail | index | archive | help
On Sat, Jan 28, 2017 at 3:37 AM, Gleb Smirnoff <glebius@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



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAMOc5cz%2Bk-R9oJSbnKMPpTjhTD99_fwTKNF_N=qUPm98bvA6Dg>