Is there a reason that these syctls would need "CTLFLAG_NEEDSGIANT", or does this patch default to that flag because it's a safe default if the contents of the sysctl are unknown? I'm aware of the previous review that added these flags, but I didn't get to look at it too closely.

Can this get regenerated? It no longer applies cleanly.

It looks like this change was part of the recently committed D22912 / rS356107

In D22870#500744, @markj wrote:

IMO it makes slightly more sense to have the check in the ixl ioctl handler: it serves as a signal to anyone extending the ioctl handler that they should be careful, and doing so maintains the invariant that internal driver functions need not check for privileges. I am not the maintainer though so I don't insist on any particular approach.

In D22523#495057, @jacob.e.keller_intel.com wrote:

Hmm. I think I understand the change.. but it seems less intuitive.
Do you have any example of how much this improves? I.e. a C program with a large enough test case to show measurable improvement?

Builds okay now.

Don't remove the extra whitespace in if.c

Update patch to make it build on HEAD

I get a build error with this revision:

Adding @jpaetzel since he seemed to be the last person making updates to oce(4); is this change ok to make there? There's no functional change.

@jacob.e.keller_intel.com, is this ready to be committed?

Update review with a first cut version of the code that checks the bus
ranges of upstream pci bridges; this doesn't incorporate suggestions
that jhb@ had made.

• Add a specific iflib flag for VLAN anti-spoof and use it

Resolve merge conflict

Here's the output I got from the first pcib above ice4/ice5 in devinfo:

I like the changes for the Intel ethernet drivers. I've always been uncomfortable with how we were required to manually iterate through the list in the driver using the LIST_FOREACH macros; like you say in your description, if the data structure changes, then it causes a lot of driver thrash.

In D21944#479344, @jhb wrote:

How did this work? Meaning how did you allocate bus numbers? Did the parent PCI-PCI bridge have enough bus numbers in range already? For this to work properly you'd need to ensure that the parent PCI-PCI bridge at the other end of the link has the requested bus numbers mapped into its range of valid bus numbers.

@krzysztof.galazka_intel.com did this get tested yet?

In D21712#474097, @gallatin wrote:

Would it make sense then to assert that the link is down?

Relevant bugzilla: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=240610

Bugzilla link: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=240610