refactor the matching of sk->sk_states entries in pf_find_state()
ive been looking at and trying to comprehend this code for what
feels like months of my life, and the af-to handling in particular.
it wasn't until i found the PF_AFRT handling in pf_test that it
suddenly clicked.
i figure it doesnt hurt to pull the code here apart a bit and put
some comments in place to help future travellers.
ok sashan@
Do not force the page daemon to sleep when there are outstanding paging requests.
This partially reverts the changes made in rev 1.131
Currently, this serializes the processing of pmr requests when
scheduling pageouts into only processing one pmr request. while there
appears to be a desire not to "over swap" this also I believe means
we can "under swap" if we can not schedule enough pageouts to
satisfy this request, at which point I believe we can miss wakeups
under load - especially if the pmr request can not be satisfied
and remains on the list.
I think the intent here can be achieved, but not without some
careful rework first. The current method of only waking up one
sleeper on any pmr request is very different from how this
code worked in the past and very different from the rest of the
kernel, where processes compete for freed resources to progress
the entire system forward. Serializing only one pmr requestor
to be woken up after every round of potentally sceheduling a bunch
[7 lines not shown]
Revert the change made in rev 1.126 of uvm_pdaemon.c
While the commit message was
"Do not try to release memory if all we need is balancing the page lists."
This is not what this actually did. It also removed the minumum amount of
pages that the page daemon would attempt to free, and most importantly,
it would make the page daemon potentially go back to sleep when woken
wihtout waking the sleepers that went to sleep waiting for it to free
memory and wake them up.
Since *someone* probably went to sleep when waking the page daemon, and
today we have no idea if that sleeper's request could have been satisfied
by the page daemon's free page reserve (as we have no idea how fragmented
the free pages are, or where they are in memory) this is currently dangerous.
While the "hack" of freeing up 16 pages every time it is woken is indeed
a hack, it does mean that something that is failing to allocate will force
[17 lines not shown]
update to chromaprint-1.6.0
explicitly set FFT library to use FFmpeg's (it already uses FFmpeg for
file reading); the readme claims this is used by default but actually
1.5.1 picked up fftw in preference and 1.6.0 picks up its own internal
library - not sure what's up as the CMakeFile seems to match the readme
but...
prompted by build failures due to junking of fftw3,double (which it
was picking up in preference to fftw3,float previously listed as a dep)
that naddy and I both ran into.
rewrite SOCKS4/4A/5 parsing code to use sshbuf functions instead
of manual pointer fiddling. Should make the code safer and easier
to read. feedback/ok markus@
i2c_ASN1_BIT_STRING() vs ASN1_STRING_FLAG_BITS_LEFT
A nasty quirk in the bit string handling is that the serialization
produced by i2d_ASN1_BIT_STRING() depends on whether the the magic
ASN1_STRING_FLAG_BITS_LEFT is set.
If ASN1_STRING_FLAG_BITS_LEFT is set, the number of unused bits is
carried in a->flags & 0x07 and the remainder of the bit string is
in a->data. This is terrible and undocumented but handled correctly.
If ASN1_STRING_FLAG_BITS_LEFT is not set, all trailing zero bits are
(intended to be) chopped off with all sorts of hilarious side effects.
I broke this quite thoroughly when I incorrectly ported an overflow
check from BoringSSL in:
https://github.com/openbsd/src/commit/f81cc285d2aed8b36615119a306533696f3eb66c
The result is that we currently return ret = a->length + 1 for both NULL
and non-NULL pp. The calls to asn1_ex_i2c() in asn1_i2d_ex_primitive()
thus report consistent lengths back, making it succeed.
[21 lines not shown]
