From owner-freebsd-net@freebsd.org Fri Feb 10 01:57:15 2017 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id C6A9CCD864D for ; Fri, 10 Feb 2017 01:57:15 +0000 (UTC) (envelope-from sepherosa@gmail.com) Received: from mail-vk0-x231.google.com (mail-vk0-x231.google.com [IPv6:2607:f8b0:400c:c05::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 82041883; Fri, 10 Feb 2017 01:57:15 +0000 (UTC) (envelope-from sepherosa@gmail.com) Received: by mail-vk0-x231.google.com with SMTP id r136so16280564vke.1; Thu, 09 Feb 2017 17:57:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=fvmnhkDUAN/tQKubU0g1rf8peqkKBdVJnI+UL8mL3D8=; b=lFnm1btNzEG5jfnX18dk14KHtCmS4PGjr+i9k1l3EUwQb6INT2OTPNYtNfjCQkRjVY mBDticXWOJTjAwb1DLQWAWXhNX5jDUn6mutkqT8gVGEcRQvoK+NdD1PsRRovwT3At4s9 wwpuAwrWCJ51ZX4OO3TyweAsD2kodzyE5G/j+vKA9gHRfmSAt+BvTUUx7V9UVL+0pRhp FjOtWU8oW3pXJDtl9Cwr/0ffsRD0cx8PoIFTfu1gvQr3DfwIMRqHABrmolj7mCeKSgk0 C1otdw8ZSH+/f7wVHkGuVHQZmffFS/dBd7jbKXRkS4RSTqiJRI/nMUWAwnycXAdC5I5L AsPQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=fvmnhkDUAN/tQKubU0g1rf8peqkKBdVJnI+UL8mL3D8=; b=RA9IRJcJcZXAO9xVvqhxDy4XNP/byUs4OMdMxngYR02IY+gUuvg2ZVaeQd14upv7FJ XXmhrO3azhaNjIFE2BS011p7avC+jHEUm174PBGlikT34gs3QRV61oRQwM3ZdG6+Fa5m xWmqIO0R17er3RlOoSdFBgh5J81lFd0HoR7ZL+unQGPbSauLpXKQr/SmWlp7tI17TIv5 xeYyUC1AjLxqsaI306gwrvIjIIooXkBknf4yLdQGGsTWjr8vPyHcnt8dodXpJOqNx0K+ DOcKLkEaLkga1l0qbzfK4jOL2CeXa5tzhm2SNIhIR/GE7vneojrf9g3AP8D7YMg6BkP0 VJ9Q== X-Gm-Message-State: AMke39n15PW6+BdrQyLKAyStGRYqYY54N/kDj6bj0Y9YUwGox/nsRC76oRb6jEd7qyLtfzZQevIv7tQ3Rb4new== X-Received: by 10.31.155.75 with SMTP id d72mr2968724vke.55.1486691834325; Thu, 09 Feb 2017 17:57:14 -0800 (PST) MIME-Version: 1.0 Received: by 10.176.2.10 with HTTP; Thu, 9 Feb 2017 17:57:13 -0800 (PST) In-Reply-To: <20170127193723.GT2611@FreeBSD.org> References: <790a6da4-2492-d887-8cbc-d9737d3f07d1@freebsd.org> <20170127193723.GT2611@FreeBSD.org> From: Sepherosa Ziehau Date: Fri, 10 Feb 2017 09:57:13 +0800 Message-ID: Subject: Re: ifmedia status callback is non-sleepable To: Gleb Smirnoff , "freebsd-net@freebsd.org" Cc: Andrew Rybchenko , FreeBSD developers Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Feb 2017 01:57:15 -0000 On Sat, Jan 28, 2017 at 3:37 AM, Gleb Smirnoff 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