| Commit message (Collapse) | Author | Files | Lines |
|
|
|
- gofmt
- Give config struct one line per field
- Use camel case
- Check errors
- Log invariants with detail
- Use consistent pronouns
|
|
|
|
|
|
|
|
It should never be the case that skb->head + skb->transport_header -
skb->data is greater than 2^16, but in case the kernel network stack
borks this at some point in the future, we don't want this to slyly
introduce a vulnerability into WireGuard.
Further, really smart compilers might be able to make deductions about
data_offset, and optimize accordingly.
|
|
|
|
|
|
|
|
We don't want people packaging these or even using these scripts, which
are only useful for limited development circumstances, so get rid of
them. More widespread development testing techniques still exist in
src/debug.mk and src/netns.sh
|
|
Suggested-by: Daniel Kahn Gillmor <dkg@fifthhorseman.net>
|
|
|
|
|
|
For the websites referenced that offer https instead of http, use
https.
|
|
|
|
The padata free functions make reference to their parent workqueue, so
it's important that we wait to free the workqueue after the padata.
|
|
|
|
Per http://lists.openwall.net/netdev/2016/05/03/87 dev->trans_start has
been removed, and updates are now supposed to be handled with
netif_trans_update, which now updates the particular txqueue's
trans_start instead.
However, netdev_start_xmit already updates this member after calling
ndo_start_xmit, so the new netif_trans_update function smartly makes the
comment that for drivers that don't use LLTX, it's not neccessary to
call netif_trans_update.
Except we do use LLTX, so it would seem again that we do need to be
calling netif_trans_update. However, glancing at drivers like vxlan and
other similar virtual tunnels, this doesn't seem to be the case. I
suspect the reason is that we both also set IFF_NO_QUEUE, so we aren't
even using a txqueue for updating.
Thus, this patch removes updating of trans_start all together. I believe
this should be okay for older kernels too.
|
|
|
|
|
|
|
|
With packets hitting multiple cores, a 64bit backtrack was too small.
This algorithm increases our backtrack to 1984bits.
|