Could the purpose of the new cpu method expressed as "move CPU state to PCB/thread save location in preparation for ..."? I think a comment like that would be due.

Taking into the account bz' grep output, I believe that the best route is to properly implement the struct module. For start it could be simply struct module {int dummy;}; if nothing is needed from its guts. But there should be an instance of the structure for each LKPI module, and THIS_MODULE underlying symbol should be magic indeed, but not in the sense of the current review. Instead, it should be only resolved locally, causing undefined symbol error if attempt is made to reference it from kld without the module symbol (section ?).

So what is the expected use of THIS_MODULE in Linux? Determine that current module is not that module, or something else?

More license lines

Licenses and man page fixes.

Add documentation and test.

Does it matter/used on arm64 and risc-v? I remember that psABIs require nx stack always for them. It might be that some (old ?) linker complained about the note on these arches.

Is it flag or enumeration?

Handle Mark' notes:

• move include of sys/_sigval.h at the top of pthread.h
• add comments to the signo flags definitions
• use _types.h names for types

-sort rwlock.h in kern_thr.c

In D44867#1022943, @olce wrote:

What's the problem with one more syscall ?

This review adds pthread_sigqueue(3) as requested. Right now it is not tested and unfinished: it lacks man pages update and test case, which I add after the issue below is discussed.

In D43306#1021418, @andrew wrote:

Rework to not guarentee the SVE registers are saved over a syscall other than sigreturn.
The ABI doesn't require SVE registers to be saved on a function call so extend this to a system call.
As dropping the SVE state on all system calls could get expensive only do it on context switch when in one.

Do you mean that td_frame is not constant on arm64?

Could you try to (greatly) simplify unionfs rename by using ERELOOKUP? For instance, it can be split into two essentially independent cases: 1. need to copy fdvp from lower to upper (and return ERELOOKUP) 2. Just directly call VOP_RENAME() on upper if copy is not needed.

Reference the IOMMU spec for pcireg.h

Go ahead with the current patch.

In D38852#1018757, @alc wrote:

Just so we're all on the same page, I want to point out the following: While this patch achieves contiguity, it doesn't guarantee 2 MB alignment. Let 'F' represent a fully populated 2 MB reservation, 'E', represent a partially populated reservation, where the population begins in the middle and goes to the end, and 'B' is the complement of 'E', where the population begins at the start and ends in the middle. Typically, the physical memory allocation for one chunk of stacks on amd64 looks like 'EFFFB'. While it would be nice to achieve 'FFFF', this patch is already a great improvement over the current state of affairs.

In D44581#1018549, @olce wrote:

In D44581#1017675, @kib wrote:

I do not like it. Errno has the defined scope of providing the communication between kernel and userspace. Some of the 'out of band' values like ERESTART and EJUSTRETURN and valid extensions because they modify the kernel->user edge behavior, all other in the list are hacks.

If "Errno" above means the standard macro errno, of course, but then ERESTART and EJUSTRETURN are also just hacks: They never reach userland (i.e., are never placed in errno).

They are hacks, but not in the same sense as the proposed value. ERESTART and EJUSTRETURN directly affect the content of the user context restored by the syscall return to userspace, same as any other userspace errno values, unlike the EUNSDEP (and unlike ENOIOCTL/EDIRIOCTL/ERELOOKUP).

Adding anything to errno is the wrong direction. If you want to get arbitrary error back from kldload(2), then perhaps kldload2(2) is due, with a signature allowing to pass back a text describing the error.
This would be similar to the interface of rtld itself, where dl*() functions do not try to extend errno but provide dlerror() with the description of the problem.