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.