Add tests

Why did you left trywrlock() out of this change? POSIX allows both wrlock() and trywrlock() to return EDEADLK, and our man page notes the error for both functions. So if making one return the error, I do not see why not making another to behave identically.

Lock curthread for name.
Rename to pthread_query_all_np().
Man page editing.

Disallow altroot use for RBENEATH lookups.
Clear altroot on cap_enter().
Hardening of cap_enter().

In D60035#1397512, @markj wrote:

I would really like to see tests which specifically exercise handling of the altroot across execution of setuid executables, and jail_attach(). We should also make sure that if a process sets an altroot and enters capability mode, that the altroot doesn't enable lookups that would otherwise be disallowed. In other words, if a process in capability mode does a dirfd-relative lookup and the lookup fails with ENOENT, then the fallback lookup must not succeed. Same for O_RESOLVE_BENEATH lookups. Right now it appears that we retry failed dirfd-relative lookups unnecessarily?

In D60832#1397713, @aokblast wrote:

In D60832#1397587, @markj wrote:

In D60832#1397040, @kib wrote:

In D60832#1397005, @aokblast wrote:

In D60832#1395914, @kib wrote:

In D60832#1395514, @aokblast wrote:

In D60832#1395064, @kib wrote:

You could query the kernel to see the state of the thread using kinfo_proc().

Somewhat curiously, I thought about adding an API to query the list of the threads for the current process.

Yes, but it is a test for pthread_tryjoin_np so :).

I do not understand what do you intended to say by this sentence.

I mean this robustness change is needed as we are testing pthread_tryjoin_np, which should not query status by using kinfo_proc.

I still do not understand why should it not. Using kinfo would make the test more precise IMO, But I do not intend to block this change.

I also do not really understand. It seems fine to use kinfo. See tests/sys/kern/procdesc.c:wait_for_naptime() for an example. It is just an alternative method to avoid polling while you are waiting for thr_fun() to wake up.

Wouldn't wait_for_naptime still poll on something?

This is fine but also it means that the object is corrupted. We do not perform exhaustive checks for the ELF consistency in kernel, generally.

I only asked about one chunk from three. I still think that the other two chunks are good.

In D60832#1397005, @aokblast wrote:

In D60832#1395914, @kib wrote:

In D60832#1395514, @aokblast wrote:

In D60832#1395064, @kib wrote:

You could query the kernel to see the state of the thread using kinfo_proc().

Somewhat curiously, I thought about adding an API to query the list of the threads for the current process.

Yes, but it is a test for pthread_tryjoin_np so :).

I do not understand what do you intended to say by this sentence.

I mean this robustness change is needed as we are testing pthread_tryjoin_np, which should not query status by using kinfo_proc.

Fix chroot(8) -A.
Lots of nits fixed found with the automatic review.

Hopefully better comments, passed though some automatic checker.

Free allocated fake pages.
Add some comments explaining the intent.
Avoid going through the vm_page_array[] at all, the page physical address is all that is needed for a fake page construction.

Add copyright statement to the man page.

Rework API.
Add man page.
Fix pre-existing race also affecting the patch.

In D60832#1395514, @aokblast wrote:

In D60832#1395064, @kib wrote:

You could query the kernel to see the state of the thread using kinfo_proc().

Somewhat curiously, I thought about adding an API to query the list of the threads for the current process.

Yes, but it is a test for pthread_tryjoin_np so :).

Zero reserved fields of the info structure.

Do not expose internal pointer to the thread name.

Man page and test will be done after discussion.

In D60832#1395064, @kib wrote:

Somewhat curiously, I thought about adding an API to query the list of the threads for the current process.

You could query the kernel to see the state of the thread using kinfo_proc().

I believe this is fine as the code change. The termios(4) man page would benefit from some clarification of this sentence:

A process does not relinquish its
controlling terminal simply by closing all of its file descriptors
associated with the controlling terminal if other processes continue to
have it open.