ifnet: Traverse interface groups under the network epoch

[kbowling]

Summary

iflib holds IFNET_WLOCK while ether_ifattach() synchronously emits
the ifnet_attached_event.  The rtnetlink group dump calls
if_foreach_group(), which tried to acquire IFNET_RLOCK and panicked
on an exclusive-to-shared recursion.

The group lists use CK_STAILQ, and deletion already waits for
network epoch readers before freeing members.  Traverse the list in
the network epoch, as the link layer address walkers do, to avoid the
recursive lock while retaining lifetime protection.

[pouria]

I'm not sure if this is the right approach because if_detach_internal() is not the only consumer of if_delgroup. But since we're using ck_queue here, I think it should be fine.
I prefer to have other opinions on this change as well.

Thank you!

[glebius]

It is a problem of iflib. Drivers shall not use IFNET_WLOCK(). Ideally the lock should be private to net/if.c, in reality some other files in the network stack use it, but not drivers. iflib violates that, and it seems to be a pretty recent thing.

[glebius]

Mkay. We were actually already 100% correct on this lock until in 2022 in e0e12405285b6 vmaffione@ abused it for the first time. That wasn't noticed, since that was specific to netmap and due to me not keeping eye on changes close back in 2022. And very recently you pushed some LLM generated code in fe00ca2f88718 that introduced more IFNET_WLOCK() into iflib.c. Most likely you are stepping on the latter.

[kbowling]

Agreed, abandoning this approach

[glebius]

Please refactor the fe00ca2f88718 and I will see if anything can be done to e0e12405285b6. If successful with the latter, I will move the lock to if.c and that will prevent LLMs to produce this kind of problem again.

[kbowling]

@glebius I am stress testing a fix for the fail point registration, I will tag you when I post it.

[kbowling]

https://reviews.freebsd.org/D59294