blender,nheko,libquotient: stop disabling PCH, ok rsadowski
The need for disabling precompiled headers disappeared at some point in
the last few years. This was related to C++20, libstdc++, and stdarg.h
and __bsd_locale_fallbacks.h. Some of this changed in recent compiler
updates, and cmake is also much more modern.
minor markup improvements:
in particular, more consistently use .Cm for module names, Makefile targets,
and fixed strings like Yes and No, .Ev for Makefile variables,
and .Sy for command names not documented in the present page
OK daniel@
fmt: fix build with libcxx22, ok sthen
fmt relies on pulling in stdlib.h for malloc/free via C++ headers, and this
no longer happens with libcxx22. So follow the approach taken by upstream
and include it explicitly.
SEV: Add option AMDSEV
To allow building the small RAMDISK kernel without SEV-* support
introduce the option AMDSEV.
When running a non-SEV kernel as a SEV guest we will raise a #VC
exception on the very first CPUID instruction. To allow a somehwat
graceful termination keep the locore0 #VC trap handler, fall through
to the termination code and issue TERMINATION request to the
hypervisor. In all other environments #VC will never be raised and
the kernel runs normally.
Build RAMDISK without SEV-* support, all other kernel keep SEV-*
support.
While there, cleanup and unify some definitions of the MSR protocol.
ok kettenis@
pf(4): connection counter for source track must use atomic_{inc,_dec}()
The connection counter is advanced when on state transition from
SYN_SENT to ESTABLISHED. That code in pf(4) currently runs with
no locks. If two packets happen to share the same source tracking
node, the race may occur. Two packets try to advance connection
counter simultaneously but only one operation is observed.
There is similar race between packet and timer that removes
expired state entry, the timer drops the connection count for
the source tracking entry while packet does opposite.
The result of those races may lead to connection counter underflow.
The issue was investigated and kindly reported by
Janak Trivedi <janakktrivedi _at_ gmail _dot_ com>
Feedback and suggestions by bluhm@
OK @bluhm
