I think this is probably fine - we are lying to the upper layers about having successfully written a block when in fact we're only caching it, but that shouldn't cause problems. You might consider doing this in the minidump code instead, since the coalescing will help disk dumps as well. But I don't mind having this be netdump-specific for now.

Remove unintended line break.

Try to make the wording around relocations more generic.

Address feedback.

Typo.

Address feedback.

In D20310#437745, @kib wrote:

Why do we need this page ?

So if ni_dvp == ni_vp, does the caller hold two references on vp or one? It was not clear to me from some quick reading of the code.

In D17392#417232, @andrew wrote:

I'm fine with breaking from the ABI in the kernel & modules as long as it's just for optimisation and we don't require the breakage to allow the kernel to still work after being built with, for example, gcc & linked with bfd.

I committed this in r346932.

In D20260#436664, @emaste wrote:

In D20260#436661, @kib wrote:

BTW would it be better to use the -Wl,-z,notext -Wl,-z,ifunc-noplt syntax ?

Yes, or even -Wl,-z,notext,-z,ifunc-noplt. But at least the -z and its arg should be in the same -Wl, IMO.

In D19247#413465, @kib wrote:

Don't we need to split the kernel wire/user wire limits for this to be feasible, otherwise intensive io holding pages would deny user wiring requests.

Rebase.

A different approach was taken, see D19908.

In D19908#434693, @ngie wrote:

The user space and test changes all look great. I’ll defer to someone else (like kib@) about the VM changes.
Curious: why was the quantity changed from an int to a u_long quantity? Could a comment be added to note why the change is being made, and can it optionally be committed as a separate change, if the reasoning is for modern architecture scaling?

Perhaps @andrew, @manu, @greg_unrelenting.technology or one of the other ARM folks would be willing to test?

In D20206#435984, @cem wrote:

• Add and use netdump_enabled() predicate. We rely on sx_assert neutering

during kdb/panic to obviate the lock assertion during the dump-time code, which
generally does not take locks.

Approved.

In D20218#435623, @cem wrote:

In D20218#435600, @markj wrote:

And the linker has no problem with the NULL pointer at ifunc resolution time, it's later when subsystems like DTrace want to examine kernel symbols and trip over a symbol with non-zero size and a value of 0; it's not quite right of me to say that the kernel linker doesn't "handle" this case.

Sure, I guess it's really dtrace that doesn't like zero symbols. We could monkey patch this or we could change dtrace to just ignore ifuncs that resolve to zero. I don't know if there are other consumers than dtrace that might stumble over the same obstacle, though it seems like maybe a pain point for further adoption of ifuncs.

Go back to panic().

Use a better panic message and switch to KASSERT().

In D20218#435593, @cem wrote:

Huh, I figured linker failure would prevent MOD_LOAD and thus it wouldn't matter. I had thought about providing a 3rd panic function like this but didn't know if it was required and couldn't think of a reason it might be. Guess I was mistaken :-).