Fixes the short noise when playback of unsigned samples stops. We've
to call enc_sil_do() instead of padding with 0 (0 doesn't represent
silence for unsigned encodings).
Mostly from gkoehler@
"The Mach kernel has a builtin kernel debugger (kdb) based on adb"
Mach: A New Kernel Foundation For UNIX Development, USENIX Summer 1986
"The new kernel debugger has most of the features of the old kdb, but
with a more rational (gdb-like) syntax."
Mach 3.0 (mk83), ddb.man
Mark W. Eichin explains how ddb came to be in 386BSD 0.1 in
a June 1992 post to comp.unix.bsd
https://groups.google.com/g/comp.unix.bsd/c/LY3hbHwjdG0/m/ca1hS0Hp5HcJ
comp.unix.bsd and was part of the 0.2.2 patchkit. The first two commits
to NetBSD were 386BSD 0.1 and the 0.2.2 patches.
uk.c did not appear till NetBSD 1.0.
ok miod@
I admit this is unusually long for a manual page. But that's not my fault
as a documentation author. An example in a manual page ought to be minimal
to show what needs to be demonstrated, and this example is minimal in that
sense. Making it shorter without loosing important aspects does not seem
possible.
When an API is poorly designed, one of the consequences is that that
documentation becomes harder to understand and often longer - in this
case to the point of becoming outright intimidating. If people dislike
that, they should design better APIs in the first place rather than
blasting the poor manual page for being too long or too complicated.
OK tb@
This was the list where PCBs were temporary linked to avoid sleep with
`inpt_mtx' mutex(9) held. in_pcbnotifyall() and in6_pcbnotify are the
last list users, so switch them to in_pcb_iterator() too, moreover they
already do in_pcb_is_iterator() check.
Note, in_pcb_iterator() does necessary reference couter handling,
unlocked `inp' dereference is safe.
ok bluhm
virtio 1.x requires that all queue setup, including the queue interrupt
vector, is done before setting the queue_enable register to 1. This
conflicts with how we do things right now:
* We implicitly make queue setup in virtio_alloc_vq(), which is called
from the child driver attach functions. This also sets queue_enable=1.
* Later, we allocate the interrupts and set the queue interrupt vectors
in the second half of the virtio transport attach functions.
This is a violation of a MUST from the standard and causes problems with
some hypervisors, in particular those that have no virtio 0.9 support,
which has no such ordering requirements.
To fix this:
* Move the interrupt allocation to a new virtio_attach_finish() function.
This does all queue setup, including the interrupt vectors.
* Don't call virtio_setup_queue() in virtio_alloc_vq() anymore.
* We can also move the setting of the DRIVER_OK flag into this function.
virtio_attach_finish() must be called before using any virtqueue or
writing any virtio config register.
While there,
* also streamline the attach error handling in all drivers.
* skip initially setting sc_config_change to NULL, the softc is
initialized to 0.
ok jan@
tested by bluhm@
with an unsupported control command, return -1 rather than 0
to the caller to indicate the error because in general, these
control hooks ought to return -1 for unsupported control commands
and 0 for other errors, for example other invalid arguments.
Not a big deal because this change does not change when operations
succeed or fail, and because callers are unlikely to pass unsupported
control commands in the first place. The only functional change is that
if a calling program inspects the ERR(3) stack after this failure,
it will now find the correct error code rather than nothing.
Even that wasn't a huge problem because for most EVP_CIPHER control
failures, getting no reason for the error is the usual situation.
Then again, giving the reason when easily possible may occasionally
be useful. OpenSSL also returns -1 in this case, so it also helps
compatibility a tiny bit.
Found while auditing the return values of all the EVP_CIPHER
control hooks in our tree. This was the only fishy one i found.
OK tb@
In tcp_mss_adv() max(9) was used to guarantee that mss it not too
small. Unfortunately max() uses u_int and mss could get negative
in some error conditions.
Rearrange the code to directly return in case of errors. Also read
tcp_mssdflt only once to head towards atomic integer sysctl.
OK mvs@
. uvm_pagewait(): do not require an exclusive lock to release it & sleep
. uvm_page{de,}activate(): lists updates are serialized by the `pageqlock' mutex
More assertions could be relaxed but only those 3 are necessary for running
the lower fault handler in parrallel.
ok miod@
With this change, any line is logged using a single function call
(instead of one function call per logged token). This makes the
sources easier to read and reduces the binary size. Debug strings that
would be too difficult to produce with snprintf(3) are simplified.
ok tb, dlg
algorithm-independent EVP_EncryptInit(3) manual as another step
in making the latter leaner and more palatable.
As a side benefit, the new EVP_aes_128_ccm(3) manual page may provide
a better fighting chance to programmers who see themselves forced to
support CCM for whatever reason. It documents the mandatory, but so
far undocumented EVP_CTRL_CCM_GET_TAG control command and makes the
description of the three EVP_CTRL_CCM_SET_* control commands and the
numerous related quirks more precise.
Make proper use of CBB and CBS. If a CBS ever owns data, you're holding
it wrong. Ditch gross macros, sscanf, and globals. The use of fgets is
annoying here, so replace it with getline, which be provided by portable
if needed.
Most importantly, make the tests actually signal failure rather than
only printing an error. Fix the state machines in a few of them. Some
tests didn't parse the .txt file at all. Others mostly did but didn't
actually test what they were supposed to be testing. Such failures
were hidden by the way the tests were written.
This basically needed a complete revamp. It still isn't pretty and much
of it could be deduplicated, but I only have so much time alotted on this
blue planet.
Only unlock soreceive() path, somove() path still locked exclusively. Also
exclusive socket lock will be taken in the soreceive() path each time
before pru_rcvd() call.
Note, both socket and `sb_mtx' locks are held while SS_CANTRCVMORE
modified, so socket lock is enough to check it in the protocol input
path.
ok bluhm
This is the statistics implemented with per-CPU counters and the
`carp_opts' array of atomically accessed integers.
Replace the `carp_opts' array with individual `carpctl_*' variables
and use sysctl_bounded_arr() instead of sysctl_int(). Keep current
`carpctl_*' variables bounds as is, they would be adjusted with
separate diff.
ok bluhm
This should not have any functional difference on existing setups, as
so far any time this function would have been used, it would have led
to a kernel panic as it's been a NULL pointer.
This fixes bootup on the MNT Reform2 with the RK3588 module.
ok kettenis@
In some cases, following a fallback from RRDP to RSYNC, files are
moved to the wrong place. With this change, only rsync repositories
are considered when looking up where to move DIR_TEMP files.
repo.c requires more study, this fix might be a bandaid for a problem
not fully understood.
"put it in" claudio@ OK tb@
The RPKI ecosystem suffers from a partially unmitigated risk related to
long-lived Trust Anchor certificate issuances.
Issues could arise when a on-path attackers (or, operational errors such
as restoring a super old backup of a webserver) bring back into
circulation old (but still valid) TA certificate. Older certificates
remain valid for the duration of their validity period, because TA
certificates - being top of the chain - cannot be revoked.
Real world examples of old potential replayable certificates that today
still would pass validation are here:
https://mailarchive.ietf.org/arch/msg/sidrops/NxzvSFH0sPXEmyfOS99cLApFKqM/
The trouble with these replayable TA certificates is that when an
on-path entity ends up presenting such an outdated-but-still-valid
certificate to the RP, accepting such a cert will damage the RP's local
validated cache. Parts of the validated output will disappear, in an
unpredictably manner.
Periodic reissuance of TA certs is important because TA certificates are
not entirely static, which of course is why replay might even be an issue
in the first place!. There are 3 'dynamic' fields in TA certificates:
- the validity period (notBefore, notAfter)
- the SubjectInfoAccess (where can the RP find the first repository?)
- the extensions for IP addresses & AS identifiers (RFC 3779 INRs)
(the RFC 3779 extensions are of critical importance to the
RPKI's chain validation algorithm)
RIRs will want RPs to validate using the 'latest' issuance of the TA
certificate, because a TA cert from 10 years ago obviously will be 10
years behind on operational decisions, potential SIA migrations,
resource transfers, new IANA assignments, or any other updates to the
RIR's current holdings.
How to repair this situation?
The plan to overcome this risk has three steps:
step 1) RPs to prefer shorter-lived Trust Anchor certificates over
longer-lived ones. (rpki-client already implemented this)
https://datatracker.ietf.org/doc/html/draft-ietf-sidrops-rpki-ta-tiebreaker
step 2) RPs ship with scheduled future refusal of ultra long-lived Trust
Anchor certificates (that's the below diff).
step 3) Consequently, RIRs have to reissue shorter-lived TA certificates
to avoid being rejected by RPs.
The end result is that after anno 2026 / 2027, if 100 year or 10 year
certs somehow be brought back into circulation, RPs will simply refuse
such long-lived certs, despite them technically being 'valid'.
Why this works:
The ta-tiebreaker mechanism provides an incentive for TA operators to
reissue with reasonable (1 or 2 year) validity periods, as those certs
will be preferred. In turn, RPs scheduling refusal of long-lived certs
at a predetermined future point in time, relieves TA operators from
worrying about previously issued certs with ultra long lifetimes. It is
a win win for everyone in the ecosystem.
Scheduling details:
- February 2nd 2026 for phase 1, because 02-02-2026 is an unambiguous
date both in the US and elsewhere.
- March 3rd 2027 for phase 2, because 03-03-2027 also is unambiguous and
visually is very distinct from the phase 1 date.
The hope is that with this schedule global coordination less will be less
error-prone, and everyone should get adequate preparation time.
Discussed with various RIRs
with & OK tb@
Use local-as in community and large-community stanzas since that will
be expanded at runtime. For communities that only work with 2byte ASN
the filter will never match (or nothing will be set / deleted) since
a 4byte ASN can never match.
We want an bgpd.conf example ruleset that is sensible, works and is a
good starting point for beginners. In other words we should not add
traps to the config.
OK deraadt@ job@
