In D53026#1211786, @des wrote:

@mjg @kib do you agree that there is no reason why the userland implementation of realpath() would succeed after the syscall failed, except in the case of a race?

I intend to commit this early next week.

Bug fixes after Peter' testing.

You might hide the workaround under some sort of ifdef gcc. It would be tricky, though, since this needs to happen inside the macro.

Ask kargl@ for explicit feedback and approval of the patch.

Rename the option to 'unixbypass'.
Add documentation.

Might be bzero() whole *kvo on each iteration?

In D52983#1210802, @markj wrote:

This should be documented in mount_nullfs.8. The implementation looks ok to me.

Rebase. Document KQUEUE_CPONFORK

Might be s/compiler/gcc/

In D52939#1209577, @rlibby wrote:

There are other options for how to spell the internal macros. I'm open to something else that might be more clear. Something in particular I considered is just providing

#define _RB_OP_RVAL(elm, op, dir)	((__typeof(elm))		\
					((__uintptr_t)(elm) op (dir)))
#define	_RB_OP(elm, op, dir)	((elm) = _RB_OP_RVAL((elm), op, (dir)))
#define	_RB_OPUP(elm, field, op, dir)	_RB_OP(_RB_UP((elm), field), op, (dir))

and not _RB_{OR,XOR,ORUP,XORUP} and then having the rb code look like e.g.

			_RB_OPUP(parent, field, ^, elmdir);

instead of _RB_XORUP(parent, field, elmdir).

In D51623#1209355, @jhibbits wrote:

In D51623#1209045, @kib wrote:

It seems that you always build 4-level intermediate page table. Wouldn't it blow up if the source kernel is running in LA57 mode? [Kernel always expect LA48 on start nonetheless]

You're right. I'll need to force it down to LA48 when entering the new page table. I'll have to check on this, as I'm not familiar with configuring LA57 mode.

It seems that you always build 4-level intermediate page table. Wouldn't it blow up if the source kernel is running in LA57 mode? [Kernel always expect LA48 on start nonetheless]

Fix acq/rel description for RMW.

Yes indeed what you noted is a bug in the description of acq/rel for atomics that perform more than one memory access, basically all RWM atomics. I think just fixing that would be enough.

Thanks.

Both changes (Versions.def) and this one can be MFCed, but we normally do the Versions.def change separately because there might be other symbol in FBSD_1.9 that is merged before your recallocarray.

So are ILP32/LP64 defined for cheri? If not, please mention it explicitly.

Are ILP32/LP64 undefined for cheri? If yes, I think that this should be explicitly mentioned, and in fact these macros are still useful, to exclude the outliers from regular arches.

This is not a complete patch, I think? The other bits except smr lock are missing.

In D52818#1206828, @brooks wrote:

In D52818#1206819, @emaste wrote:

Is this true for 32-bit powerpc as well?

From what I could tell in compiler explorer, yes.

Might be, keep the note but replace the symbol by a descriptive text?

Markj@ editing

Tighten lock assert in reaper_clear()

The commit message body is ought to be more detailed than <nul>.

Be explicit about what might happen on aarch64.

If /usr/sbin is fine, but libexec is decided, then it should be /usr/libexec and not /libexec. /libexec is for something that is needed when booting the system.

Remove .Tn