I know the initial emails were eaten by phabricator. I am still hoping someone would tell me why this is a really bad idea... or not. @karels @gnn ?

Given the discussions in D18968 I think you'd be safe as I'd assume we don't otherwise have TCP_REASS_LOGGING in 11, do we?
I guess rrs may or may not give you a more technical feedback.

Ok, your prepared change looks good from a merge-to-stable11 perspective.

Can we also get rid of the special case pfil_ipfw with this (before/after this change)?
Also, while I like it can we break out certain changes which do not have to be part of the initial framework change, e.g., the Mellanox driver change seems to be self-contained (as others possibly are). Helps to review and understand individual parts.

Looks good.

I am accepting it as it seems all correct. Given you said you want an EN for this as well, you might consider to split it up into two parts so that only the real functional fix would later be part of the EN.

You may want to consider forwarding this to re@ after commit and suggest once merged to stable/12 there should be a EN about this; probably together with markj's D18906.

Most of the "cosmetic" changes can be ignored if you want. The only real one is the one I marked with XXX; if the current code is correct I think it would deserve a comment on why that is. I couldn't figure it out quickly.

(a) there's one or two lines of whitespace changes in there; can we get them sorted separately?
(b) how much of this has become "reverting" changes and how much is actual change now? I wonder if, for the sake of clarity and history as well as for easier review, could be split into two parts? Is that feasible?

Hit enter too early; you might want to be slightly more verbose in the commit message as to why this change is done.

Not sure where the documentation will go but netstat -s -p ip6 says "fragments" not "packets" so this change sees correct.

Ok looks like bwi doesn't need.

I like this version better than the one before. Thanks! For as much as I can say it looks OK. I haven't tested it.

Depending on the outcome here, it look like bwi will need similar treatment?

Can you please fold some of the problem description of "why?" this change is needed in the proposed commit message; having some more information available when scrolling through source code management system logs is extremely helpful.

Ok, let's try this..

Sorry, a tiny tinsy bit more.

Also please re-gen src.conf(5)

I suggest a grep -ir timed over the src tree (ignore the .svn directory) is a good way of seeing or finding more.

I think you are still not removing /etc/rc.d/timed using ObsoleteFiles and also libexec/rc/rc.d/timed (I assume is where it's coming from given the Makefile change) is still in SVN.

I volunteered to look at this to get the transport unblocked. Can do tomorrow together in case I'd have a question.

Check libexec/rc/rc.d/Makefile:.if ${MK_TIMED} != "no"
Check tools/build/mk/OptionalObsoleteFiles.inc:.if ${MK_TIMED} == no
rm tools/build/options/WITHOUT_TIMED (and re-gen src.conf)

In D18420#392922, @ae wrote:

I think such method can be useful. Do you plan to merge it?

Sorry but my understanding is that this could possibly free the softc even before lagg_clone_destroy() has finished, couldn't it?

@imp could you please comment on your architectural views (or wish-list) while there is still time? Otherwise I might have to sort it out after the facts; I am expecting to be at a point when I need to make a driver talk to some SDIO in about a week and that means I'll work on any middle-glue-code I'll see fit.

I'll trust you to get the assertion right; sounds good to me.

In D12467#277167, @imp wrote:

Sorry, getting IPv4 fragments into my head is absolutely not a good idea.

Sorry; getting IPv4 fragments into my head is not a good idea.

Can you please site the Apple CVE and possibly the original writeup instead of a (random) reddit thing?

To me this change seems wrong. The only caller for this function is exactly for the situation when the link-local address is missing.
If we are in the progress of "configuring" the interface and someone is already de-configuring it to me that sounds like a concurrency problem elsewhere.
This entire function seems to be based on the idea that there's a lock held around it and it's the only actor (which might very well still be coming from &Giant days of FreeBSD 4).

See PR 230857 for details.

So is it the last 5 commits on your github branch or is there anything in there from before that? Having this broken up in logical junks for review will make it a lot easier.

In D17512#379535, @arichardson wrote:

Ideally we could place the padding outside of the section instead of inside and then just use <=. However, the linker can place any orphan section inbetween so there might be some relocations...
Since that is not possible this solution looks fine to me.

In D17512#378547, @jhb wrote:

The magic value seems kind of odd. Note that it is a valid KVA on i386 now that i386 was 4:4 (and even before then it was possible to move the top of UVA down to give more KVA, e.g. some folks ran 2:2 on i386 instead of 3:1). Do you have more details on the relocation check? Is it using < instead of <= or some such?

Ok, I've tested this (well the shorter constants version mostly) with my two test modules (no longer panics, size of 1 symbol works), which a linker script which had a wrong padding, and with the matching modules. I am aware that 3rd party modules will be unhappy but after spending days and weeks to get to this, no better solution could be found. Does anyone want to review this quickly so it can go into HEAD and go to 12, to prevent panics there?

Update the constants to sizeof linker-script-LONG (32bit) to have a smaller
possibility of accidentally matching.

Go with Alex's suggestion of fixed padding at the end as linkers are not
working reliable enough to simply extend an already existing section (see PR 232291).
This simplfis the linker script logic and adds some extra checkes to link_elf.c
for just i386.

Neither this nor the kernel version (though that one just less likely) is not deadlock safe. It can still happen.

What's the reason we can't just use the IFNET_WLOCK() and be good with it and not rewriting the entire code but going back to what it was?
The original version if_grow() could not fail, ifindex_alloc() had at best one retry, ... I am still not getting why this wasn't good enough?

Anyone? I'd love to get this in ...

In D17598#376045, @hselasky wrote:

@bz: Try modifying the script to create 65536 /dev/tun devices.

Silly question; can you explain that test case? How do 255 multicast addresses assigned to 255 interfaces make you run out of ifindex space?

For as much as my brain still functions this seems ok

It would greatly help if the proposed commit message would also cite the RFC sections not just the RFCs; ideally actually comments in the code would do that as well at the right place so that future reference lookups will be easier.

Scrolling through it looks OK with cross-checking to the RFCs.
Mostly commenting on the fact that we should get this in before BETA as it does change the kernel KPI.
Hope someone will do the full technical review (want to add lstewart as well?)