| Age | Commit message (Collapse) | Author |
|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
With much assistance from miod@
ok deraadt@@
|
|
ok miod@ deraadt@
|
|
ok miod@
|
|
ok miod@
|
|
Much discussion with and assistance from miod and deraadt
ok miod@
|
|
|
|
this differs slightly from 1.121 in that it uses the new srp_follow()
to walk the list of descriptors on an interface. this is instead
of interleaving srp_enter() and srp_leave(), which can lead to races
and corruption if you're touching the same SRPs at different IPLs
on the same CPU.
ok deraadt@ jmatthew@
|
|
hazard pointers were becoming corrupt and therefore panics.
the problem turned out to be that bridge_input calls if_input on
behalf of a hardware interface which then calls bpf_mtap at splsoftnet,
while the actual hardware nic calls if_input and bpf_mtap at splnet.
the hardware interrupts ran in the middle of the bpf calls bridge
runs at softnet. this means the same srps are being entered and
left on the same cpu at different ipls, which led to races because
of the order of operations on the per cpu hazard pointers.
after a lot of experimentation, jmatthew@ figured out how to deal
with this problem without introducing per cpu critical sections
(ie, splhigh) calls in srp_enter and srp_leave, and without introducing
atomic operations.
the solution is to iterate forward through the array of hazard
pointers in srp_enter, and backward in srp_leave to clear. if you
guarantee that you leave srps in the reverse order to entering them,
then you can use the same set of SRPs at different IPLs on the same
CPU.
the ordering requirement is a problem if we want to build linked
data structures out of srps because you need to hold a ref to the
current element containing the next srp to use it, before giving
up the current ref. we're adding srp_follow() to support taking the
next ref and giving up the current one while preserving the structure
of the hazard pointer list. srp_follow() does this by reusing the
hazard pointer for the current reference for the next ref.
both mattieu baptiste and jmatthew@ have been hitting this pretty
hard with a tweaked version of srp+bpf that uses srp_follow instead
of interleaved srp_enter/srp_leave sequences. neither can reproduce
the panics anymore.
thanks to mattieu for the report and tests
ok jmatthew@
|
|
|
|
Historically, \- was used in troff for three cases: flags/pathnames,
en dashes, and minus signs. mandoc_char(7) currently recommends it
for minus signs, recommends \(en for en dashes, and doesn't mention
flags/pathnames.
In the old days, nroff rendered \- as ASCII '-', and troff rendered
it as en dash/minus (which were visually indistinguishable).
In Unicode, en dashes and minus signs are semantically distinct and
encoded differently (U+2013 for en dash, U+2212 for minus), and
often rendered differently too. Meanwhile ASCII '-' has been renamed
"hyphen-minus" and fonts typically render it closest to a hyphen, not
a minus.
There is very little consistency across roff implementations and output
formats for what Unicode character \- corresponds to. So at least for
minus signs, change the recommendation to the unambiguous \(mi escape.
ok jmc@ (after reams of discussion)
|
|
|
|
|
|
|
|
multiple domain names in dhcp option 15 (Domain Name). This allows
resolv.conf 'search' statements to be built with multiple entries.
Adhere to the limits stated in resolv.conf(5) - no more than 6
domains and less than 1024 characters total length.
Encountered in the wild and fix tested by beck@. Feedback from
deraadt@
|
|
address. Add test for syslogd -p log_socket.
|
|
specific programm or host. It does not make sense to truncate the
string from the config at some character from a list. Just take
whatever the user specified as progname or hostname. If it contains
funky charactes it will not match and the action is not taken. This
fixes matching with IP addresses if syslogd is started with -n.
OK semarie@
|
|
PR_WAITOK flag to pool_init and pass NULL as the pool allocator.
ok mlarkin@
|
|
|
|
when we actually want it to.
ok deraadt@
|
|
|
|
skipping a libc crank since unused in base on 64bit systems
discussed with miod, tedu; ok kettenis
|
|
|
|
are only two loadable segments. With W^X on OpenBSD, we will typically
create more than two. Most shared libraries and binaries end up with
five of them. One of them is the GOT itself so we don't need to take that
one into account. So raise the number of spare local GOT entries from 5 to 7.
This fixes building liblto_plugin.so in the gcc 4.9 port.
ok miod@, jasper@, pascal@
|
|
|
|
want to do the same for fstatfs(), after we handle statfs(). These system
calls leak path information, however I am reluctant to add a seperate
catagory.
|
|
cr_uid/cr_gid (effective ids). Thus, chown(, -1,-1) should work OK, so
should chown(, me, -1), etc. With this commited, more people can test.
|
|
those bits in the request and continue. This is a better posix-subset
to give to programs.
|
|
and verbose, who would ever spend their time reading them.
|
|
for taming the string manipulation in the later half of the program.
|
|
Cleaner, clearer and less error prone.
Tested by bmercer@ as part of a larger diff, of which this is the
last part.
reads ok to jsing@ kettenis@. ok deraadt@.
|
|
|
|
sector containing the disklabel, eliminating an unnecessary " *
DL_BLKSPERSEC()".
Tested by bmercer@ as part of larger diff.
Idea from & reads ok to jsing@. ok kettenis@.
|
|
|
|
Fewer "struct rtentry" left in the wild!
|
|
|
|
|
|
Those tests now pass even if you have an AUTOCONF'd address on your machine.
Note that the global list of prefixes is *still* not rtable ID aware.
|
|
Previously loopback connected routes were managed via the global list
of prefixes, which mean that systems with AUTOCONF'd addresses did not
see them in the routing table.
This also makes inet6 route creation coherent with inet.
|
|
usbd_transfer(9).
This fixes a use-after-free.
Bug found by and diff from John L. Scarfone <john AT scarfone DOT net>
|
|
Found while comparing IPv4 and IPv6 versions.
ok naddy@
|
|
Reported by jsg@, ok deraadt@
|
|
instead of using pool_allocator_nointr.
ok tedu@
|
