Age | Commit message (Collapse) | Author |
|
Matches what iwm(4) has been doing for a long time to ensure that
a good initial Tx rate will be chosen.
Tested by Tracey Emery on AR9281.
|
|
Some peers will eagerly try to negotiate block ack (asking us to reserve
buffer space) before they are done authenticating themselves. No thanks.
Just let them try again later.
ok mpi@
|
|
as well as pulling frames off the Rx block ack reordering queue, when
an incoming frame above the current seqnum window forces us to slide
the window forward, potentially losing frames within the old window.
Leaving the seqnum window out of sync with the queue would cause needlessly
long stalls in traffic until the window moved again for some other reason.
Problem observed on lossy wifi whenever netstat -W indicated an increasing
"input block ack window slides" counter. With this fix, stalled frames can
be observed only for a relatively short amount of time whenever one or more
frames in the current window are lost.
ok mpi@
|
|
Even with the latest microcode this is not set on all CPUs with TSX, but
is set on CPUs which don't need MDS mitigations.
MDS mitigations also mitigate TSX Asynchronous Abort (TAA) but aren't
done if the CPU claims to not be affected by MDS (MDS_NO).
According to "Deep Dive: Intel Transactional Synchronization Extensions
(Intel TSX) Asynchronous Abort" CPUs requiring additional mitigations
for this are:
06-8e-0c Whiskey Lake (ULT refresh)
06-55-0{6,7} 2nd Gen Xeon Scalable Processors based on Cascade Lake
06-9e-0d Coffee Lake R
Currently TSX is disabled unconditionally when possible even if TAA_NO
is set.
We don't currently do MDS mitigations on i386. Attempt to disable TSX
regardless to match amd64.
|
|
Even with the latest microcode this is not set on all CPUs with TSX, but
is set on CPUs which don't need MDS mitigations.
MDS mitigations also mitigate TSX Asynchronous Abort (TAA) but aren't
done if the CPU claims to not be affected by MDS (MDS_NO).
According to "Deep Dive: Intel Transactional Synchronization Extensions
(Intel TSX) Asynchronous Abort" CPUs requiring additional mitigations
for this are:
06-8e-0c Whiskey Lake (ULT refresh)
06-55-0{6,7} 2nd Gen Xeon Scalable Processors based on Cascade Lake
06-9e-0d Coffee Lake R
Currently TSX is disabled unconditionally when possible even if TAA_NO
is set.
ok bluhm@ guenther@ deraadt@
tested by bluhm@ on i5-8365U (06-8e-0c).
|
|
|
|
pipe_lock. This add a potential sleeping point in the kqueue filter
routines which should be fine by now thanks to changes made to the
kqueue subsystem by visa.
ok visa@
|
|
the kernel.
ok patrick@
|
|
the kernel.
ok mlarkin@, visa@
|
|
the kernel.
ok mlarkin@, visa@
|
|
ok visa@
|
|
Some drivers have returned ENXIO (6) if the device is not available
which incorrectly translates into POLLPRI|POLLOUT (2|4) in userland.
Change it to POLLERR for now, but it might as well be POLLHUP.
OK mpi@
|
|
There is an existing allocsize variable tracking size of allocations,
turns out we can pass it to free in the error path.
OK florian@, mpi@
|
|
ok deraadt@, dlg@
|
|
OK guenther@, kettenis@, mpi@
|
|
against codes in the known-codes table, like Linux does it.
Mark the known-codes table static so it won't ever collide with
symbols declared elsewhere in the kernel.
Also add some more cause codes found in iwlwifi. I still keep hitting
firmware SYSASSERT codes that aren't declared in this table, though :(
These changes only affect IWM_DEBUG builds.
|
|
Firmware-based Tx retries were disabled when it was found that MiRA
makes better choices while probing with a constant Tx retry rate.
Before that change, high Tx rates looked better than they actually
were. The change resulted in less retries and thus higher throughput
because a lower, but actually working, initial Tx rate eventually
became the preferred choice.
However, disallowing retries at lower rates also resulted in increased
amounts of observable packet loss, especially while the connection to
the AP was still fresh and bad Tx rates had not been discovered yet.
To get the best of both worlds, use a constant Tx rate for retries while
MiRA is probing and otherwise allow firmware fallback to lower rates.
tested by Tracey Emery, pamela, jasper, and myself, on 7265/8265/9260
|
|
in inteldrm(4).
ok guenther@
|
|
maps. This lets witness know that these really are different classes
avoiding false positives when detecting lock order reversals.
ok guenther@, visa@, mpi@
|
|
|
|
|
|
ok ratchov@
|
|
processors not all microarchitectural side effects are abandoned,
leading to spectre-like effects. This was fixed quietly and without
responsible disclosure by ARM in linux mainline a year ago, but
rediscovered independently by Anthony Steinhauser. ok patrick
guenther kettenis
comment to ARM: "Responsible Disclosure" doesn't mean "downplay at
maximum to avoid damage to the bottom line", the responsibility aspect
entails ensuring "all customers are aware of the defect". What
happened here is indistinguishable from Intel's behaviour, and that's
not the look you want.
|
|
While FIDO/U2F keys were already supported by the generic uhid(4)
driver, this driver adds the first step to tighten the security of
FIDO/U2F access. Specifically, users don't need read/write access to
all USB/HID devices anymore and the driver also improves integration
with pledge(2) and unveil(2): It is pledge-friendly because it doesn't
require any ioctls to discover the device and unveil-friendly because
it uses a single /dev/fido/* directory for its device nodes.
It also allows to support FIDO/U2F in firefox without further
weakening the "sandbox" of the browser. Firefox does not have a
proper privsep design and many operations, such as U2F access, are
handled directly by the main process. This means that the browser's
"fat" main process needs direct read/write access to all USB HID
devices, at least on other operating systems. With fido(4) we can
support security keys in Firefox under OpenBSD without such a
compromise.
With this change, libfido2 stops using the ioctl to query the device
vendor/product and just assumes "OpenBSD" "fido(4)" instead. The
ioctl is still supported but there was no benefit in obtaining the
vendor product or name; it also allows to use libfido2 under pledge.
With feedback from deraadt@ and many others
OK kettenis@ djm@ and jmc@ for the manpage bits
|
|
Some numbers may be wrong but it a start and further fixes can
happen in tree. Especially the LPDDRx case is untested.
OK deraadt@
|
|
From Joe Gidi.
|
|
especially KERNCZ (AMD FCH SMBus). Additionally this also implements
multi-bus support for SB800, Hudson-2 and KERNCZ.
Tested by many. Input & OK kettenis@
|
|
OK deraadt@ kettenis@
|
|
ok deraadt@
|
|
Spotted by Hrvoje Popovski using witness(4)
OK dlg@
|
|
* Enable gen2 link training when the dtb is configured with
max-link-speed = <2>;
* Workaround a rockchip bug where Target Link Speed is not set when
PCIE_CLIENT_PCIE_GEN_SEL_2 is configured
* Wait for LTSSM L0 state after initial link training to ensure gen2
link training does not start too early
okay kettenis@
|
|
OK tedu@
|
|
OK tedu@
|
|
OK tedu@
|
|
OK tedu@
|
|
OK tedu@
|
|
ACPI lock and when we call our own ws_[gs]et_param functions we cannot
take the lock again, because it's non-recursive. Thus we need to find
another way, like not taking the lock if we already have it. But the
solutions need to be discussed first, so back it out in the meantime.
|
|
|
|
calling the ACPI methods. On some machines, like my X395,
those ACPI methods don't allow changing the brightness, so
this allows acpivout(4) to e.g. use amdgpu(4)'s code.
ok kettenis@
|
|
Attaches pvclock with lower priority (500) in case of unstable tsc
(PVCLOCK_FLAG_TSC_STABLE) instead of not attaching at all. In this state, we do
make sure to return a monotonically increasing number.
This mostly helps openbsd guests on openbsd vmm(4) where a pvclock with unstable
tsc is still better than i8254.
ok mlarkin@
|
|
This diff ensures we reload the VMCS before we dump its content in a few
debug code paths, and ensures we flush the VMCS in a few error paths
in the writeregs VMX function.
|
|
xen_intr_unmask_release was not decrementing the reference counter
on the interrupt source structure when bailing out early which led
to the refcnt overflow.
From niklas, ok mlarkin
|
|
Missing piece of tickless timeout revert.
|
|
structures"
Backed out during revert of "timeout(9): switch to tickless backend".
Original commit message:
- CIRCQ_APPEND -> CIRCQ_CONCAT
- Flip argument order of CIRCQ_INSERT to match e.g. TAILQ_INSERT_TAIL
- CIRCQ_INSERT -> CIRCQ_INSERT_TAIL
- Add CIRCQ_FOREACH, use it in ddb(4) when printing buckets
- While here, use tabs for indentation like we do with other macros
ok visa@ mpi@
|
|
timehands.th_adjustment"
Reverted with backout of tickless timeouts.
Original commit message:
We currently mix timecounter.tc_freq_adj and timehands.th_adjtimedelta
in ntp_update_second() to produce timehands.th_adjustment, our net skew.
But if you set a low enough adjfreq(2) adjustment you can freeze time.
This prevents ntp_update_second() from running again. So even if you
then set a sane adjfreq(2) you cannot unfreeze time without rebooting.
If we just reread timecounter.tc_freq_adj every time we recompute
timehands.th_scale we avoid this trap. visa@ notes that this is
more costly than what we currently do but that the cost itself is
negligible.
Intuitively, timecounter.tc_freq_adj is a constant skew and should be
handled separately from timehands.th_adjtimedelta, an adjustment that
we chip away at very slowly.
tedu@ notes that this problem is sort-of an argument for imposing range
limits on adjfreq(2) inputs. He's right, but I think we should still
separate the counter adjustment from the adjtime(2) adjustment, with
or without range limits.
ok visa@
|
|
Tested by anton@, sashan@
OK mpi@, anton@, sashan@
|
|
In kqueue_scan(), threads have to get an exclusive access to a knote
before processing by calling knote_acquire(). This prevents the knote
from being destroyed while it is still in use. knote_acquire() also
blocks other threads from processing the knote. Once knote processing
has finished, the thread has to call knote_release().
The kqueue subsystem is still serialized by the kernel lock. If an event
filter sleeps, the kernel lock is released and another thread might
enter kqueue_scan(). kqueue_scan() uses start and end markers to keep
track of the scan's progress and it has to be aware of other threads'
markers.
This patch is a revised version of mpi@'s work derived
from DragonFly BSD. kqueue_check() has been adapted from NetBSD.
Tested by anton@, sashan@
OK mpi@, anton@, sashan@
|
|
compilers that OpenBSD provides have builtins for vararg routines
and use the machine-independent definitions in <sys/stdarg.h>.
Input from miod@
OK millert@
|
|
the area where the boot loader copies the kernel. Its EfiLoaderCode
is write protected, so the boot loader hangs in memmove(). As we
may use this memory after calling EFI ExitBootServices(), change
the protection bit to writeable in the page table.
OK deraadt@ mlarkin@ patrick@
|
|
- reduces gratuitous differences with NetBSD,
- merges multiple '#ifdef _KERNEL' blocks,
- kills unused 'struct vm_map_intrsafe'
- turns 'union vm_map_object' into a anonymous union (following to NetBSD)
- move questionable vm_map_modflags() into uvm/uvm_map.c
- remove guards around MAX_KMAPENT, it is defined&used only once
- document lock differences
- fix tab vs space
ok mlarkin@, visa@
|