Age | Commit message (Collapse) | Author |
|
ok bluhm@, visa@
|
|
Pointed out by Mark Johnston, Markj@FreeBSD
|
|
back it out until i can figure the problem out.
|
|
the code has rotted, and obviously hasnt been used for ages. it is
also hard to make mpsafe. if we need something like this again it
would be better to do it from scratch.
ok tedu@ visa@
|
|
this keeps the knowledge of ifq locking in ifq.c
ok visa@
|
|
without providing a full connection specification (sshd -T -C ...)
spotted by bluhm@
|
|
this replaces ifq_start with code that waits until at least 4 packets
have been queued on the ifq before calling the drivers start routine.
if less than 4 packets get queued, the start routine is called from
a task in a softnet tq.
4 packets was chosen this time based on testing sephe did in dfly
which showed no real improvement when bundling more packets. hrvoje
popovski tested this on several nics and found an improvement of
10 to 20 percent when forwarding across the board.
because some of the ifq's work could be sitting on a softnet tq,
ifq_barrier now calls taskq_barrier to guarantee any work that was
pending there has finished.
ok mpi@ visa@
|
|
taskq_barrier guarantees that any task that was running on the taskq
has finished by the time taskq_barrier returns. it is similar to
intr_barrier.
this is needed for use in ifq_barrier as part of an upcoming change.
|
|
above and enable the driver on arm64.
From Artturi Alm. Tested by Stephen Graf.
|
|
From Artturi Alm. Tested by Stephen Graf.
|
|
Issue reported by Alexi Malinin via bugs@. Thanks!
|
|
|
|
It isn't safe to manipulate PF_KEY sockets without KERNEL_LOCK() because
they aren't protected by the NET_LOCK().
I missed this in my previous audit and neither my tests, the regression
tests nor the IPsec performance tests exposed the problem. Hopefully I
added the right check to soassertlocked() a while back.
Found the hardway by and ok sthen@
|
|
|
|
This matches splassert(9)s behavior and prevent noise when a CPU
panic(9) and set splassert_ctl to 0.
Found the hardway by sthen@
|
|
screen. GitHub issue 1150.
|
|
pass in proto icmp max-pkt-rate 100/10
all packets matching the rule in the direction the state was created are
taken into consideration (typically: requests, but not replies).
Just like with the other max-*, the rule stops matching if the maximum is
reached, so in typical scenarios the default block rule would kick in then.
with input from Holger Mikolon
ok mikeb
|
|
Recognize this state and allow user configuration of the pin if the
pin is left into this state.
tested by Stephen Graf.
|
|
ok visa@, benno@
|
|
having pf_ouraddr say a packet is forwarded let's in_ouraddr avoid
doing a route lookup for the packet. however, because it is forwarded
we need to do a route lookup in ip_output anyway to know where it
goes.
in_ouraddr does a bunch of extra checks on the result of the route
lookup that ip_output does not do though, including special handling
of ip_directedbroadcast and M_BCAST. if you have directed broadcast
enabled and do not do these checks, the ethernet layer will loop a
copy of broadcast packets back into the stack recursively which
can blow the thread stack in the kernel.
discussed with jmatthew@, sashan@, and henning@
ok mpi@
diagnosing this led to the enabling of a guard page on amd64 kernel
stacks, which was necessary for correctly identifying this problem.
|
|
currently serves no purpose.
ok rpe, agreement from deraadt and halex
|
|
IPsec is enabled.
This is currently a no-op since we still use a single taskq. But it
will allows us to experiment with multiple forwarding threads and the
PF_LOCK() without having to fix IPsec at the same time.
ok sashan@, visa@
|
|
|
|
still use integers, so use the natural bounds for these.
POSIX says m4 should error when these use non numeric values, and now they
do.
okay millert@
|
|
|
|
diff from carlos cardenas, thanks.
|
|
etc) from underlying switch interface instead of handling this on its
own.
Diff from carlos cardenas, Thanks!
ok reyk@
|
|
Diff from Carlos Cardenas, thanks!
ok krw@
|
|
|
|
ok schwarze@ "good compromise" jmc@
|
|
soon as the TRACE function is called. This helps while debugging crashes.
Noticed and annoyed by while debugging the SIGTERM crash I just submitted.
OK millert@ and tb@
|
|
mode.
Found while testing previous commit by millert@
OK millert@ and tb@
|
|
Inputs and ok jsing@.
|
|
regular file with the expected permissions and locks it. Inspired
by changes in NetBSD by Christos. OK martijn@
|
|
the recover file fd open so just run sendmail with stdin set to
the recover file. OK martijn@
|
|
do things differently in the ps vs pdf case.
okay schwarze@
|
|
This will be used to first allow read-only ioctl(2) to be executed while
the softnet taskq is running. Then it will allows us to execute multiple
softnet taskq in parallel.
Tested by Hrvoje Popovski, ok kettenis@, sashan@, visa@, tb@
|
|
Input and OK jca@, OK florian@
|
|
hint in case of symlinks.
|
|
Reporting OpenBSD bugs to GNU makes no sense...
|
|
|
|
from semarie
I meant to do that at p2k17 but totally forgot...
|
|
renew/rebind/expiry. Treat renew/rebind/expiry statements in leases as
comments for human consumption.
|
|
|
|
purged. Remove it and move the prototype to if.c since ifconf() is
not used outside of this file.
ok mpi
|
|
using a mutex. This lets octmmc_intr() run without the KERNEL_LOCK().
Tested on CN6120, CN7130 and CN7360.
|
|
ensures that scapy's SYN+ACK packet hits the TCP stack when it hurts.
|
|
calls in tcp_input(). When I added this code for socket splicing,
I have missed that they may be called indirectly through functions.
Although not strictly necessary since we have the sosplice thread,
put that flag consistently when we want to prevent that tcp_output()
is called in the middle of tcp_input(). As soisconnected(),
soisdisconnected(), and socantrcvmore() call the wakeup functions
from tcp_input(), set the TF_BLOCKOUTPUT flag around them.
OK visa@
|
|
termination issue that can arise when parsing IP options.
The bug was found by Hrvoje Popovski with ping -R.
Fix tested by Hrvoje, OK millert@
|
|
From Klemens Nanni.
ok markus@
|