Is it intended for userland to be able to pass KERN_CLOSE_RANGE_MAXFD? If not we should check for it in the sys_ wrapper and return EINVAL.

Hmm... based on the current definition of our close_range, we would have to since Linux is expecting ~0U to close all fd, and I've represented both fd parameters as int. I guess I should likely change this to u_int to match -- I didn't pay enough detail to this initially, and we usually don't accept unsigned fd in syscalls so I didn't think much of it.

The internal kern_close_range definition is likely going to change to take u_int fds, so this will change to ~0U... is it worth keeping the definition around at that point, just to formalize it?

lowfd and highfd are not really descriptors, but rather bounds for a range of descriptors. Having fds typed as int is useful for detecting a programming error that results in userland specifying an fd of -1, but here we give a special meaning to a value of -1 (or ~0U, whatever) for highfd. So from that perspective, using u_int makes sense to me.

Since we are allowing ~0U from userspace, should that be documented in the man page?

Fair- I'll go ahead and change that to match.

I think once the implementation takes unsigned values instead, documenting it specifically in the manpage doesn't mean too much. At that point, there is no specific check for ~0U and it's no longer a violation of what would normally return EINVAL, it just gets naturally clamped down to fdp->fd_lastfile and the manpage should make sure to indicate that lowfd, highfd will get clamped to the valid range.

Shouldn't the check come before the clamp? Suppose a process has descriptors 0, 1 and 2 open and fd_lastfile is 2. closefrom(3) would return EINVAL.

Hmm... I thought I had wanted different semantics for close_range (i.e. close_range(3, ~0U, 0) in that same scenario to return EINVAL), but I suppose that also makes little sense.