The status of fegetexcept, feenableexcept, and fedisableexcept and their relationship to __BSD_VISIBLE seems to be rather variable. Some of that variability may be incorrect and other parts expected. I just note the variability itself. A quick look seemed to show:

I thought of this as an addendum to your work, and, ideally, we reviewers should have caught it in https://reviews.freebsd.org/D55938. Since you're busy tackling the arm32 and powerpc64 stuff, I'll take care of this.

I can reproduce below steps

I want to remove V_nd6_defrouter and handover selecting default router responsibility to the routing stack.
I need this patch for that.
I'd appreciate if people take look at this.

I have tested the updated if_axe driver with several devices.
In my environments, the issues with link flaps have been resolved(even added changing axe_miibus_statchg, there is "no" spurious link down message. I don't know why??) .

this look good to me

@jrm Ah, cool! Was worried I had forgotten about something. But I don't want to take credit for your work, so if you want to commit it yourself, that's probably better?

I'd be happy to review this, but I need reproduction steps.

Hi @kib,
I read your comments from kern_membarrier.c
Please can you correct me if I'm wrong "The function returns a mask of the CPUs where the given pmap is active(Here a CPU is active for a pmap if its using address space represented by that pmap). CPUs that switch context during the call might be missed, so the caller must ensure synchronization or otherwise the result could be invalid immediately after the call." I'll add this in a separate NOTE section

You're right. we set is_excluse for frag6. I thought we set it for entire netinet6.

Address @markj comments on memcpy and duplicate flags.

In D56143#1284104, @kib wrote:

Also it probably worth explaining what 'active' means.

Also it probably worth explaining what 'active' means.

The result of the call is invalid the moment the function returns. If this one-line manual page ever makes sense, it must describe how to use the result safely.

Initialize cnt

Seems ok, but I'm not sure if it's sufficient for the LLVM test case that @aokblast was looking at.

closing in favour of the other diff

not tested, but this looks reasonable, thanks!