https://reviews.freebsd.org/D55045

In D55045#1263761, @markj wrote:

Feel free to ignore this suggestion: rather than having MSR_OP_SAFE, I would instead introduce x86_msr_op_safe(). Then x86_msr_op() can keep the void return type.

I prefer to expose one function. There is no harm from returning unused value.

Keep interrupts disabled around ops for SCHED.
Allow SAFE variants of RENDEZVOUS.

Ok, I give up to make some progress. I still disagree with this approach.

In D55255#1263689, @mmel wrote:

I understand that libsys might be the last frame.
However, this also means that the unwinder is supposed to call the function aeabi_unwind_cpp_pr0, found in the .ARM.exidx section of the corresponding object.
In your case, this is buildin_trap().
Is this right?

This is the last question, I promise.

We do want the unwind info generated for libsys. Although libsys cannot generate exceptions synchronously, it still might be the last frame for stack where signal is delivered for process that slept in the slow syscall. The unwinding info is needed for any dwarf stack unwinders then, like gdb, libunwind, etc, even in its armv7 variant, as far as I understand.

IMHO the control flow could be made less confusing. Right now it is 'break' -> userret, and in one place it is goto no_userret. I suggest to add a control variable like 'use_userret', set to true, assigned from svc_handler() return value. Then instead of goto no userret. check the value of use_userret around userret() call. Hope it is understandable.

In D55255#1263672, @mmel wrote:

Should not these symbols also be marked as weak? Hidden symbols are not 'overloaded' in the same library. kib, jrtc27 any comment about this, please?

Expand LASS in the comment.

In D55218#1263398, @emaste wrote:

We'll want to add a note to mitigations(7) as well; I can take a look at that.

Drop unneeded chunk.

Add comment why SMAP is required.

Require SMAP for LASS.

Bump prio around SCHED

Well, I said that the kernel is real-time, not that the system is. One of the reason why it is not is the frivolous use of the sections with disabled interrupts, and I do not see why adding more of it.
For instance, RENDEZVOUS which disables interrupts must wait for all CPUs to leave the sections of disabled interrupts, which is accumulating and causes even longer delays.

Move setting CR4.LASS into initializecpu()

In D55056#1261167, @asomers wrote:

I have no idea what is double-release.

Calling vfs_rel twice on the same struct mp, or something like that.

In D55056#1261107, @arrowd wrote:

My concern is that the pointer to mp, stored somewhere in fusefs data, gets reused for other mount.

How could this happen? My understanding is that it can't happen until we unmount and the unmounting may happen for two reasons:

• User called umount
• A FUSE process terminates abnormally, but has passed -o auto_unmount.

In both cases we perform the unmounting and then set fdata = NULL. So, for example, if the daemon first performs a proper umount and then dies due to SIGKILL, we won't touch fdata->mp in the destructor.

I too can't find a way for Konstantin's fear to happen. But keeping the mountpoint reference is still a good defensive coding practice.

And remove stale comment

Remove blank line

In D55169#1262376, @tembun_bk.ru wrote:

Thank you! Do you think that kld(4) would be an appropriate place for this description? I guess I can incorporate it there.

Ping?