Generally, this is a quite unusual interface conventions. Typical unix approach is to tolerate short io and not make it error, instead having the caller to interpret and make the decision.

Rebase after some trivial bits were committed.

So yes, this is definitely the make (1) regression in HEAD. I tried tinderboxing your patch on stable/13 machine, and everything went fine. Feel free to commit with 'Approved by: kib'.

ptrdiff_t sounds arbitrary. Why did not you used e.g. ssize_t? Because it is not defined by C STD?

Yes, it seems to be a recent regression in make. Do you build on HEAD or stable?

In D31016#704447, @pho wrote:

All done. No problems seen.

20210722 19:00:47 all.sh done, elapsed 2 day(s), 04:40.10

The changes are fine.

KERNSTART
Remove second set of CR4_PGE
Update comment about KERNLOAD
Do not corrupt low memory doing AP startup if EFI boot

In D31279#704398, @markj wrote:

Ok, I see. So according to your suggestion, amd64 fuword should fall back to a lock-prefixed instruction if it detects that the operand is unaligned.

I do not think so. As far as kernel does not melt under unaligned access, it should be fine. The fact that fuword/suword are not atomic on perfectly unaligned addresses only breaks userspace that is already broken by requesting umtx op on such address.

In D31279#704379, @markj wrote:

In D31279#704348, @kib wrote:

But why is this check needed? We do not do similar checks in kern_umtx.c.

IMO MD casueword/fuword/suword interfaces must handle this case, e.g. returning EFAULT if unaligned userspace address is not acceptable (or silently do whatever is needed).

Hmm, for some reason I thought that umtx checks this. When are unaligned addresses ever acceptable? I don't see how e.g., fuword can silently handle unaligned addresses.

But why is this check needed? We do not do similar checks in kern_umtx.c.

In D31238#704101, @dchagin wrote:

UMTXQ_LOCKED_ASSERT?

Ah, ok

Style requires a blank line before multi-line comment. Also it requires a blank line after end of the block described in the comment, in this case 422/423.

I am sure that you can manage such changes without a review.

I think on ARM there exist the same problem we fixed for umtx in 30b3018d48e4441083b

I do not object against the idea of making more guts of kern_umtx.c usable for e.g. Linuxolator, but I think that polluting sys/umtx.h is not a right approach. I suggest to follow established practice, and add a new header, e.g. sys/umtxvar.h, where most of the stuff you moved could land.

Set slop to 8M for amd64, and 0 for other arches.
Add 'staging_slop' loader command to set slop to any value.

I am fine with the patch in review, but think that the actual commits should be split. In particular:

• new test
• removal of the task from UFS code
• removal of the marker

needs to be a separate commits, at least.

More grammar.

Some grammar.

Did you tried to look at the opinion of shellcheck? Often this linter catches quite amusing issues, also it often allows to simplify.

Add symbolic names for copy_staging values.
Fix pmap_page_alloc_below_4g() to use zeroed for bzero() call.
Comments fixes and style.

Fix indexes for kernel page table pages.

In D31121#702429, @dasebek_gmail.com wrote:

The kernel panic after service zfs onestart seems to be caused by this patch. I can reproduce it every time I run the command from an installation media on a KVM virtual machine.

• Without this patch, service zfs onestart succeeds.
• With this patch and copy_staging enable, the service also starts.
• With this patch, and with the default value of copy_staging, the kernel panics every time I run service zfs onestart. The error message is panic: vm_radix_insert: key 7fffffffc16 is already present.

Restore automatic state of copy_staging if kernel exec failed.

Add autodetection of the kernel type WRT copying of the staging area. Infer it from the type and size of the kernphys symbol. I am very happy with this hack because it allows us to not depend on any special notes or rather expensive and fragile mechanism. Instead, loader directly tests for the present functionality.

I do not object, but we need to coordinate due to D31180

Add __restrict to mempcpy(3) definition as well.

The added macro is affected by symbols from the user namespace. This is actually a feature for kernel compilation environment. It should be put e.g. into sys/systm.h, not into the common header that must be usable in all environments. And in sys/systm.h, it should be under #ifdef _KERNEL.

Add the 'yield if hog' patch