| Age | Commit message (Collapse) | Author |
|---|
|
|
|
even got there in the first place. I've been wondering why I have
seen a bit of mbuf corruption here and there since I put the bwfm(4)
M.2 PCIe card into my arm64 machine. Well, duh.
|
|
|
|
ok kettenis
|
|
lowercase for "usage", and add -e, which was missing;
ok kettenis
|
|
counts.
Tweak man page accordingly.
Requested by deraadt@ and kettenis@.
|
|
Thankfully clang elided the code in an almost harmless way (at least on
amd64 GENERIC.MP). Spotted by chance when building kernels
with -Wno-error=uninitialized.
ok dlg@ sashan@ bluhm@
|
|
implementation of delay(9).
ok deraadt@
|
|
|
|
implementation of delay(9).
ok deraadt@
|
|
|
|
|
|
recorded as a new dependency. Even though ForwardDependencies normally
takes care of that, with tags, this is not enough.
(this happens only because libexecinfo was a "tight" dependency, thus
resulting in a large UpdateSet, and when some of the objects did require
tags in the new package, and when the order of things meant that BaseSystem
was considered a bit early).
Since there's no handle at this point, a dirty but efficient test vs
BaseSystem will do (which is not a valid normal package name anyhow)
tested to fix the obnoxious warning landry@ saw, which I was able to
reproduce on a box...
|
|
discussion with espie kettenis jsg
|
|
|
|
While here fix a misplaced '(' to make this nitems the same as
all its friends.
Pointed out by okan@
|
|
CVS commit mPRyhYmlmonmI11J which added support for Rx aggregation offload
contains a node leak in the rx_reorder() function. Node leaks will cause
the driver to get stuck when roaming between access points.
Add missing calls to ieee80211_release_node() to fix this.
ok mpi@
|
|
|
|
The original implementation of the virtio network device assumed a
driver would only provide a 2-descriptor chain for receiving packets.
The virtio spec allows for variable length chains and drivers, in
practice, construct them when they use a sufficiently large MTU.
This change lets the device use variable length chains provided by
the driver, thus allowing for drivers to set an MTU up to the
underlying host-side tap(4)'s limit of TUNMRU (16384).
Size limitations are now enforced on both tx and rx-side dropping
anything violating the underlying tap(4) min and max limits.
More work is needed to increase the read(2) buffer in use by vmd
to prevent packet truncation.
OK mlarkin@
|
|
special boot partitions needed by some hardware. Make it
difficult to add, delete or modify those partitions with 'fdisk
-e'.
Trim back and correct syntax in usage(). Whack at man page
verbiage.
Suggestions and ok deraadt@
|
|
siglongjmp(3) to decide wehther we need to restore the signal mask.
ok deraadt@, drahn@
|
|
OK sthen@
|
|
OK sthen@
|
|
protocol (-x) default to AES. The old defaults are just not sane anymore.
OK sthen@
|
|
The old defaults are just not sane anymore.
OK sthen@
|
|
things:
- Only allow SNMPv3 by default. SNMPv1 and SNMPv2c can be enabled by
setting the new snmpv* flags on the "liston on" statements.
- Remove the default community names. They're not secure to use.
- Change the default seclevel to enc.
Initial idea, help from and OK sthen@
|
|
would have been written this way because of the old args limit, but the
extensions to -b expose a nasty line wrap when written that way;
|
|
|
|
Extend the syntax to allow the boot partition offset and boot
partition type to be specified if needed.
ok deraadt@ kettenis@
|
|
local variables to just before they are needed.
ok kettenis
|
|
opening the tty corresponding to a non-console device will hang the
machine.
ok deraadt@
|
|
cpumatch will also ignore them, but skipping them here avoids increment
of hw.cpusfound
ok jsg
|
|
|
|
|
|
As found by djm by fuzzing ssh, scan_scaled can overflow for negative
numbers when rescaling is needed. This is because the rescaled fractional
part is added without taking the sign into account.
ok ian jca
|
|
on i386. This is a backout of revision 1.152.
Kernel crash with messages printed concurrently from multiple CPUs
occasionally seen during ports build:
"WARNING: SPL NOT LOWERED ON TRAP EXIT"
and these panics
ddb{1}> sh panic
cpu1: uvm_fault(0xd470a0a0, 0xcf9b7000, 0, 1) -> e
cpu3: kernel diagnostic assertion "!_kernel_lock_held()" failed: file "/usr/src/sys/uvm/uvm_map.c", line 2707
|
|
file for the installer.
|
|
using inet autoconf, like we do with "dhcp" and "inet6 autoconf".
OK kn
|
|
|
|
|
|
For the thunderbolt controller, while a public datasheet with product
ids and marketing names can't be found we know these ids are for the two
channel version of the thunderbolt 3 controller codenamed titan ridge
from public patches by Intel employees. There are two channels per port
and the only single port titan ridge described on ark.intel.com is the
JHL7340. The ids included with lspci refer to these devices as JHL7540
but that is a four channel / two port controller.
initial patch from fkr
|
|
ok drahn@
|
|
turns out same as a diff drahn didn't commit
ok kettenis
|
|
|
|
Due to a type bug that has been present in DTLS since the code was first
committed in 2005, dtls1_get_bitmap() fails to handle next epoch correctly
when the epoch is currently 0xffff (and wraps to zero).
For various reasons unknown, the epoch field in the SSL3_RECORD_INTERNAL
(formerly SSL3_RECORD) was added as unsigned long (even though the value
is an unsigned 16 bit value on the wire, hence cannot exceed 0xffff),
however was added to other code as unsigned short.
Due to integer promotion, the r_epoch value is incremented by one to
become 0x10000, before being cast to an unsigned long and compared to
the value pulled from the DTLS record header (which is zero). Strangely
0x10000 != 0, meaning that we drop the DTLS record, instead of queueing
it for the next epoch.
Fix this issue by using more appropriate types and pulling up the
calculation of the next epoch value for improved readability.
ok inoguchi@ tb@
|
|
In particular, test handling of 0xfffe and 0xffff - the latter results in
wrapping to zero for the next epoch. One of these tests triggers a known
bug in libssl, which will be fixed following this commit.
|
|
This allows for regress to test edge cases for epoch handling.
ok tb@
|
|
Currently these only get correctly initialised when
dtls1_process_buffered_records() is called - while this works it is more
accidental than intentional.
ok tb@
|
|
These tests exercise the various queues and delayed processing that exists
in the DTLS code.
|
|
Two tests currently fail (and are disabled) due to a flaw in the DTLSv1.0
specification - this flaw was addressed in DTLSv1.2, however our DTLS
server code still needs to support the fix.
Quoting RFC 6347 section 4.2.4:
"This requirement applies to DTLS 1.0 as well, and though not explicit in
[DTLS1], it was always required for the state machine to function
correctly."
In otherwords, both the original DTLS implementation and the DTLSv1.0
specification have a broken state machine, resulting in possible dead lock.
|
