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]
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]
asn1basic: add example showing current bogus encoding
There is a bug in i2c_ASN1_BIT_STRING() resulting in nonsense encoding of
some BIT STRINGs with trailing zeroes if ASN1_STRING_FLAG_BITS_LEFT is not
set (a rare corner case). This test currently passes when it shouldn't.
i2c_ASN1_BIT_STRING(): zap nonsensical comment
The /* should not happen */ happens if a->data is all zeroes (where
there used to be an OOB access a few years back), which is a legitimate
BIT STRING, so this is just nonsense.
ok jsing kenjiro
Backout: Protect IGMP and MLD6 fast timer with rwlock.
syzkaller found recursive calls with if_maddrlock. in_addmulti()
takes the lock, calls igmp_joingroup(), igmp_sendpkt(), ip_output().
There in_hasmulti() takes the lock again. Analog for mld6_sendpkt().
Reported-by: syzbot+9ef22ca02dffcf088cf6 at syzkaller.appspotmail.com
Reported-by: syzbot+de6bcf8e746b8a631885 at syzkaller.appspotmail.com
Reported-by: syzbot+c366cf5e7c87ead7f4f7 at syzkaller.appspotmail.com
Use an iterator in uvmpd_scan_active() to prevent a list corruption.
Releasing the pageqlock without iterator wasn't safe.
Suggested some time ago by claudio@, reported by and ok bluhm@
While it's clear from this man page that it's possible to list all
encoding with the -l flag, there is no mention of the hidden .metaesc
option. Also add reference to wskbd and wsconsctl, which can also be
used to change the keyboard.encoding.
ok op@
Protect IGMP and MLD6 fast timer with rwlock.
Multicast interface addresses for IPv4 and IPv6 get their own per
interface lock. Protect the TAILQ if_maddrlist with rwlock
if_maddrlock. Also struct in_multi and in6_multi use this lock for
their state and timer. Sleeps in malloc and IP output are possible.
Run IGMP and MLD6 fast timeout with shared instead of exclusive net
lock.
Reported-by: syzbot+3dcb7e0d63b11f6f341c at syzkaller.appspotmail.com
OK mvs@
fix scan-build dead stores findings
- httpd.c:533 – q assigned but immediately overwritten in the loop
- server.c:891 – inrd/inwr assigned, then reassigned, never actually needed
- server_fcgi.c:678,690 – kv result unused
OK stsp@
Unexport ASN1_LONG_UNDEF
This is another one of these weird magic values that nothing outside
of libcrypto uses. Fix a confusing comment in long_i2c() while there.
The skipping behavior is used in particular for omitting the optional
length value in the non-standard OpenSSL-specific DHparam() ASN.1
encoding.
ok jsing kenjiro
These files contain both MP and non-MP versions of the shoot functions
seperated by #else. The MP versions contain the code from the non-MP
versions verbatim. This adds and #ifdef MULTIPROCESSOR into the MP
versions makes minor adjustments. This style will avoid future errors.
I already almost introduced one..
