Use trap_diag()

I did not looked at the rest of the changes for now, what I see are huge stop signs already.

In D48150#1098161, @markj wrote:

Suppose a filesystem has MNT_NOSUID set, and contains a setuid root executable. If I create a nullfs mount of that filesystem and run the executable though nullfs, should the suid bit be honoured? I would expect not, but it is. In particular, MNT_NOSUID is not copied to the upper mount, and the code which checks MNT_NOSUID does not use a VOP, it just checks vp->v_mount->mnt_flags.

In D48150#1098146, @markj wrote:

When lower fs acts according to its mount configuration, it is reported up as VOP errors.

I do not quite understand what you mean here.

I believe this is done in the wrong order. First, i386 kernel should be removed from the tree, then the userspace portion of this review can be pushed, with removal of non-sse implementation for load (and similar implementation for store should be done as well).

In D48069#1095720, @rscheff wrote:

In D48069#1095714, @kib wrote:

What do you mean by 'lock release ordering'? Can you show exact diagnostic you are trying to fix, please?

lock order reversal:
1st 0xfffffe10d700f978 IPFW static rules (IPFW static rules, rm) @ src/sys/netpfil/ipfw/ip_fw2.c:1908
2nd 0xffffffff81bbb888 rawcb (rawcb, sleep mutex) @ src/sys/netipsec/keysock.c:208
lock order IPFW static rules -> rawcb attempted at:
#0 0xffffffff80acced5 at witness_checkorder+0x1265
#1 0xffffffff809e3327 at __mtx_lock_flags+0x2d7
#2 0xffffffff80d8a66b at key_sendup_mbuf+0x21b
#3 0xffffffff80d69ccb at key_allocsa_policy_debug+0xb2b
#4 0xffffffff80d6a018 at key_allocsa_policy+0x2d8
#5 0xffffffff80d65175 at ipsec4_check_pmtu+0x535
#6 0xffffffff80d648d5 at ipsec4_process_packet+0xb5
#7 0xffffffff80d6485a at ipsec4_process_packet+0x3a
#8 0xffffffff80d65582 at ipsec4_output+0x172
#9 0xffffffff80d6546d at ipsec4_output+0x5d
#10 0xffffffff80c8d16b at ip_output+0x288b
#11 0xffffffff80da074b at ipfw_chk+0xa41b
#12 0xffffffff80d9dfd7 at ipfw_chk+0x7ca7
#13 0xffffffff80db10bf at ipfw_chg_hook+0xb8f
#14 0xffffffff80c3fc9f at pfil_run_hooks+0x16f
#15 0xffffffff80c8533d at ip_input+0xc0d

What do you mean by 'lock release ordering'? Can you show exact diagnostic you are trying to fix, please?

In D46625#1094801, @imp wrote:

In D46625#1094783, @andrew wrote:

Not currently as no kernels support it. We could add an elf note when we support LPA2 in locore.S to tell loader the kernel supports executing from a higher address.

That would be great.

amd64 cpu_set_upcall() also calls cpu_thread_clean(), basically for the fresh thread. I suspect this call was copied.

I feel that the better place for this stuff would be cpu_machdep(9) rather then comments in the header.

Let me explain my PoV.

For the udata part, I agree.

vm_map_is_system()
Remove vm_flags_t
Some updates to vm_map(9)

Of course there are more deadlocks/live locks behind this change. But we wouldn't see them until this fix is done.

Add wrapper map_is_system_map().
Convert system_map and needs_wakeup to flags.

BTW, why does SYSINIT() enforces the cast? Isn't it more correct to not cast in the macro, and allow a compiler to check that the function passed matches the type?

Add a knob to select panicing behavior.

We can add a knob to control the behavior, panic/not panic.

In D24459#1092727, @kevans wrote:

Actually, it looks like our driver callbacks typically do timeouts when they actually submit to the controller: https://cgit.freebsd.org/src/tree/sys/dev/usb/serial/uftdi.c#n1688 -- so most of these should be reasonably bounded. Perhaps still good to be defensive, since I'm not about to audit every path out of usb_serial.c

Alan' notes. Remove outdated comment. Fix kassert message.

In D24459#1092724, @kevans wrote:

In D24459#1092714, @kib wrote:

So userspace might end up waiting uninterruptibly for hw to finish something?

Yes, though we could presumably implement usb_proc_mwait_sig() for an escape hatch. It would be an improvement even before this change, because open/close will both drop the tty lock and wait potentially uninterruptibly for the hardware.

Update comment about permissions for stack gap entries.

So userspace might end up waiting uninterruptibly for hw to finish something?

Rename MAP_STACK_GROWS_DOWN to MAP_STACK_AREA

Remove MAP_ENTRY_GROWS_UP

Reword comment.
Drop _DN suffixes, a separate commit.