• Rebase.
• Fix bugs found by Peter.

Rebase.

Here's the result so far from the test: https://reviews.freebsd.org/P277

Committed in r349846.

Rebase and fix some problems found by pho.

I'll give this patch a try on a system running "poudriere bulk", which tends to use most of my system's swap.

Don't attempt to free the page if it is busy at all.

IMO fhold() and refcount_acquire_checked() should have the __result_use_check annotation.

Restore a lost comment.

Rebase.

Ping?

Shouldn't the VFS and VM changes be split into a separate review and committed separately?

In D20941#454586, @oshogbo wrote:

libnv may be used in different places as well, not only Capsicum.
Right now it is cross build: https://github.com/fudosecurity/nvlist

In D20941#454582, @oshogbo wrote:

It took me a while to try remind this issue:
https://github.com/google/capsicum-test/commit/b3104a4305a34ed2fc1b7cefbe7838f24b1ba4cd#diff-07efe4d15482f102e04663a89285a1dd

• Check for AF when promoting.
• Convert clean, RW mappings to RO when promoting.
• When demoting, assert that writeable mappings are dirty.

In D20863#454107, @dougm wrote:

It would be unfair to Peter to keep guessing solutions for this problem and letting him try them out. Does anyone listening know what I've got wrong here?

We also have the (unused) so_linger_set(), which should possibly assert that the input value is valid.

It seems that there are two related problems:

1. Refcount overflows triggered by a kernel bug, such as the one dissected in the link.
2. Refcount overflows triggered by malicious or buggy userspace, for instance by allocating 2^32 descriptors. (Note, at present this requires sizeof(filedescent) * (1 << 32) = 206GB of memory on amd64, including for descriptors internalized in unix socket buffers.)

• Restore comment in pmap_ts_referenced().
• Assert that writeable mappings are dirty in pmap_l2_demote_locked().
• Style in pmap_mincore().

Remove obsolete comment from pmap_ts_referenced().

In D20907#453501, @markj wrote:

I also plan to measure how long lld takes to link the kernel, with and without this change applied. lld is multi-threaded, so we can get a sense for whether using a read lock in pmap_fault() is beneficial.

• Leave AF set in unmanaged speculatively created mappings.
• Restore part of the comment above pmap_pte_dirty().

This matches the IPv4 change, so I'm fine with it going in. I agree that having a goto to the read lock case would make a bit more sense.

• Rebase.
• Update pmap_mincore() to only call pmap_pte_dirty() on managed mappings.

Fix ATTR_AP_RW_BIT handling bugs.