It turns out that the binary actually gets smaller if we simply inline
the very small parts of libmnl that we need. Since we wind up needing
the mnlg bits anyway, there's little benefit in linking to libmnl.
Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
We used to reach back into parent directories for this, but with the
repo split, we now require our own copy.
We use -idirafter in case system headers are installed for the
wireguard.h netlink definitions.
Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
Netlink returns NLM_F_DUMP_INTR if the set of all tunnels changed
during the dump. That's unfortunate, but is pretty common on busy
systems that are adding and removing tunnels all the time. Rather
than retrying, potentially indefinitely, we just work with the
partial results.
Reported-by: Robert Gerus <ar@is-a.cat>
Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
It's not used for anything, and LKML doesn't like the type being used as
an index value.
Suggested-by: Eugene Syromiatnikov <esyr@redhat.com>
Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
The kernel has very specific rules correlating file type with comment
type, and also SPDX identifiers can't be merged with other comments.
Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
It's good to have SPDX identifiers in all files as the Linux kernel
developers are working to add these identifiers to all files.
Update all files with the correct SPDX license identifier based on the license
text of the project or based on the license in the file itself. The SPDX
identifier is a legally binding shorthand, which can be used instead of the
full boiler plate text.
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Modified-by: Jason A. Donenfeld <Jason@zx2c4.com>
Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
This gets us nanoseconds instead of microseconds, which is better, and
we can do this pretty much without freaking out existing userspace,
which doesn't actually make use of the nano/micro seconds field:
zx2c4@thinkpad ~ $ cat a.c
void main()
{
puts(sizeof(struct timeval) == sizeof(struct timespec) ? "success" : "failure");
}
zx2c4@thinkpad ~ $ gcc a.c -m64 && ./a.out
success
zx2c4@thinkpad ~ $ gcc a.c -m32 && ./a.out
success
This doesn't solve y2038 problem, but timespec64 isn't yet a thing in
userspace.
Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
One types:
for (i = 0 ...
So one should also type:
for_each_obj (obj ...
But the upstream kernel style guidelines are insane, and so we must
instead do:
for_each_obj(obj ...
Ugly, but one must choose his battles wisely.
Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
DaveM suggests we do in fact do this. Others on the same thread weren't
happy about the length of the proposed message, so we also give a bit of
a less dramatic warning.
This reverts commit a2cc976a3b572cf308cc2d97c080eacac60416fe.
Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
Maybe an attacker on the system could use the infoleak in /proc to gauge
how long a wg(8) process takes to complete and determine the number of
leading zeros. This is somewhat ridiculous, but it's possible somebody
somewhere might at somepoint care in the future, so alright.
Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
