When the pagedaemon is triggered to create free memory, there may be
sleeping pmemrange allocations with multi-page alignment requirements
which can't be satisfied by the simplistic freeing of (solo) pages
which the pagedaemon performs. As we near starvation, fragmentation
is the main problem. Our free list could be large enough that the
pagedaemon sees no reason to do more work, but also too fragmented to
satisfy a pending allocation request with complex requirements
(imagine asking for 512K of physically linear memory which is DMA
reachable). When the requirement isn't satisfied, the pagedaemon is
told to try again, but again doesn't mean harder because it has no
mechanism to try harder. It's tracking variables do not show the
fragmentation problem. It spins a lot. Often this becomes a
deadlock.
Time to change strategy: Overshoot creation of (both) inactive and
free pages each time through the loop. After inspecting existing
variables, we generate minumum 128 inactive pages (which may be
dynamically drawn down asyncronously by accesses), and then try to
convert minumum 128 inactives into free pages (different pages
get freed different ways, including via swapcluster which has been
[7 lines not shown]
To support swapencrypt, the swapcluster code has a memory allocation codepath.
Since this is runs inside the pagedaemon that is unworkable. We'd like to
encrypt the pages inplace for IO, but there are architectures not ready for
a high-mem page to be written to a dma-restricted device (work in progress).
So for now we need to bounce through dma-reachable memory buffer. A previous
attempt had 1 extra bounce buffer, but then slept on allocation inside the
pagedaemon context which is also unworkable. This version contains 32
pre-allocated swapclusters (64K each), and through a counter signals to the
pagedaemon when it should stop trying to create memory. 32 swap clusters
is comfortably more than the minimum we expect the pagedaemon frantically
generate. This crummy solution is good enough until we the dma reach problem
is solved (soon)
ok kettenis kirill (who looked into other solutions) beck
uv,zizmor: remove version number of aws-lc-sys in comment
It will stay this way for a few more versions and we will inevitably
forget to update this comment.
Add openssl/4.0 (third time is the charm)
This imports openssl-4.0.0-beta1 and merges openssl/3.6 into it. The
actual release is scheduled for April 14 at which point (or whenever
it happens) we can update to that version.
There's a lot of new things. Per the list, the most important breaking
change is that RSA keys having the top bit of the first octet set are
no longer prefixed with 00: when printed.
Less important changes include that they finally eliminated the atexit()
handler to appease Valgrind, that ASN1_STRING is now opaque and there was
a significant amount of const sprinkling.
Having ECH support is nice.
Why on earth they felt the need to add RFC 7919 FFDHE support to TLSv1.2
when the deprecation is both important and imminent is beyond me:
https://datatracker.ietf.org/doc/draft-ietf-tls-deprecate-obsolete-kex/
[5 lines not shown]
Apparently we shouldn't touch the RTC immediately after restarting the
i8254 clock either when coming out of S3 suspend. So move the code
that checks whether the RTC alarm went off and clears it all the way to
the end of acpi_cpu_resume. This fixes a lockup seen on the x220.
Figured out by mlarkin@ who write the initial diff; I just tweaked it.
ok mlarkin@, deraadt@
