In D20584#445378, @rmacklem wrote:

Yes, I did understand the comment w.r.t. range_locks. I fixed the rest of the stuff for two vnodes locked
concurrently, but I couldn't see an easy way to do range_locks on both of them without a LOR.

Because of the above and because it allows me to use FIOSEEKHOLE/FIOSEEKDATA, I've changed
the code to call vn_rdwr() with the vnodes unlocked and I just let vn_rdwr() deal with the range_locks, etc.

So you relock range for each chunk ? This defeats the purpose of the range locking. Should copy_file_range() be atomic WRT other reads and writes ?

Is this a fix for the i386 wrap issue, or just a related change ?

I believe that you should allocate a flag in the feature note and use it to opt-out (or opt-in ?) of max_prot.

Lowercase comments.

I think this version of code is technically correct. I still would prefer the fd-based sysctl instead.

In D20519#443214, @asomers wrote:

In D20519#443196, @kib wrote:

I suspect it could be more useful to pass a file descriptor number to the sysctl, leaving path manipulation to open. E.g., this way it would be possible to hack-reclaim unlinked inodes.

OTOH, taking a file descriptor instead of a pathname means that it wouldn't be able to reclaim inactive vnodes. For my purposes that's more important. For example, I want to be able to reclaim a directory that doesn't currently have any open file descriptors.

I suspect it could be more useful to pass a file descriptor number to the sysctl, leaving path manipulation to open. E.g., this way it would be possible to hack-reclaim unlinked inodes.

Could you please update the diff to include the definition if vm_page_wired() ? I expect it to be trivial.

Imagine that there is no pseudo ttys in the system, and user called mkdir('/dev/pts'). Then a new pty pair is created, which makes a device node in /dev/pts. On device destruction, the node is removed, and its contained directory is removed if empty. But '/dev/pts' was created by user, not my makedev(9).

Your follow-up questions definitely show that you want some mountd.conf config file, e.g. to manage -I flag. The file should be re-read on SIGHUP.
I could argue that it is reasonable for mountd.conf to provide all options supplied as command-line arguments to mountd.

In D20347#441878, @manu wrote:

In D20347#441757, @kib wrote:

This all looks fine, except one detail. I reviewed UEFI 2.8 description of EFI_BOOT_SERVICES.GetMemoryMap() but did not found a mention that they require the map ordered by phys address. Did you miss the code to sort the map ?

In chapter 4.6, EFI_MEMORY_ATTRIBUTES_TABLE it is said : The list must be sorted by physical start address in ascending order.

I am even more confused. The description said that about EFI_MEMORY_ATTRIBUTE, not about memory map. And you correctly use memory map, because MEMORY_ATTRIBUTE seems to be some after-thought patch only applicable to EFI runtime code and data.

This all looks fine, except one detail. I reviewed UEFI 2.8 description of EFI_BOOT_SERVICES.GetMemoryMap() but did not found a mention that they require the map ordered by phys address. Did you miss the code to sort the map ?

As Mark noted, move of P_TRACED cleanup should be a separate commit which makes sense to ask pho to test. Also I recommend to split introduction of proc_add_orphan() into another preliminary commit, since it will make merges easier.