bc8b8e10 zec Oct. 9, 2021, 11:47 a.m.
The number of chunks can still be tracked via vmstat -z|fgrep dxr.

MFC after:	3 days
1549575f zec Oct. 9, 2021, 11:22 a.m.
Tracking the number of unused holes in the trie and the range table
was a bad metric based on which full trie and / or range rebuilds
were triggered, which would happen in vain by far too frequently,
particularly with live BGP feeds.

Instead, track the total unused space inside the trie and range table
structures, and trigger rebuilds if the percentage of unused space
exceeds a sysctl-tunable threshold.

MFC after:	3 days
PR:		257965
032448cd emaste Oct. 9, 2021, 3:15 a.m.
Reviewed by:	kevans
Fixes:		5551c573554e ("Rework PRIVATELIB")
Sponsored by:	The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D32384
172fa4aa emaste Oct. 9, 2021, 1:29 a.m.
From openssh-portable commits f3cbe43e28fe and bf944e3794ef.
1c64959b dteske Oct. 8, 2021, 11:26 p.m.
My current style is to copy C for "/* NOTREACHED */" instead of spelling
out "Not reached". Make this one nominal change in this one file and the
others later.

While here, word-smith "Preload" into "Pre-load" as I believe that to
be more grammatically correct in this instance.

Also while here, fix a comment capitalization error.

Lastly, bump copyright for above changes.
15575aca imp Oct. 8, 2021, 9:44 p.m.
Separate out the arch/cpu options for armv6 from the armv7 ones. This is
less confusing.

Sponsored by:		Netflix
17f790f4 mhorne Oct. 8, 2021, 5:16 p.m.
These platforms don't manage resources for DMA request lines or I/O
ports, this is specific to x86. Remove the references from the comments.

Reviewed by:	imp, jhb
MFC after:	3 days
Sponsored by:	The FreeBSD Foundation
Differential Revision:	https://reviews.freebsd.org/D32358
bf8f6ffc pstef Oct. 8, 2021, 3:07 p.m.
PR:		224837
Reported by:	Aleksander Derevianko
1c680e62 kp Oct. 8, 2021, 12:46 p.m.
We overwrite these fields again in pf_kanchor_setup() anyway.

MFC after:	2 weeks
Sponsored by:	Rubicon Communications, LLC ("Netgate")
0525ece3 bz Oct. 8, 2021, 11:21 a.m.
In 526370fb85db4b659cff4625eb2f379acaa4a1a8 "net80211: proper ssid
length check in setmlme_assoc_adhoc()" we are checking the
sizeof on an array function parameter which leads to a warning that
it will resturn the size of the type of the array rather than the
array size itself.  Use the defined length used both in the ioctl
and the sizing of the array function parameter instead.

Reported by:	CI
MFC after:	3 days
X-MFC with:	526370fb85db4b659cff4625eb2f379acaa4a1a8
76f3b8cb bz Oct. 8, 2021, 10:28 a.m.
Change the probe return value from BUS_PROBE_DEFAULT to BUS_PROBE_GENERIC
given this is the "generic" attach method.  This allows individual
drivers using XHCI generic but needing their own intialisation to
gain priority for attaching over the generic implementation.

Reviewed by:	hselasky
Differential Revision: https://reviews.freebsd.org/D32257
09dd08f1 bz Oct. 8, 2021, 10:26 a.m.
In ieee80211_ies_expand() we are looping over Elements
(also known as Information Elements or IEs).
The comment suggests that we assume well-formedness of
the IEs themselves.
Checking the buffer length being least 2 (1 byte Element ID and
1 byte Length fields) rather than just 1 before accessing ie[1]
is still good practise and can prevent and out-of-bounds read in
case the input is not behaving according to the comment.

Reported by:	(coypu sdf.org)
admbugs:	857
MFC after:	3 days
Reviewed by:	adrian, markj
Differential Revision: https://reviews.freebsd.org/D32340
526370fb bz Oct. 8, 2021, 10:23 a.m.
A user supplied SSID length is used without proper checks in
setmlme_assoc_adhoc() which can lead to copies beyond the end
of the user supplied buffer.
The ssid is a fixed size array for the ioctl and the argument
to setmlme_assoc_adhoc().
In addition to an ssid_len check of 0 also error in case the
ssid_len is larger than the size of the ssid array to prevent

PR:		254737
Reported by:	Tommaso (cutesmilee.research protonmail.com)
MFC after:	3 days
Reviewed by:	emaste, adrian
Differential Revision: https://reviews.freebsd.org/D32341
bd19202c tuexen Oct. 8, 2021, 9:33 a.m.
MFC after:	1 week
174aad04 kib Oct. 8, 2021, 9:24 a.m.
Wakeup in vm_waitpfault() does not mean that the thread would get the
page on the next vm_page_alloc() call, other thread might steal the free
page we were waiting for. On the other hand, this wakeup might come much
earlier than just vm_pfault_oom_wait seconds, if the rate of the page
reclamation is high enough.

If wakeups come fast and we loose the allocation race enough times, OOM
could be undeservably triggered much earlier than vm_pfault_oom_attempts
x vm_pfault_oom_wait seconds.  Fix it by not counting the number of sleeps,
but measuring the time to th first allocation failure, and triggering OOM
when it was older than oom_attempts x oom_wait seconds.

Reviewed by:	markj
Tested by:	pho
Sponsored by:	The FreeBSD Foundation
MFC after:	2 weeks
Differential revision:	https://reviews.freebsd.org/D32287