In D46635#1063118, @cem wrote:

In random_early_prime we divide the input into blocks of size sizeof(event.he_entropy)) and then process those one by one, with each block only being fed into one pool. so simply padding the entropy with zeros would result in most of the pools having no entropy.

Sure. But Fortuna seeds derive from all pools, only relying on at least one pool being uncompromised. (You could also just re-input the same 64 bytes 32x to touch all pools, although I don't think this buys you any additional safety.)

Fix bootstrapping on macOS.

Fix bootstraping on macOS.

Remove blank lines at the begining of functions with no local variables.

Add a comment explaining why we check mediasize this late.

Updated wrong review. Bring back the proper patch.

Compilation fix.

Compilation fix.

In D45243#1033059, @des wrote:

In D45243#1032859, @pjd wrote:

In D45243#1032364, @des wrote:

Have you considered implementing Apple's copyfile API?

I did, but I cannot commit that much time to implement it.

I'm not suggesting implementing the full API; just COPYFILE_DATA and COPYFILE_STAT and a handful of modifiers (COPYFILE_DATA_SPARSE, COPYFILE_EXCL, COPYFILE_MOVE, COPYFILE_NOFOLLOW, COPYFILE_UNLINK) should suffice. I'd offer to help, but I've seen the source code (it's on GitHub under APSL) so I probably shouldn't.

Remove too aggressive assert.

Add a missing argument to VNASSERT().

Use VNASSERT() instead of KASSERT().

In D45243#1032364, @des wrote:

Have you considered implementing Apple's copyfile API?

• Rename vnode_disk_create_vobject() to vnode_create_disk_vobject().
• Improve assertions.

• Introduce dedicated vnode_disk_create_vobject() for use by g_vfs_open(), so we don't have to do vn_isdisk() checks for regular files.

Fall back to read(2)/write(2) in case of EBADF and EISDIR.

Style.

• Don't call vn_getsize_locked() in case of VNODE_NO_SIZE.
• Assume we can have a disk for both cases (size == 0 and size == VNODE_NO_SIZE).

Thank you for working on this!

Remove compatibility code from libc.

In D43488#991394, @mjg wrote:

What's the motivation here? If you are running into scalability problems, it has to be allproc and proctree locks (amongst others).

PoC, still missing bitset(9) manual page update. Part of: https://reviews.freebsd.org/D43488

Introduce kern.pid_max_limit.

Remove MAX_PID check from pkill.

In D43077#982025, @kib wrote:

For NO_PID, also look at usr.sbin/bsnmpd/modules/snmp_hostres/hostres_swrun_tbl.c and contrib/sendmail/src/sendmail.h (later is probably fine).

Add missing include.

• Remove hardcoded PID_MAX from sched_{g,s}etaffinity().
• Remove hardcoded NO_PID from bsnmpd.

In D43077#982024, @kib wrote:

If you manually upload diffs, please generate them with something like git diff -U999999 <whatever> so that the full content is available.

We shouldn't make the code more complex and less readable just to optimize for some rare edge cases. If someone disables block cloning, they are most likely not too concerned with performance and trying to avoid an extra vnode lock at the expense of code readability is, in my opinion, the wrong approach.

Thank you for the fix!

In D38814#884116, @mjg wrote:

I think this is a step backwards and it is not what I suggested.

For example now any fs which does not provide it's own primitive will take a trip through returning EOPNOTSUPP when it can be avoided.

I suggested everyone handling as much as they can and otherwise punting to vn_generic_copy_file_range or a differently named fallback with the same result.

To further illustrate the win in nullfs case, consider the following with 2 nullfs mount points:

1. we land in null_copy_file_range or whatever
2. both target vnodes get "unwrapped"
3. the vop gets invoked in vnode1 with both as arguments and we are done here

With the proposed patch it will be instead:

1. we land in null_copy_file_range or whatever
2. both target vnodes get found + refed
3. the vop returns EOPNOTSUPP
4. the routine unrefs vnodes and returns
5. ... now vn_generic_copy_file_range will keep calling VOP_READ and VOP_WRITE while looking up + refing (and unrefing) vnodes for each call

In D38814#883415, @asomers wrote:

LGTM. But is there any file system that you expect to support cross-mountpoint copy_file_range ?

In D38803#883156, @mjg wrote:

My grep fails to find any existing custom routines, I'm guessing one for zfs will be showing up later. I think this also means there is no worry of any backwards-incompatible breakage.