Unfortunately this was done wrong. Instead of fixing it now
(and change behavior), document the behavior.
Fixes: 430eb4004ab7f93fd840e9836d4bc9220d3c406d
Signed-off-by: Thomas Haller <thaller@redhat.com>
Commit 7bb956501ccd58ed3bbffc59de996f056e178683 added nla functions for
s32. We preferibly add all signed integer operations at the same time.
Thus, also add s8, s16, and s64.
Also, previously the NLA_TYPE_MAX enum was not extended to have
NLA_S32. Fix that too.
Reported-By: Jiri Pirko <jiri@resnulli.us>
Fixes: 7bb956501ccd58ed3bbffc59de996f056e178683
Signed-off-by: Thomas Haller <thaller@redhat.com>
A wrong behavior for rtnl_neigh_get() was introduced between 3.2.14 and 3.2.15
(commit 64fcb47a36ec12d7e7f00605f6a8952ce985dd08).
It was later fixed between 3.2.21 and 3.2.22
(commit 8571f58f23763d8db7365d02c9b27832ad3d7005).
Add a capability NL_CAPABILITY_RTNL_NEIGH_GET_FILTER_AF_UNSPEC_FIX
to indicate that this buggy behavior was fixed.
https://bugzilla.redhat.com/show_bug.cgi?id=1261028http://lists.infradead.org/pipermail/libnl/2015-August/001951.html
Signed-off-by: Thomas Haller <thaller@redhat.com>
Currently, we try to handle MSG_CTRUNC, but if msg_controllen is zero, we make
double free for the same address.
realloc(0, 0) returns non-zero address
realloc(addr, 0) returns zero and free(addr) has already been called
Then we call free(addr) again and get an error like this:
*** Error in `./task_diag_all': double free or corruption (fasttop): 0x0000000000f9c160 ***
======= Backtrace: =========
/lib64/libc.so.6(+0x77e9d)[0x7f360ed96e9d]
/lib64/libc.so.6(+0x7f53c)[0x7f360ed9e53c]
/lib64/libc.so.6(cfree+0x4c)[0x7f360eda2e9c]
/lib64/libnl-3.so.200(nl_recv+0x221)[0x7f360f2f6361]
/lib64/libnl-3.so.200(nl_recvmsgs_report+0x555)[0x7f360f2f6a95]
/lib64/libnl-3.so.200(nl_recvmsgs+0x9)[0x7f360f2f6d89]
./task_diag_all[0x400f8d]
/lib64/libc.so.6(__libc_start_main+0xf0)[0x7f360ed3f790]
./task_diag_all[0x401169]
http://lists.infradead.org/pipermail/libnl/2015-September/001965.html
Signed-off-by: Andrey Vagin <avagin@openvz.org>
Signed-off-by: Thomas Haller <thaller@redhat.com>
Add LINK_ATTR_NSFD, LINK_ATTR_NS_PID and LINK_ATTR_LINK_NETNSID to the
link_attrs translation table after they were added in commits
760bfabad8cd ("add link netns support") and 66aab65595fb ("route/link:
add support for IFLA_LINK_NETNSID") respectively.
http://lists.infradead.org/pipermail/libnl/2015-August/001959.html
Signed-off-by: Tobias Klauser <tklauser@distanz.ch>
Signed-off-by: Thomas Haller <thaller@redhat.com>
When generating a port fails a few times (because they are already in used
outside of libnl's knowledge), we would back off generating a local
port and instead let kernel decide.
There was however a bug in nl_connect() that caused an assertion:
BUG at file position socket.c:147:_nl_socket_used_ports_release_all
app: socket.c:147: _nl_socket_used_ports_release_all: Assertion `0' failed.
Fixes: 96e1e5bdc2e803700055395cc3c428fa2525d1ca
Even if the local port of @sk already equals to the port of
the file descriptor @fd, we want to release a possibly generated
port and set NL_OWN_PORT.
Fixes: 2d61e890379888907a93ddd0a04187b130629f6f
Signed-off-by: Thomas Haller <thaller@redhat.com>
release_link_info() already check whether link->l_info_ops is not NULL
before accessing it, thus there is no need to do the same before calling
it.
http://lists.infradead.org/pipermail/libnl/2015-July/001929.html
Signed-off-by: Tobias Klauser <tklauser@distanz.ch>
Signed-off-by: Thomas Haller <thaller@redhat.com>
libnl allows the user to explicitly set the local port before connecting
the socket. A more convenient way is to leave the local port unspecified
and let libnl generate a port id.
As it is, generate_local_port() would try at most 1024 ports, that
means if a user tries to connect more sockets, the automatism will
fail.
Kernel also supports choosing the local port itself (via netlink_autobind()).
So, this could be fixed by always leaving the port unspecified and let
kernel decide on the port. For that we could entirely drop generate_local_port().
There are however problems with that:
- it is unclear why generate_local_port() was even introduced in the
first place instead of always relying kernel. This code already
appeared in libnl-1, so maybe there was a good reason for it or
it is necessary on some kernel versions.
- The deprecated libnl-1 library also uses a form of generate_local_port().
Its first guess would always be getpid(), but the problem is that
it would not retry on EADDRINUSE. Currently libnl-3 generates ports in
a different sequence and will not generate a conflicting port (until it
already exhausted 1016 other ports).
Hence, currently if your application uses libnl1 and libnl3
together, the automatism might just work without conflicts
(commit 1f734a8f892abcd3f81637df4a089155aca1b66a).
Accidently, kernel/netlink_autobind() also first tries the process
id as port. That means, if we change libnl-3 to leave the decision
to kernel, and
- the application connects sockets both via libnl-1 and libnl-3
- and the libnl-3 socket happens to connect first
then the libnl-1 socket would fail to connect without retrying
another port.
- Removing generate_local_port() entirely changes behavior in the
following case:
sk = nl_socket_alloc();
/* accessing local port before connecting the socket used to
* freeze the local port to the generated value. */
port = nl_socket_get_local_port(sk);
nl_connect(sk, NETLINK_...);
Maybe the issues are minor and it would simplify the code just to get
rid of the cruft. But instead fix the issue without changing behavior.
Just keep trying with generate_local_port() first, before fallback to
kernel.
Reported-by: Julien Courtat <julien.courtat@6wind.com>
Signed-off-by: Thomas Haller <thaller@redhat.com>
http://lists.infradead.org/pipermail/libnl/2015-June/001889.html
When running out of local ports, _nl_socket_generate_local_port_no_release()
would leave the socket with port UINT32_MAX. That means if nl_connect()
fails due to out-of-ports, it would leave the port id assigned to an
invalid port and the socket instance was not re-usable until the user
called nl_socket_set_local_port(). Fix that by resetting the local port
to zero.
Thereby, also change generate_local_port() to return zero when
running out of ports. zero is a more natural value for ~no port found~.
It also matches the port that _nl_socket_generate_local_port_no_release()
uses when failing to generate a port.
Also ensure that zero cannot be returned as valid port by generate_local_port().
Arguably, that would only be possible if (getpid() & 0x3FFFFF)
returns zero. Just be extra cautious.
Signed-off-by: Thomas Haller <thaller@redhat.com>
9 digits for for B/s don't make sense to me. It's just breaks the alignment.
[thaller@redhat.com: whitespace fixes]
Signed-off-by: Thomas Haller <thaller@redhat.com>
I added all the netem attributes (except for limit) to the NL_DUMP_DETAILS section.
[thaller@redhat.com: whitespace fixes]
Signed-off-by: Thomas Haller <thaller@redhat.com>
CMSG_NXTHDR requires <linux/socket.h>. This fix a build error with the musl
C library:
```
undefined reference to `__cmsg_nxthdr'
```
https://github.com/thom311/libnl/pull/83
Suppose the case:
1. message have already some payload
2. malloc() failed
In that case:
1. msg->queue_msg_payload become NULL
2. msg->queue_msg_payload_len stay non-zero
Now when malloc() error occurs, nothing changed.
https://github.com/thom311/libnl/pull/83
In case doc/configure.ac hasn't found asciidoc or any of its
prerequisites (such as pygmentize), make shouldn't try to run it.
One such case ("gendoc" target) is covered while the other
("%.html" target) is not. Fix it by adding a proper ifdef.
Signed-off-by: Kir Kolyshkin <kir@openvz.org>
A check for python binary that was originally introduced by commit
183e869 is needed because python is used for a couple of preprocessors
(doxygen-link.py and resolve-asciidoc-refs.py) and therefore it is
impossible to build docs without python.
While it is right to check for python, the check was both wrong and
excessive. Instead of just checking for python binary, it checked for
various versions of python and set a few variables that are not needed
here. More to say, the absense of python binary was not treated as
being fatal like it should.
Fix both problems by using AC_CHECK_PROG for python, terminating the
build in the same way as with doxygen absense. Also, remove the
m4/ax_python.m4 which is no longer needed.
Signed-off-by: Kir Kolyshkin <kir@openvz.org>
These files, as well as the proper configure.ac calls, were added
by commit f443be6, but the calls were later removed by commit b4b853e,
so these are no longer needed.
Signed-off-by: Kir Kolyshkin <kir@openvz.org>
This file is no longer needed since commit db13843 which copied it
to doc/ subdir and removed the call to AX_PYTHON from configure.ac.
That commit should have moved it rather than copied, let's fix it.
Signed-off-by: Kir Kolyshkin <kir@openvz.org>
The ifi_change field can be set with the mask of the flags that need
to be changed as part of the link message to the kernel. This means only
the specific flags that have been changed will be modified in the kernel,
rather than the entire flags entry.
[thaller@redhat.com: add capability to indicate the change in behavior]
https://github.com/thom311/libnl/pull/86
In the future kernel might support more modes. Don't be so
strict in rtnl_link_ipvlan_set_mode() and accept any uint16
mode.
This way when adding new modes, rtnl_link_ipvlan_set_mode() does not
need to be changed.
If the user passes an invalid value and sends a message to the kernel,
it will be rejected there.
http://lists.infradead.org/pipermail/libnl/2015-June/001902.html
Fixes: 7de5be85bf9aa3eb9f022e4813226135e89adec2
Signed-off-by: Thomas Haller <thaller@redhat.com>
Commit 6a9335f101e22cd5eaba4dfcf0a44e2c3097b4ab fixed a typo in the
string-to-flags conversion. At least for rtnl_neigh_str2state()
we want to continue to parse "norarp" for backward compatiblity.
Signed-off-by: Thomas Haller <thaller@redhat.com>
Translate NUD_NOARP to "noarp", instead of "norarp".
https://github.com/thom311/libnl/pull/79
Fixes: 44d362409d5469aed47d19e7908d19bd194493a4
Signed-off-by: Thomas Haller <thaller@redhat.com>
