EVP_SealInit.3: fix RETURN VALUES section
While normal calls return 0 for error and npubk for success, there is a
case where it returns the usual 1/0 thing. Make that explicit.
Prompted by a report by Niels Dossche
ok jsing kenjiro
EVP_{Open,Seal}Init(): remove redundant EVP_CIPHER_CTX_reset() calls
The subsequent EVP_{Decrypt,Encrypt}Init_ex() calls already do that.
pointed out by jsing
EVP_SealInit(): minor cleanup.
Explicitly compare pointers against NULL, turn the function into single
exit, add hint at why npubk <= 0 or pubk == NULL are a success path:
The documentation briefly explains that EVP_OpenInit() and EVP_SealInit()
is able to initialize the EVP_CIPHER_CTX in two steps exactly like the
EVP_CipherInit_ex() API they wrap: the first call with non-NULL cipher
(aka type) only sets the cipher on the ctx, then it returns to allow
callers to customize the EVP_CIPHER_CTX, and a second call with
cipher == NULL skips the initialization and finishes the ctx setup
by setting key and iv.
Prompted by a report by Niels Dossche.
ok jsing kenjiro
EVP_SealInit: do not return -1 on error
It is documented that EVP_SealInit() returns 0 on error. So -1 is wrong.
Reported by Niels Dossche
ok jsing kenjiro
EVP_OpenInit(): minor cleanup
Explicitly compare pointers against NULL, turn the function into single
exit and explain why priv == NULL is a success (hint: muppet API).
Prompted by a report by Niels Dossche.
ok jsing kenjiro
Update ni_rssi only with good rxi_rssi in ieee80211_inputm()
Some drivers don't report rssi here. This causes good value from other
places replaced with 0, leading to annoying UI oscillation.
OK stsp@ phessler@
uvm_wait() was waking the pagedaemon then going to sleep on &uvmexp.free,
but made no indicator in a variable that the pagedaemon should do anything.
So, if the pagedaemon didn't see sleepin pmemrange allocations at the same
time, it would go back to sleep. This resulted in uvm_wait() wakeups
being substantially deferred.
ok beck claudio
rpki-client: prepare p -> cert replacement in cert_buffer() and cert_read()
This wraps a few lines and pulls assignments out of if statements to avoid
overlong lines. The replacement will then become purely mechanical.
ok claudio
Change the high-level FUSE implementation to use the low-level API.
Currently, both APIs communicate with the kernel independently.
Even though this is a libfuse change, I've included a minor kernel
patch to remove a now unecessary check for a ENOBUFS errno. This
is not part of the FUSE protocol and is no longer needed.
I've also deleted a regression test, which checks that libfuse
functions can handle NULL as an argument. It's better that these
function segfault rather than attempt to gracefully handle bad
arguments.
There is no change to the libfuse API so shlib_version does not need a
bump.
OK claudio@
Back out the pagedaemon "oom" reserve and sleeping point
As discussed extensively. This was originally a backout
worked through by me, and then fixed and tested by deraadt@
We do not want the page daemon to sleep for other memory
resources while it should be waking sleepers and recovering
memory.
We may consider adding somthing like a reserve at a later time,
or ensure that the resources needed for swapping are always
present and never competed for, but we are backing this out
for the moment to deal with further pagedaemon bugs that this
gets in the way of solving
ok deraadt@
In uvm_pdaemon.c 1.121, 1.122, and 1.123, two things happened:
1. The shortage target inside uvmpd_scan() / uvmpd_scan_inactive() which
used to be computed using the realtime uvmexp.free value, was replaced with a
(historic prediction) using the pre-existing pagedaemon "shortage" variable.
This means the scanner will continue work even if the system recovers
memory asyncronously and has resolved the scarcity which caused the pagedaemon
to be summoned. That's a bad idea. The code should revert to observing
realtime system conditions. We don't have a diff for that yet, but the
other concern is immediate:
2. The pre-existing calculation of the "shortage" variable was changed
significally, without verifying correct behaviour.
size += shortage;
...
shortage -= bufbackoff(&constraint, size * 2);
since bufbackoff() returns how much it did, and generally succeeds at
satisfying the full request size * 2, that is effectively "shortage =
-shortage". The scan function changes still expect a positive target
[5 lines not shown]
The pagedaemon inspects the top-most sleeping pmemrange allocation for
for size and constraint, and passes this information to the inactive
scanner. The idea is that an extremely high-size and
strict-constraint allocation that fails repeatedly would percolate to
the top of the list. To ensure the scanner can inspect this
allocation's constraint via the pointer, it gets locked. Then we
release tons of memory from the buffer cache, and run the scanner to
recover free memory. At the same time, other running operations free
and allocate memory and wakeup all the sleeping pmemrange allocations,
but no, not this one, because it is locked so that the pointer won't
become invalid. When the scan is done, we may once again have meager
memory resources because all the good stuff was allocated by
asyncronous allocators, potentially creating substantial fragmentation
not compatible with the constraint. Now, the sleeping request gets
unlocked and woken to re-check it's requirements and guess what, the
constraint fails it goes back to sleep, and we need to go around
again... In practice this is a hard uvm deadlock.
Instead, copy the constraint from the request, do not lock the
allocation request and ignore the pointer.
[4 lines not shown]
ls(1): use correct buffer size for ngroup.
In numeric long format, ngroup is formatted using sizeof nuser. That's a
copy-paste bug. It's harmless only because the arrays are the same size
today; it would become a real truncation/overflow risk if they ever
diverge.
From Michal Mazurek (akfaew@), thanks!
OK kn@, tb@
rpki-client: explain why we do what we do in ta_check_pubkey()
The base64-encoded SPKI blob in the TAL should really be matched against
the corresponding part of the cert's DER. Unfortunately, libcrypto only
stores internal representations in the X509's cert_info field, so what it
hands back via the X509_* and X509_PUBKEY_* API is at best re-encoded and
therefore unsuitable for this purpose. Document this so when I will have
forgotten this the day after tomorrow, I still have a chance of not wasting
as much time for a third or fourth time next time I revisit this.
ok claudio
rpki-client: rename ta_parse() to ta_validate() and document it
ta_parse() only parses the TAL's SPKI, so it is misnamed. What it really
does is it compares the TA's SPKI to the TAL's SPKI and checks that it is
a curently valid, self-signed cert.
ok claudio
