From nobody Thu Apr 27 16:45:16 2023 X-Original-To: bugs@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4Q6hRx0vkdz47Q09 for ; Thu, 27 Apr 2023 16:45:17 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mxrelay.nyi.freebsd.org (mxrelay.nyi.freebsd.org [IPv6:2610:1c1:1:606c::19:3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mxrelay.nyi.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Q6hRw5cQcz3jf8 for ; Thu, 27 Apr 2023 16:45:16 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1682613916; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=yf2TunVKEpz4lJS28xjTNrBWcEs/F7RujkXFktdOZMo=; b=p0gzqbRM9xA//XTW6+3jU5qVXKXiYoxusWSbPGC7E1aXYTxpnbKTBgZpw91XRY0gVLUcjH QAQ9hTdSkQi/uG5haZg8Kzj5bh+KX5jymajNrdTI0XlVdkclvfk+/DNTww5ikdMEOOqPYm cwvNvhfIr+GNlNh16XN6Bj74UJBG9RQcPlm6Q8m5USJdhuIavkT5dcV0OTk9RnqJRVj2fN sD6oUNx3tg309K2IDt0syDBCXBKnu3LSW/2KiEMq2JnJHbzsiWlPaJeNJy77uYERHFllSa Drb0GX9etZIr6lyWB0LXVvUFyc9mbtBnn+xacUbCh4090ZMke0X4CDdAufRXew== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1682613916; a=rsa-sha256; cv=none; b=NA1tmJ8l5lyAVFxqmzr3fLFAUJTA8Q8QQuD2lUOC03CbTZGYT83eJg3bzTTQQxUmdL9R1q 4f4RRvO42OnS1Seq7qfqHHEbSa+KlMNral13KCjOGAk4NuNLDs8SP9K5j0Z3/nglsnFzuH uTkqEQdEp0YTb+5zm52m+5KDflRodnVdBnY4s4T4RuKJBIkfpivt2zebL2eOiWQvYvDZPr OUfyjoUrvAeJNfIuI1IVJLEQRucx48RL/qZA8yKOfzWJzEa9+/7q9zyDAlPUwtDHGkivk/ OodVdZI3KpZmUMtiDRcPjLjD1lz8PciP8Zv7ODsqlYf4Q4c5SVutz8T78LxAdQ== Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2610:1c1:1:606c::50:1d]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mxrelay.nyi.freebsd.org (Postfix) with ESMTPS id 4Q6hRw4YjnzQ69 for ; Thu, 27 Apr 2023 16:45:16 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org ([127.0.1.5]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id 33RGjG7M090107 for ; Thu, 27 Apr 2023 16:45:16 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id 33RGjG0E090106 for bugs@FreeBSD.org; Thu, 27 Apr 2023 16:45:16 GMT (envelope-from bugzilla-noreply@freebsd.org) X-Authentication-Warning: kenobi.freebsd.org: www set sender to bugzilla-noreply@freebsd.org using -f From: bugzilla-noreply@freebsd.org To: bugs@FreeBSD.org Subject: [Bug 271101] cxgbe(4): panic due to lock recursion while creating tracing interface Date: Thu, 27 Apr 2023 16:45:16 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: CURRENT X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: melifaro@FreeBSD.org X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: bugs@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated List-Id: Bug reports List-Archive: https://lists.freebsd.org/archives/freebsd-bugs List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-bugs@freebsd.org MIME-Version: 1.0 X-ThisMailContainsUnwantedMimeParts: N https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D271101 --- Comment #1 from Alexander V. Chernikov --- Thank you for sharing the report! That was not certainly the desired outcome. The feature of Netlink in question is providing the "link" operstate per RFC 2863. Generally, Netlink is going to fetch more interface data (like min/max MTU, LRO/GSO, other capabilities etc) which may trigger either driver ioctl or e= vent some new nl_ioctl - that's something not polished yet. Speaking of this particular situation - I understand that calling driver io= ctl from within the event handler is something never done before (and there was= not a lot of users of ioctl interface within the kernel either). I see the following options as the path forward: 1) Do not ask for operstate on init. It can serve as a workaround, but may introduce silent "state miss" for other interfaces that are oper-up from the beginning. Additionally, the similar task needs to be done for the other fu= ture queries 2) Cut the event handler callchain in half (e.g. store the arrival/departure/events, reference ifp and call it from the dedicated task= q). It can do the trick, but may introduce more events reordering with other ifaddr/ifstate/route related events. The worst part (to me) is that such solution sort of says that's something wrong with the event callpoints. 3) Update the driver (either by using recursive sx or existing sx prior to calling ether_ifattach(). Personally, in my mental model ether_ifattach() call serves as the notifica= tion like "hey, this interface is ready to be used as any other interface" to the rest of the system. I actually lean to option (3) for exactly this reason. = I'm happy to change something inside the Netlink code so we don't run into issu= es with netlink<>driver interaction like this, but I'm not sure I see a good solution on Netlink part. What do you think? --=20 You are receiving this mail because: You are the assignee for the bug.=