For the changes in unionfs_lock(), there is indeed a window after the interlock drop and before lock acquire and drop where the "root" reference unionfs holds (through unionfs_node; the one that allows to call vholdnz() above) could be dropped (it's the same window described in the big comment about checking the proper target vnode (lower or upper) was locked).

This change is an improvement without drawbacks, so should be committed.

We have indeed several problems with VOP_OPEN()/VOP_CLOSE(), e.g., they are not always called in pairs, and even if they are the passed td may not match between an open and close. These interfaces need serious revision, in particular determining which exact info the filesystems would like to use and if there are better ways to obtain them.

Please don't forget to exclude the changes in sys/netinet/ip_carp.c as they are completely unrelated.

In D52960#1212126, @rmacklem wrote:

Looks ok to me. I'll leave min vs MIN up to you.

Seems good (disclaimer: I only did manual code analysis, but didn't test).

Update after discussion and fixing the last use of vm_domainset_iter_page_init() with an object not write-locked in D52982.

Indeed, that is the only problem in UMA.

Please add Reported by: olce at commit, thanks!

It seems good indeed that not all man pages related to libraries go into separate packages, as some are targeted at administrators.

Superseded by the series starting at D52960 (through D52964).

In D52263#1194974, @rmacklem wrote:

In D52263#1194959, @olce wrote:

So, what do you think of:

1. To support the protocol, we accept up to 17 groups (1 + 16), but no more (extensions are not supported).
2. But we discard the 17th one, as we don't have room to store it.

This is in fact what the inline decode version is already doing.

It would be nice if all 17 groups ends up in the real cred structure,
but I now recall looking at this long ago and leaving it, since I
was not willing to revise xucred.

It might be worth looking at what else uses xucred to see if adding
a separate cr_gid field for the additional gid is feasible without
too much churn. (xucred was just defined when ucred was being
changed to handle more groups)

• Amend in the direction of feedbacks.
• Move the whole block of text at the send of the section (but still before the recent C++ section).

Looks good (but please see suggested changes). I've not tested the patch though.

In D52850#1208187, @markj wrote:

I guess that should be removed too?