In D23802#523392, @jilles wrote:

In D23802#523379, @kib wrote:

The buffer was written by the function, this is my point of the aliasing breakage.

A const pointer does not require that the pointed-to object remain unchanged; it merely suggests that it not be modified via the pointer. There may be other non-const pointers to the same object or const may be cast away.

Yes, but why is it useful even slightly to prevent modifications to (successfull) result of the vn_fullpathX() ?

In D23802#523080, @kevans wrote:

In D23802#523059, @kib wrote:

I really do not understand it. The *retbuf *is* modified by vn_fullpath. I believe you are lying to the compiler' aliasing analysis this way.

*retbuf is, but importantly **retbuf is not. This should be the difference between const char ** and char * const *

I really do not understand it. The *retbuf *is* modified by vn_fullpath. I believe you are lying to the compiler' aliasing analysis this way.

In D23428#522227, @mjg wrote:

So any incarnation of this patch makes the following fail contrib/netbsd-tests/lib/libc/c063/t_fstatat.c:

ATF_TC_BODY(fstatat_fd, tc)
{
        int dfd;
        int fd;
        struct stat st1, st2;
        ATF_REQUIRE(mkdir(DIR, 0755) == 0);
        ATF_REQUIRE((fd = open(FILE, O_CREAT|O_RDWR, 0644)) != -1);
        ATF_REQUIRE(close(fd) == 0);
        ATF_REQUIRE((dfd = open(DIR, O_RDONLY, 0)) != -1);
        ATF_REQUIRE(fstatat(dfd, BASEFILE, &st1, 0) == 0);
        ATF_REQUIRE(close(dfd) == 0);
        ATF_REQUIRE(stat(FILE, &st2) == 0);
        ATF_REQUIRE(memcmp(&st1, &st2, sizeof(st1)) == 0);
}

That is, they fstat twice to different buffers and memcmp the result. Since the spare area is not populated this fails. This makes me worried there are actual programs which also do it and which would break because of this change.
Thus another take is this: on Linux struct stat is 144 bytes. On FreeBSD this struct without any spares would have precisely the same size. The upshot of shrinking it to Linux size would be that userspace sees the same one (and uses less memory). If spares are to be preserved, we can use fewer of them. Adding 16 bytes in spares brings the structure to 160 bytes in total. I can add the necessary compat for 12.x binaries.
Note this change on top of other speed ups gives about +10% for fstat/second rate which I think makes it worth it given how often fstat is executed.
Thoughts?

I would be slightly less worried about this hack if you added asserts that odevvp does not get any buffers on its bufobj queues.

Overall this looks reasonable.

In D23774#522552, @markj wrote:

In D23774#522504, @kib wrote:

I very much dislike this. It repeats the mistake of KASSERT() while not eliminating KASSERT.
IMO the big and perhaps the only problem of KASSERT is that it was written before C99 so it cannot use variadic args. If the () around the printing part are dropped, then we can do any additions to the printed line without adding yet another set of macros.
So if you want to spend time on this, doing the convertion of KASSERT to variadic, and dropping the braces, would be a first step IMO. Personally I am fine with the churn.

I don't really care about the parens either way, but I don't want yet another assertion macro. I'd prefer to see kassert_panic() take func or LINE and FILE arguments. Existing consumers can be fixed up to avoid printing redundant info, it could be combined with the paren removal.

I very much dislike this. It repeats the mistake of KASSERT() while not eliminating KASSERT.

Ok, lets postpone AT_NOFOLLOW.

How jails and chroots are handled ?

In D23587#520661, @mjg wrote:

In D23587#520606, @jeff wrote:

This would be a good use for tick based (non-atomic) smr. It would have a cheaper simpler write path. I don't object to this patch but it might get replaced again.

In the current code the commonly executed codepath is expanded with:
#define syscall_read_barrier() __compiler_membar()
it does not get any cheaper than that for that end. Anything else *adds* work.
On the other hand we really don't expect to register/unregister syscalls a whole lot and let alone catch someone executing them while we do so. If someone would be looking at improving the area, they can consider working on lending the priority to blocked syscall users.
In fact in my opinion the facility should be removed.

Why ?

Biggest objection is that there is still no ABI for atomic stuff even on x86, so each compiler (version) is free to choose the implementation that it finds suitable and that non necessary compatible with the other' compiler implementation.

One setpend() was missed after refactoring.

Thanks.

re-upload with context.

Apply full pack of nano-optimizations, change sigfastblock_fetch_always to bool.

If one day I feel offended enough by this breakage, it seems that ptracestop() can be used to restore the functionality.

Give up. Do not build dtrace.

In D23699#520445, @markj wrote:

I don't see a problem with excluding the dtrace modules if KDTRACE_HOOKS is not defined, but the patch doesn't completely fix the problem. KDTRACE_HOOKS is a kernel option that means, "the kernel implements the interfaces required by dtrace.ko and friends." It doesn't make sense for the modules themselves to be modulated by this option.

Why ? This is exactly how options work, at least for the coherent build of kernel and modules.

If module is buildable, I do not see a reason to not include it into the build. Mark can provide more input on this issue.

Another approach, summary will be updated.

It was a test for r357894. The victim thread exiting, then I need to wait for it to exit but not join, to issue cancellation request.

Ok, consider it from the following angle: does doing the sweep for CTLTYPE_NODE->CTLTYPE_PROC improves the code or just allows to avoid adding a flag, and then removing it ?

Man page edits.
Add symlink for man.