I think this change is fine as is.

If doing such reorg, it might make sense to de-commission syscall_thread_enter/exit, renaming underscored functions back to syscall_thread_.... Then you would fetch SY_THR_STATIC once and cache it in local var.

enter is needed for syscalls from _loadable_ modules, not unloadable.

Provide extensive comment about get_parent_vp(), which in essence overviews the whole patch with its ERELOOKUP mechanism.

Last batch of fixes.
Passed full stress2 run.

refcount_release_if_last sounds almost like refcount_release, and I suspect that refcount_release() might be enough. As I understand, the problem is that pmap_remove_pages() has to operate on current pmap, which causes all that troubles. What if we just use refcount_release() and keep p_vmspace with refcount zero until pmap_remove_pages() finish ?

I am not sure about this approach. Note that vref()/usecount reference does not prevent the vnode reclaim. So for instance force umount results in vgone() which does inactivation and reclaim regardless of the active state (or rather does inactivation if the vnode is active). In this case, it seems to not fix the issue.

All pseudo fs do not do anything with from/source.
For real filesystems, resolving source is actually useful for users, I believe, but it would be a user-visible change. In fact, I sometimes want the behavior that your patch introduces.

In D26908#600942, @alc wrote:

After mulling this over for the past day or so, I'd like to propose the following alternative description:

"This option creates a memory region that grows downward on demand and an adjoining guard that both reserves address space for the memory region to grow into and limits the memory region's growth. Together, the memory region and the guard occupy len bytes of the address space. The guard starts at the returned address, and the memory region ends at the returned address plus len bytes. Upon access to the guard, the memory region automatically grows in size, and the guard shrinks by an equal amount. Essentially, the boundary between the guard and the memory region moves downward so that the access falls within the enlarged memory region. However, the guard will never shrink to less than the number of pages specified by the sysctl security.bsd.stack_guard_page, thereby ensuring that a gap for detecting stack overflow always exists between the downward growing memory region and the closest memory region beneath it."

Rebase.
Fix build for !DIAGNOSTICS.
Latest batch of the fixes for bugs reported by Peter.

vmspace != vm_map, and vm_map lock is only supposed to protect vm_map.

What about compat32 ?

Instead of trying to outguess all syscalls, might be add a TDP flag to indicate that AUDIT on exit does not need to be done. Then, in the special-case syscalls like *execve() and perhaps all users of kern_posix_exit(), call AUDIT_SYSCALL_EXIT() manually when you know the correct errno.

Reword text to distinguish between guard as is, and minimal guard size.

As far as this pass tinderbox ...

In D26887#600298, @br wrote:

In D26887#599735, @andrew wrote:

Would it make sense to move these to subr_bus_dma.c in the non-IOMMU case?

I'm not sure. I guess we can't customize per-arch implementation of these functions in non-IOMMU case

Ed' changes.

Handle Ed' notes.
Use .Dv for sysctl mib name.
Bump date.

Add parenthesis.

I will handle the patch.

Merging i386/npx.c and amd64/fpu.c is a lot of work for many reasons, I evaluated that several years ago. For now keeping them separate is better IMO.

No, this should be in SATA driver.

Document softdep_pre*().

Newer snap.

I am curious. There is no arch restriction on the value of MSI base address ? System can map MSI page anywhere, and just programming the correct address into MSI address register would make it work ?

In D26818#598251, @imp wrote:

In D26818#598049, @kib wrote:

In D26818#598018, @imp wrote:

In D26818#597997, @kib wrote:

In fact having gnuc-isms clearly marked is a useful feature.

Everything in this file is a gnu ism... no?

No, I do not view it this way. First, there is enough stuff not related to GNU C extensions. Starting from the compat shims for c89 or even K&R (but some stuff like static assert or array sizing in args, is really for c99), POSIX/XSI/BSD visibility macros, ending in thread-local shims etc that do not require gnu-isms.

Do you have a compiler I can test whatever I come up with then? I don't mean to be difficult, but if there's no way to test it, there's no way to know if the ancient stuff even works.

What do you refer above as an ancient stuff ? Except for __P() and perhaps __inline/__const/__volatile everything else is not about ancient. [We should get rid of __inline/__const etc IMO].

In D26818#598018, @imp wrote:

In D26818#597997, @kib wrote:

In fact having gnuc-isms clearly marked is a useful feature.

Everything in this file is a gnu ism... no?

The bigger part of !GNUC support is in machine/atomic.h.

I think that memory saving is still more important than really minor TLB usage optimization.

Ok, the capsicum argument is convincing enough to not go with /dev/eventfd route. But on the other hand having a single syscall that can also serve timerfd in future would be nice indeed. I do not think that shmfd should be plugged into this case.