Age | Commit message (Collapse) | Author |
|
|
|
|
|
From Florian Riehm
|
|
|
|
Architecture Reference Specification, the sum of the 8 trap entry words
*and* of the payload which address and length are to be set at well-known
positions in the aforementioned trap entry, needs to be zero; the existing
code was only enforcing that the sum of the trap entry words is zero.
This matches what Linux and NetBSD do.
ok kettenis@
|
|
bit fields with their right sizes (the L2PARERR field on PCXL processors being
4 bits wide, not 1 bit), and make comments consistent accross these functions.
ok kettenis@
|
|
changed a lot in the last 5 years; verified to work on a 3GB system, in
snapshots for a few weeks already.
|
|
having to
modify various third party apps using the V4L2 API to build on OpenBSD specifically.
"I think this is the right thing to do" miod@
"Fine with me." sthen@
|
|
will be used from.
this adds pool_setipl at IPL_VM to the crypto descriptor pools, and
removes all the splvm handling around the use of those pools.
tested by many via tech@
ok kettenis@ deraadt@
|
|
make the crypto taskq protect things at IPL_VM instead of IPL_HIGH.
everything else in crypto.c uses splvm/IPL_VM. it seems this IPL_HIGH
came about because the hand rolled task list and thread that crypto
used to use was converted to workqs, which unconditionally used
IPL_HIGH internally. when it was converted from workqs to tasks it
blindly ported the protection workqs gave.
tested by many via tech@ and snapshots
ok kettenis@
|
|
|
|
while in the manpage add volatile where the code has it too.
ok miod@ guenther@
|
|
Both sys_mkfifo(2) and sys_mkfifoat(2) could be replace by libc wrappers
using mknodat(2) at a later date if we desire. OK guenther@
|
|
If there is a tie then a carp interface is not allowed to win even if
it has an address with a longer bitwise match. This allows reliable IPv6
communication between carp master and backup across a shared IPv6 subnet.
Consider the carp address 2001:DB8:10::14, which is configured on firewall A
(in carp master state) and firewall B (in carp backup state), each of which
has another address in the same prefix on a non-carp interface (A has
2001:DB8:10::1 and B has 2001:DB8:10::11). In this setup, A would use
2001:DB8:10::14 as source address when sending neighbour solicitations to B.
Since 2001:DB8:10::14 is a local address from B's point of view, B never
replied to the neighbour solicitations sent by A.
With this change A uses 2001:DB8:10::1 as source address instead.
ok mpi@
|
|
userland.
Fix a warning from gcc-4.9:
../../../../ufs/ufs/dir.h:113:33: warning: variably modified 'dh_firstfree' at file scope
ok kettenis@
|
|
|
|
everything else in crypto.c uses splvm/IPL_VM. it seems this IPL_HIGH
came about because the hand rolled task list and thread that crypto
used to use was converted to workqs, which unconditionally used
IPL_HIGH internally. when it was converted from workqs to tasks it
blindly ported the protection workqs gave.
tested by many via tech@ and snapshots
ok kettenis@
|
|
redundant copies of the same information. No functional change.
Also add some comments as to how these globals are used.
|
|
wasn't freeed when the interface is destroyed. Free it properly.
ok dlg
|
|
|
|
through the remainder of the attachment logic.
|
|
OK blambert@ yasuoka@
|
|
|
|
|
|
ok deraadt@
|
|
|
|
|
|
The previous lack of error handling could trigger a kernel crash
in some situations, with ulptwrite being called while not ready.
ok deraadt phessler
|
|
DMA segment size when setting up the TX buffers in msk_init_tx_ring().
ok jsg@
|
|
|
|
|
|
Enforcing W^X in the kernel like this mitigates at least some ret2dir attacks.
ok mlarkin@, deraadt@
|
|
|
|
construct ELF executables for which ep_daddr ends up not being properly
aligned. Sanitize the addresses before setting up the address space for the
new executable. Should fix the panic discovered by Alejandro Hernandez.
ok miod@
|
|
as well as useless include of the generated flag files.
|
|
ok ratchov@, sthen@, mpi@
|
|
sys/arch/i386/i386/bios.c, ok deraadt
|
|
bus_space(9) diff.
ok sthen@
|
|
| i386/bus_space.c:1.5->1.6
| i386/machdep.c:1.551->1.552
| include/bus.h:1.61->1.62
|
|
ok deraadt@, armani@
|
|
hiding, it is a lot of other systems too.
|
|
MD code needs excess #ifndef SMALL_KERNEL
|
|
|
|
with an ihandle instead of a phandle. And also the comparison was the
wrong way around.
This bug was causing an exception. Because -1 is returned to indicate
failure and because the comparison is the wrong way around, the bad logic
led to believing that SUNW,retain exists which is why this currently
works on some PROMs.
On E250/E450 machines, this didn't work so there was a hack to detect
these machines and work-around the problem. After this fix that hack is
now removed.
Tested on an E450 by sebastia@ and confirmed that his dmesg is now
retained after a reboot. nick@ promises to complain if his E250 is any
worse off.
ok kettenis@
|
|
|
|
introduce a new sysctl, hw.perfpolicy, that governs the policy.
when set to anything other than manual, hw.setperf then becomes read only.
phessler was heading in this direction, but this is slightly different. :)
|
|
src/sys/arch/amd64/amd64/bus_space.c r1.22
src/sys/arch/amd64/include/bus.h r1.27
instead of using the tag as an identifier for IO or memory mappings
that was checked inside the api, turn it into a pointer to a structure
of function pointers. the api then generally becomes a set of macros
that deref the function pointers on the callers behalf. the idea
is that following a pointer to very small functions is cheap compared
to doing compares continuously.
the kernel is smaller and the api is more cache friendly now.
the porting of this code from amd64 to i386 was done by kimberley manning
requested by and ok tedu@
|
|
pfsync_sendout. more specifically, move the reset of sc->sc_len to
PFSYNC_MINPKT above ip_output.
this prevents a situation where ipsec via ip_output calls
pfsync_update_tdb for syncing the ipsec flow to a peer, which
accounts for the tdb in the next pfsync packet, before unwinding
back to pfsync_output which resets the accounting we just did.
the next pfsync packet to be sent out will be allocated with a short
length because sc_len is wrong, and the long lists of things (eg,
the tdb) can overwrite memory after the mbuf. this manifests as
incorrect poisoning or xsimpleq entry corruption in mbufs still in
a pool, or random corruption of m->m_next on other mbufs in the
system.
bug found, fix tested, and ok stsp@
|
|
|
|
Pointed out by Mark Cave-Ayland.
|