| Age | Commit message (Collapse) | Author |
|---|
|
machdep.unaligned_* sysctl to control its behaviour. Such code made sense more
than 20 years ago where a lot of code was not 64-bit clean, but this is no
longer the case those days.
ok jsg@ millert@ deraadt@
|
|
|
|
Previously for __cpu_simple_lock parts. Now only hppa and m88k use
__cpu_simple_lock (and hppa uses atomic.h for it).
ok miod@ visa@
|
|
ok jca@
|
|
Define a consistently named db_machine_command_table[] across all
archs that implement the MD "machine" command, and hook this into
the main command table instead of patching it at runtime.
ok mpi@ jca@
|
|
ok miod@
|
|
ok mpi@
|
|
do not bother operating on its first 8 bytes, which will always be zero.
ok visa@
|
|
this file
|
|
|
|
|
|
SYS_syscall as the nosys() function into the MD syscall entry
routines and the SYSCALL_DEBUG support. Adjust alpha's syscall
check to match the other archs. Also, make sysent const to get it
into .rodata.
With that, 'struct emul' is unused: delete it and all its references
ok millert@
|
|
API implemented is a deadend.
OK akoshibe@ yasuoka@ deraadt@ kn@ patrick@ sthen@
|
|
3rd (variadic) mode_t parameter is irrelevant. Many developers in the past
have passed mode_t (0, 044, 0644, or such), which might lead future people
to copy this broken idiom, and perhaps even believe this parameter has some
meaning or implication or application. Delete them all.
This comes out of a conversation where tb@ noticed that a strange (but
intentional) pledge behaviour is to always knock-out high-bits from
mode_t on a number of system calls as a safety factor, and his bewilderment
that this appeared to be happening against valid modes (at least visually),
but no sorry, they are all irrelevant junk. They could all be 0xdeafbeef.
ok millert
|
|
the asynchronous crypto API which makes progress in MP difficult.
The hardware is rarely available. They support only obsolete crypto
algorithms. Scheduling crypto tasks via PCI is probably slower
than the CPU, especailly as modern CPUs have their own accelerators.
|
|
data from struct process anymore. This changes how siginfo and onstack
are accessed and make sendsig() more MP friendly.
With and OK semarie@ OK kettenis@
|
|
back in 2019.
ok mpi@
|
|
keyboard is a pseudo device which is used to expose audio and
application launch keys. My prime motivation is to get the volume mute,
increment and decrement keys to just work on my keyboard without the
need to use usbhidaction(1).
Looks reasonable to kettenis@ mpi@ and ok jcs@
|
|
waiting on CPUs that didn't spin up. This will allow us to spin down
CPUs in the future to save power as well.
ok mpi@
|
|
|
|
Add a 512-byte buffer (ci_panicbuf) to each cpu_info struct on each
platform for use by panic(9). The first panic on a given CPU writes
its message to this buffer. Subsequent panics on a given CPU print
the panic message to the console but do not modify the buffer. This
aids debugging in two cases:
- If 2+ CPUs panic simultaneously there is no risk of garbled messages
in the panic buffer.
- If a CPU panics and then the operator causes a second panic while
using ddb(4), the operator can still recall the first failure on
a particular CPU.
Misc. changes to support this bigger change:
- Set panicstr atomically to identify the first CPU to reach panic().
- Tweak db_show_panic_cmd() to print all panic messages across all
CPUs. Prefix the first panic with an asterisk ('*').
- Prefer db_printf() to printf() during a panic if we have it.
Apparently it disturbs less global state.
- On amd64, tweak fault() to write the local panic buffer. This needs
more work.
Prompted by bluhm@ and deraadt@. Mostly written by deraadt@.
Discussed with bluhm@, deraadt@ and kettenis@.
Borne from a discussion on tech@ about making panic(9) more MP-safe:
https://marc.info/?l=openbsd-tech&m=162086462316143&w=2
ok kettenis@, visa@, bluhm@, deraadt@
|
|
|
|
The timecounter struct is large and I think it may change in the
future. Changing it later will be easier if we use C99-style
initialization for all timecounter structs. It also makes reading the
code a bit easier.
For reasons I cannot explain, switching to C99-style initialization
sometimes changes the hash of the resulting object file, even though
the resulting struct should be the same. So there is a binary change
here, but only sometimes. No behavior should change in either case.
I can't compile-test this everywhere but I have been staring at the
diff for days now and I'm relatively confident this will not break
compilation. Fingers crossed.
ok gnezdo@
|
|
exposing battery sensors for HID++ 2.0 devices. Most of the code is
derived from the hid-logitech-hidpp Linux driver.
Thanks to Ville Valkonen <weezeldinga at gmail dot com> for testing.
ok mglocker@
|
|
ok kettenis
|
|
SMALL_KERNEL specific variations.
ok espie jsg
|
|
This includes ujoy_hid_is_collection() to work around limitations of
hid_is_collection() until this can be combined without fallout.
input, testing with 8bitdo controller, and ok brynet@
PS4 controller testing, fix for hid_is_collection, and ok mglocker@
|
|
At a minimum, amd64/i386 should now boot from 4TB GPT formatted disks.
More daddr32_t terminations with extreme prejudice to follow.
Tested by various, in snaps for a few days.
ok deraadt@
|
|
Simplify MD code and reduce the amount of recursion into the signal code
which helps when dealing with locks.
ok cheloha@, deraadt@
|
|
to need KERNE_LOCK. Been testing this for about 3 weeks.
|
|
|
|
as best we can.
|
|
minor refactorings to narrow KERNEL_LOCK just around uvm_fault()
ok kettenis
|
|
The condition around uvm_grow() can be simplified, as the error result
adjustment is effectively a dead store
ok kettenis
|
|
|
|
need to do it
ok kettenis
|
|
Normally we set hz(9) at compile-time in sys/conf/param.c to the value
of HZ. HZ is one of the fundamental compilation options(4). However,
sometimes we need to reset hz(9) at runtime.
Whenever we reset hz(9) we need to recompute tick and tick_nsec.
Otherwise a variety of "time stuff" in the kernel will not work
correctly. For example, most timeouts will expire "too slow" or "too
fast". There are a bunch of other places we use tick and tick_nsec
that will exhibit similar problems.
Test-compiled by deraadt@.
|
|
ok kettenis
|
|
the current cpu so use curcpu() rather than the old cpu in ci.
ok kettenis
|
|
This should be sufficient for identifying pivoted ROP. Doing so for other
traps is at best opportunistic for finding a straight-running ROP chain,
but the added (and rare) sleeping point has proven to be dangerous.
Discussed at length with kettenis and mortimer.
ok mortimer kettenis mpi
|
|
OK deraadt@, mpi@
|
|
ok kettenis@, visa@
|
|
|
|
OK deraadt@, visa@
|
|
This diff exposes parts of clock_gettime(2) and gettimeofday(2) to
userland via libc eliberating processes from the need for a context
switch everytime they want to count the passage of time.
If a timecounter clock can be exposed to userland than it needs to set
its tc_user member to a non-zero value. Tested with one or multiple
counters per architecture.
The timing data is shared through a pointer found in the new ELF
auxiliary vector AUX_openbsd_timekeep containing timehands information
that is frequently updated by the kernel.
Timing differences between the last kernel update and the current time
are adjusted in userland by the tc_get_timecount() function inside the
MD usertc.c file.
This permits a much more responsive environment, quite visible in
browsers, office programs and gaming (apparently one is are able to fly
in Minecraft now).
Tested by robert@, sthen@, naddy@, kmos@, phessler@, and many others!
OK from at least kettenis@, cheloha@, naddy@, sthen@
|
|
"looks right" deraadt@
|
|
functionality is provided by <sys/stdarg.h> using compiler builtins.
Tested in a ports bulk build on amd64 by naddy@
OK naddy@ mpi@
|
|
ok dlg@, powerpc/sparc64 ok kettenis@, sparc64/alpha tested by deraadt@
|
|
rnd.c uses nanotime to get access to some bits that change quickly
between events that it can mix into the entropy pool. it doesn't
use nanotime to get a monotonically increasing set or ordered and
accurate timestamps, it just wants something with bits that change.
there's been discussions for years about letting rnd use a clock
that's super fast to read, but not necessarily accurate, but it
wasn't until recently that i figured out it wasn't interested in
time at all, so things like keeping a fast clock coherent between
cpu cores or correct according to ntp is unecessary. this means we
can just let rnd read the cycle counters on cpus and things will
be fine. cpus with cycle counters that vary in their speed and
arent kept consistent between cores may even be desirable in this
context.
so this is the first step in converting rnd.c to reading cycle
counter. it copies the nanotime backend to each arch, and they can
replace it with something MD as a second step later on.
djm@ suggested rnd_messybytes, but we landed on cpu_rnd_messybits.
thanks to visa for his eyes.
ok deraadt@ visa@
deraadt@ says he will help handle any MD fallout that occurs.
|
|
conversion steps). it only contains kernel prototypes for 4 interfaces,
all of which legitimately belong in sys/systm.h, which are already included
by all enqueue_randomness() users.
|
