Upstream llvm commit e314622f204a makes it clear that ARM does not consider
ARMv7 to be a strict alignment architecture. So stop setting the SCTLR.A
bit. This means we don't have to change the default settings for the
upcoming LLVM 19 import.
ok jca@, patrick@
Do not unlock the socket in soabort().
One difference between UNIX and internet sockets is that UNIX sockets
unlock in soabort() while TCP does not do that. in_pcbdetach()
keeps the lock, change uipc_abort() to behave similar. This also
gives symetric lock and unlock in the caller. Refcount is needed
to call unlock on an aborted socket.
The queue 0 in soclose() is only used by UNIX sockets, so remove
the "if" persocket. The "kassert" persocket in soisconnected() is
not needed.
OK mvs@
Update to 2025agtz from https://github.com/JodaOrg/global-tz
o Paraguay adopts permanent -03 starting spring 2024.
o Improve pre-1991 data for the Philippines.
o Etc/Unknown is now reserved.
In "-T html" output, translate ".%R RFC <nuber>"
to a hyperlink to rfc-editor.org.
New feature first requested by tb@ in March 2023, now reminded by sthen@.
Patch tested by and OK tb@.
On i386, llvm >= 17 warns with -Wsync-alignment when using a sync builtin
with a 64-bit value that isn't 64-bit aligned.
The Intel SDM volume 3, strongly suggests to do this for performance
reasons. My reading is this isn't required to be atomic.
Make atomic64_t 64-bit aligned and change arguments to avoid the warning.
And make a local change to the inteldrm code to set alignment in a case
where we use a sync builtin when linux doesn't (cmpxchg64()).
discussed with tb@ robert@ kettenis@, ok tb@
Remove -C option from "apps"
As far as I can tell, this way of generating "C code" was only used to add
stuff to pretty regress and even prettier speed "app" and otherwise it just
served to make the library maintainer's lives even more miserable.
ok jsing
Improve bit counter handling in MD5.
Like most hashes, MD5 needs to keep count of the number of bits in the
message being processed. However, rather than using a 64 bit counter this
is implemented using two 32 bit values (which is exposed in the public
API). Even with this hurdle, we can still use 64 bit math and let the
compiler figure out how to best handle the situation (hopefully avoiding
compiler warnings on 16 bit platforms in the process!). On amd64 this code
now requires two instructions, instead of the previous five.
While here remove a comment that is excessively visible and no longer
completely accurate (and if you're going to redefine types like MD5_WORD
you kinda need to know what you're doing).
ok tb@ (who's going to miss the dear diary style comments)
ecparam: remove GF2m remnant
This removes the last in-tree dependency on EC_METHOD_get_field_type()
and EC_GROUP_method_of() and removes some dead code which would generate
code that wouldn't compile if it was reachable.
ok jsing
The pmap_enter(9) function may fail even if we have enough free physical
memory. This happens if we can't allocate KVA to map that memory. This
is especially likely to happen with the arm64 pmap (and the riscv64 pmap
that is derived from it) since lock contention on the kernel map will
make us fail to allocate the required KVA. But this may happen on other
architectures as well, especially those that don't define
__HAVE_PMAP_DIRECT.
Fix this issue by introducing a new pmap_populate() interface that may be
called to populate the page tables such that a subsequent pmap_enter(9)
call that uses the same virtual address will succeed. Use this in the
uvm fault handler after a failed pmap_enter(9) call before we retry the
fault.
tested by phessler@, mglocker@
ok mpi@
Simplify tls1_check_ec_key()
It doesn't need to have optional arguments anymore, so we can pass
in values and don't need NULL checks and dereferencing.
ok jsing
Remove two pointless NULL checks
The only caller ensures that the EC_KEY is not NULL and passes the address
of comp_id on its stack, so neither will be NULL.
Drop field determination dance
If we get here, we're in a server and have managed to load the cert.
The public key is therefore a point on a built-in curve, and we know
the group is defined over some prime field. Now it is just a matter of
figuring out whether we support the group in libssl.
ok jsing
