| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Previously, having many peers would result in many napi structs, which
could make lookups in the napi_hash in net/core/dev.c slow. So, we move
to using a single napi struct per device.
The best solution would be to replace napi_hash with an idr or just get
rid of it all together and use straight pointers. However, that isn't the
case currently, so we work with what is and begrudgingly remove per-peer
queues. On the upside, it means we reduce the per-peer memory usage by
about 8k/16k, but on the downside it means that napi_gro_receive is
called on a unified list, which might result in less GRO speedups on
systems with many peers active at once.
However, if napi_hash does ever go away, we should consider reverting
this commit.
Since this means moving to unified packet queues, flushing at peer
removal is something of a problem. So we make the slightly dubious
modification of just not flushing, and letting our reference counters do
the work. This in turn required some small changes to ensure that the
reference counter will, at some point in the future, still reach zero,
and not be kept alive by non-stop packet ingress.
Co-developed-by: Jonathan Neuschäfer <j.neuschaefer@gmx.net>
|
| |
|
|
|
|
|
|
|
| |
It's unclear why it was like this in the first place, but it apparently
broke certain IPv6 setups.
Reported-by: Jonas Blahut <j@die-blahuts.de>
|
| |
|
|
|
|
| |
Suggested-by: Thomas Gschwantner <tharre3@gmail.com>
|
| |
|
| |
|
|
|
|
|
|
| |
Suggested-by: Jason A. Donenfeld <Jason@zx2c4.com>
[Jason: fixed up the flushing of the rx_queue in peer_remove]
Signed-off-by: Jonathan Neuschäfer <j.neuschaefer@gmx.net>
|
|
|
|
|
|
|
| |
If KERNEL_VERSION ends in -debug, then automatically set DEBUG_KERNEL
If DEBUG_KERNEL is set, now the debug kernel will be built in a
separate directory from the normal kernel, so that it's easy to toggle
back and forth.
|
|
|
|
|
| |
This fixes DEBUG_KERNEL=yes due to
dd275caf4a0d9b219fffe49288b6cc33cd564312 being backported to 4.17.4.
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
| |
This is needed for frankenkernels, like android-common.
|
|
|
|
| |
Generally if we're inaccurate by a few nanoseconds, it doesn't matter.
|
|
|
|
|
|
|
|
| |
Since this is a network protocol, expirations need to be accounted for,
even across system suspend. On real systems, this isn't a problem, since
we're clearing all keys before suspend. But on Android, where we don't
do that, this is something of a problem. So, we switch to using boottime
instead of jiffies.
|
|
|
|
| |
Signed-off-by: Jonathan Neuschäfer <j.neuschaefer@gmx.net>
|
|
|
|
|
|
| |
This eliminates a few style warnings from "mandoc -T lint src/tools/wg*.8".
Signed-off-by: Jonathan Neuschäfer <j.neuschaefer@gmx.net>
|
|
|
|
| |
Signed-off-by: Jonathan Neuschäfer <j.neuschaefer@gmx.net>
|
|
|
|
| |
Suggested-by: Shlomi Steinberg <shlomi@shlomisteinberg.com>
|
|
|
|
|
|
| |
Otherwise these constants will be merged wrong or excluded, and we'll
wind up with wrong calculations. While bfd (the normal kernel linker)
doesn't seem to mind, recent versions of gold do bad things.
|
|
|
|
|
|
| |
Since chacha20poly1305 relies on the correctness of poly1305, it's
useful to have a failing poly1305 test first, to better pinpoint what's
happening.
|
|
|
|
|
|
|
| |
This had a bad performance impact. We'll probably need to revisit this
later, but for now, let's not introduce a regression.
Reported-by: Lonnie Abelbeck <lonnie@abelbeck.com>
|
| |
|
|
|
|
| |
Reported-by: Peter Korsgaard <peter@korsgaard.com>
|
|
|
|
|
|
| |
This will redirect to whichever archive kernel.org thinks is best.
Suggested-by: Konstantin Ryabitsev <konstantin@linuxfoundation.org>
|
| |
|
| |
|
|
|
|
| |
Otherwise it's too easy to trigger cookie reply messages.
|
|
|
|
|
|
|
| |
Otherwise, get_random_bytes_wait gets called from
curve25519_generate_secret, and at the same time, a user might use the
wg(8) utility, which then wants to grab a read lock for what we're write
locking.
|
|
|
|
|
| |
We don't want the local private key to not correspond with a precomputed
ss or precomputed cookie hash at any intermediate point.
|
|
|
|
|
|
|
| |
Usually this is called from handshake_init, where locking doesn't matter
because nothing references it yet, but it's also called when changing
the device private key, so it's probably a good thing to not process a
handshake with a ss precomputation that's part old and part new.
|
| |
|
| |
|
|
|
|
| |
This works around an unfortunate bug in 464XLAT transitions.
|
| |
|
| |
|
| |
|
| |
|
|
|
|
| |
Since these are the only consumers, there's no need for locking.
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
In rt kernels, spinlocks call schedule(), which means preemption can't
be disabled. The FPU disables preemption. Hence, we can either
restructure things to move the calls to kernel_fpu_begin/end to be
really close to the actual crypto routines, or we can do the slower
lazier solution of just not using the FPU at all on -rt kernels. This
patch goes with the latter lazy solution.
The reason why we don't place the calls to kernel_fpu_begin/end close to
the crypto routines in the first place is that they're very expensive,
as it usually involves a call to XSAVE. So on sane kernels, we benefit
from only having to call it once.
|
| |
|
| |
|
| |
|