In D46151#1052141, @andrew wrote:

In D46151#1052139, @kib wrote:

Am I right that this revision does not fix the issue, but covers it with more bits from the unused space in the head index? It is still possible that head wraps around, just less likely now that full 2^32 iterations needs to occur under it?

It's still possible, just very unlikely. Even if the value wrapped it would need to be the correct value for the cmpset to succeed.

Am I right that this revision does not fix the issue, but covers it with more bits from the unused space in the head index? It is still possible that head wraps around, just less likely now that full 2^32 iterations needs to occur under it?

If this is useful in kernel, why hen why not use mutex from either normal libpthread or mtx from libstdthread? (The later seems to not have mtx_owned analog)

Make the exit mutex recursive.

In D46113#1051367, @markj wrote:

In D46113#1051278, @kib wrote:

Does this mean that thread0 is no longer functional? If yes, can we re-purpose it for something/anything instead of throwing?

Right. Do you have any suggestions there? Hmm, after these changes there is still the vm_daemon(), to handle RACCT_RSS and RLIMIT_RSS. That is probably a good candidate.

Does this mean that thread0 is no longer functional? If yes, can we re-purpose it for something/anything instead of throwing?

In D46104#1051252, @mmel wrote:

Adapted to kib's objections.

These were anything but objections.

In D46108#1051006, @imp wrote:

It wouldn't hurt to note in the commit message that this brings us into compliance with posix.1-2024 on this point. Many people may not know why the austin group matters

Add pthread.h.
Describe the behavior in the man page.

In D46099#1050861, @bz wrote:

Address comments from @kib (I left the bridges alone but I agree a better name would be appreciated)

In D46057#1050007, @alc wrote:

In D46057#1049994, @markj wrote:

Out-of-tree code can make the same change, no need for a __FreeBSD_version bump I think. stable/11 is the last branch where kmem_arena is a distinct entity.

I checked drm-515-kmod, drm-61-kmod, and virtualbox-ose-kmod. They don't appear to have any direct references to kmem_arena.

In D46045#1049665, @np wrote:

There are also some macros in key_debug.h (for keys only) that accept a bitmap of stuff to debug. It would have been nice if ipseclog() was also written this way and then we could control its run-time verbosity and also just have added a bit for ipsec-offload debug. But oh well. I'm okay with whatever you and kp agree on.

In D46045#1049663, @np wrote:

Does ipsec offload need a debug knob of its own? Can't we use any of the existing stuff for debug (from netipsec/ipsec.h):

#define ipseclog(x) do { if (V_ipsec_debug) log x; } while (0)
/* for openbsd compatibility */
#ifdef IPSEC_DEBUG
#define IPSEC_DEBUG_DECLARE(x) x
#define DPRINTF(x) do { if (V_ipsec_debug) printf x; } while (0)
#else
#define IPSEC_DEBUG_DECLARE(x)
#define DPRINTF(x)
#endif

This also matches the UFS semantic, which considers directory empty if it consists only of whiteouts.

Switch to vm_page_wire.