looks OK, but tagging for srcmgr review since some of it looks weird too :)

code looks OK, though my arm assembler is rusty. tagged as srcmgr for review

srcmgr review, likely OK, but not actually accepted.

Wonder what the status of this is... Tagging for srcmgr review, even though it didn't make it to accepted.

tagging for srcmgr review. These are all likely a sea of conflicts now, but that should be easy to resolve.

Looks like this would be easy to forward port. But the patch series likely needs some work. tagging for srcmgr review.

Due to D41976

In D41859#955406, @kib wrote:

In D41859#955405, @dchagin wrote:

In D41859#955376, @kib wrote:

In D41859#955367, @dchagin wrote:

Btw, the way you proposed will not work, due to nosys marked as ABSENT and in such cases syscall_thread_enter() return ENOSYS.

Are you saying that sometimes we do not send SIGSYS for FreeBSD native processes?

yes, OBSOL syscalls, https://people.freebsd.org/~dchagin/nosys.c

And ABSENT as well?

In D41859#955405, @dchagin wrote:

In D41859#955376, @kib wrote:

In D41859#955367, @dchagin wrote:

Btw, the way you proposed will not work, due to nosys marked as ABSENT and in such cases syscall_thread_enter() return ENOSYS.

Are you saying that sometimes we do not send SIGSYS for FreeBSD native processes?

yes, OBSOL syscalls, https://people.freebsd.org/~dchagin/nosys.c

And ABSENT as well?

In D41859#955376, @kib wrote:

In D41859#955367, @dchagin wrote:

Btw, the way you proposed will not work, due to nosys marked as ABSENT and in such cases syscall_thread_enter() return ENOSYS.

Are you saying that sometimes we do not send SIGSYS for FreeBSD native processes?

In D41859#955367, @dchagin wrote:

Btw, the way you proposed will not work, due to nosys marked as ABSENT and in such cases syscall_thread_enter() return ENOSYS.

Are you saying that sometimes we do not send SIGSYS for FreeBSD native processes?

In D41859#955044, @kib wrote:

D41901 sounds as a hack, again.

Am I right that the issue is that nosys() sends signal, while Linux' nosys should not? If yes, there are two options:

yes

D41901 sounds as a hack, again.

In D41859#954114, @kib wrote:

Can you explain more? Does linuxolator need syscall slot 0?

Can you explain more? Does linuxolator need syscall slot 0?

In D38459#950118, @jfree wrote:

This patch has been applied to src under commit af93fea710385b2b11f0cabd377e7ed6f3d97c34.

There doesn't seem to be a way to associate this review directly with that commit, so I'm just going to abandon it.

This patch has been applied to src under commit af93fea710385b2b11f0cabd377e7ed6f3d97c34.

In D38459#947334, @imp wrote:

Are there any tests?

I have this staged and plan to commit once I confirm universe builds.

hmm, looks like the problem in how protections handled during stack grows

debootstrap for Ubuntu 23.04 requires Linux ionice command which depends on these syscalls