sys/user.h: remove XXXSKE markers

There are opportunities with amd64 at least, but I can do it myself after this patch lands. Thanks.

My previous answer was probably not quite clear in some aspects. I mean, on make installkernel we should either rename /usr/lib/debug/boot, or remove it, before installing new debug symbols.

In D55077#1258804, @tembun_bk.ru wrote:

In D55077#1258798, @emaste wrote:

Kernel debug files aren't controlled by WITH_/WITHOUT_DEBUG_FILES so should not be removed here

Oh, I see, these seem to be controlled by WITH[OUT]_SPLIT_KERNEL_DEBUG. But where we should put the code that will mark files in /usr/lib/debug/boot/{kernel,modules} 'obsolete'? I guess it must be somewhere in sys/, but I'm not sure where exactly.

Well, API or ABI, as is it is a sudden change in the behavior for the same code compiled against new or old base. IMO the #define posix is the required workaround if we going to change the ptsname_r() this way.

I think the idea was to use VARARG, but then the types and arg names have to be split out of it. Something similar to what is done to EXTERROR() from sys/exterrvar.h and CTR() from sys/ktr.h. But it might be too convoluted for the limited use.

FreeBSD is realtime kernel, where regions with disabled interrupts are exceptional. Trap happening with interrupts disabled means that CPU meeting some conditions that should not be there.
It might be that trap.c and exceptions.S somewhat evolved, but the guiding rule there was a simplification. As a secondary effect, it might take exceptions with interrupts disabled, in some cases.
It still assumes that e.g. GSBASE is valid, which is generally not true for regions with disabled interrupts. So I prefer to keep it close to original design.

Fix locking error with sched_bind()

Execute SCHED ops in critical section

Minor clarifications to the description.

finalize the change

I think it would be simpler if you commit this version now, then I will provide the proper herald comment explaining the modes, in mine SAFE patch.

In D54996#1258747, @olce wrote:

In D54996#1258511, @kib wrote:

I am fine with either case, IMO it is simpler to disable the interrupts unconditionally. It is boot code only anyway, and we should target the code size and not code speed.

Done.

But did you noted my yesterday comment about SCHED for the herald comment?

Yes. It was more of my intention to leave that discussion for when reviewing your patch instead of amending the code comments not to match what the code currently does, but there seems to still be some divergence here.

I think our goal should be to make these MSR accesses atomic, and change the rest to make it happen rather than the other way around. The SAFE variant should not be treated differently.

The only difference for SAFE is using *msr_safe(), which can fault with #GP(0) -> T_PROTFLT with handlers "installed" through pcb_onfault. After amd64's trap.c code re-examination, I fail to see any reason why this wouldn't work with interrupts disabled or even while holding a spinlock. So, where does "There, it is absolutely required to not hold thread lock around msr_safe() accesses" come from?

Do you mean that the low-level startup, e.g. hammertime() for amd64, and initarm() for arm64, must be tagged with __nosanitizeaddress as well? (And recursively every function that is called from them, at least up to the point where ifuncs are resolved).

In D55056#1258736, @arrowd wrote:

You do not need to change fuse_vfsop_unmount()

Not sure how is this possible.

I put debugging printfs into the destructor and fuse_vfsop_unmount(). When I kill -KILL the daemon I see:

===> fdata_dtor
===> fdata_dtor, mnt_ref: 4
===> fuse_vfsop_unmount, ref: 3

The control first enters fdata_dtor, then reaches the code you suggested in the last comment, then enters dounmount and eventually reaches fuse_vfsop_unmount with mnt_ref: 3. This scenario works.

Now if I do proper umount /foo I end up with

===> fuse_vfsop_unmount, ref: 4
===> fdata_dtor

The dounmount -> fuse_vfsop_unmount path happens before the destructor and the refcount is too high, which makes fuse_vfsop_unmount to sleep in [mntref]. When fdata_dtor gets executed the fdata variable is already NULL, so it exits early.

I guess, your intentition was to make the destructor dereference that last reference so that fuse_vfsop_unmount would be able to proceed?

In D54996#1258510, @olce wrote:

Gentle ping.

Is it OK like that? Or would you prefer, e.g., always disabling interrupts in the MSR_OP_LOCAL case?

No, this is not what I suggested. You do not need to change fuse_vfsop_unmount(), instead in fdata_destroy()

	if (fdata->mp != NULL) {
              if fdata->dataflags & FSESS_AUTO_UNMOUNT)
		dounmount(fdata->mp, MNT_FORCE, curthread);
	      else
                 mnt_rel(fdata-mp);
       }

modulo small details that you should figure out.

Add comment explaining why dvp is unlocked, and how possible reclamation is handled.

BTW, ls(1) and find(1) use -P for the same functionality. ls(1) does not fail if the argument is not a symbolic link.

FWIW, we do not disable EFI RT timer services when we attach to rtc, and in reverse. I am not sure, might be we should. Right now we lock accesses according to the UEFI spec recommendation.

Editings by olce.

Add assert that ast handler is called for curthread.

Simplify. Use TDP_SCHED1 instead of the new field in the ts structure.