| Commit message (Collapse) | Author | Files | Lines |
|---|
|
|
|
|
|
|
|
|
|
Signed-off-by: Jonathan Neuschäfer <j.neuschaefer@gmx.net>
|
|
The main function, mpmc_ring_selftest, is already marked with __init,
but the callback functions and the ring pointer were not.
|
|
mpmc_ptr_ring_produce takes a void*.
This fixes the following warning:
net/wireguard/selftest/mpmc_ring.h: In function ‘producer_function’:
net/wireguard/selftest/mpmc_ring.h:43:38: warning: passing argument 2 of ‘mpmc_ptr_ring_produce’ disc]
while (mpmc_ptr_ring_produce(ring, (const void *) count))
^
|
|
mpmc_ptr_ring.h should include the headers that it needs explicitly.
This commit adds the following:
- <asm/barrier.h>: smp_rmb, smp_wmb, smp_mb__before_atomic
- <linux/atomic.h>: atomic_t, atomic_read, atomic_set, atomic_cmpxchg, atomic_inc
- <linux/cache.h>: ____cacheline_aligned_in_smp
- <linux/compiler.h>: READ_ONCE, WRITE_ONCE
- <linux/errno.h>: ENOMEM
- <linux/log2.h>: is_power_of_2
- <linux/processor.h>: cpu_relax
- <linux/slab.h>: kcalloc, kfree
- <linux/stddef.h>: NULL
I'm not sure if all of them are really needed because I wasn't about to
provoke a compile error due to the missing includes.
Signed-off-by: Jonathan Neuschäfer <j.neuschaefer@gmx.net>
|
|
|
|
|
|
|
|
For producers/consumers we use atomic_t which is really int, so size_t
could either be too large, wasting memory, or too small (unlikely).
For size, we also want to be using unsigned int, since the mask that we
derive from it is ANDed with producer/consumer.
|
|
|
|
From https://www.kernel.org/doc/Documentation/memory-barriers.txt:
> SMP memory barriers are reduced to compiler barriers on uniprocessor
> compiled systems because it is assumed that a CPU will appear to be
> self-consistent, and will order overlapping accesses correctly with
> respect to itself.
Since we only order CPU memory accesses with the memory barriers in
mpmc_ptr_ring.h, smp_[rw]mb() should be sufficient.
Signed-off-by: Jonathan Neuschäfer <j.neuschaefer@gmx.net>
|
|
I'm not completely sure about this.
It also doesn't fix all the errors: sometimes the test suite reports
that it fails to send packets.
|
|
They are updated together, so it doesn't make much sense to keep them
separate in the cache.
|
|
The index range doesn't get large enough to warrant 64-bit indices.
|
|
|
|
|
|
|
|
TODO: actually use the right memory barriers in the right places
TODO: eliminate false sharing between mpmc_ptr_ring members
TODO: reconsider atomic_long_t vs. atomic_t, vs. the type of size in _init()
TODO: sprinkle likely/unlikely on some branches
FIXME: it still crashes
|
|
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.
|
|
|
Thomas Gschwantner
Jonathan Neuschäfer
Jason A. Donenfeld