[Bug 271101] cxgbe(4): panic due to lock recursion while creating tracing interface

From: <bugzilla-noreply_at_freebsd.org>
Date: Thu, 27 Apr 2023 16:45:16 UTC
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=271101

--- Comment #1 from Alexander V. Chernikov <melifaro@FreeBSD.org> ---
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 event
some new nl_ioctl - that's something not polished yet.

Speaking of this particular situation - I understand that calling driver ioctl
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 future
queries

2) Cut the event handler callchain in half (e.g. store the
arrival/departure/events, reference ifp and call it from the dedicated taskq).
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 notification
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 issues
with netlink<>driver interaction like this, but I'm not sure I see a good
solution on Netlink part.

What do you think?

-- 
You are receiving this mail because:
You are the assignee for the bug.