| Commit message (Collapse) | Author | Age |
|---|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
We strips out NLMSG_DONE piece from a multi-part message adding into the
receive queue only the messages containing actual data.
If we send a request to the kernel for getting the forwarding database table (just an example),
the response will be a multi-part message like below:
1. FDB entry 1;
2. FDB entry 2;
3. NLMSG_DONE;
We strip out "3. NLMSG_DONE;" part and places into the receive queue a pointer to
"1. FDB entry 1; 2. FDB entry 2".
But if the FDB table is empty, the respose from the kernel will look like below:
1. NLMSG_DONE;
We strip out "1. NLMSG_DONE;" part and since there is no actual data got, it continues
waiting until reaching timeout.
Therefore, a call to "sd_rtnl_call" to send and wait for a response from kernel will exit
with timeout which is interpreted as error in communication.
This patch puts the NLMSG_DONE message on the receive queue if it ends an empty multi-part
message. This situation is detected in sd_rtnl_call() and in the callback code and NULL is
returned to the caller instead.
[tomegun:
- added/reworded commit message
- extend the same support to sd_rtnl_call_async()
- drop debug logging from library, we only do this if something is really wrong, but an
empty multi-part message is perfectly normal
- modernize the code we touch whilst we are at it]
|
| | |
|
| |
|
|
|
|
| |
Do not rely on nl_pid == 0, but check the groups instead. We currently avoid using
nl_pid == 0 for unicast anyway, so this should be redundant, but let's try to be
correct.
|
| |
|
|
|
|
|
| |
In the unlikely event that we wrap the counter, skip 0 as this is used
for broadcasts.
Suggested by Richard Maw.
|
| |
|
|
| |
Replace ENOTSUP by EOPNOTSUPP as this is what linux actually uses.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
"Notifications are of informal nature and no reply is expected, therefore the
sequence number is typically set to 0."[1]
If networkd is started soon after recent netlink activity, then there
will be messages with sequence number 0 in the buffer.
The first thing networkd does is to request a dump of all the links. If
it uses sequence number 0 for this, then it may confuse the dump request's
response with that of a notification.
This will result in it failing to properly enumerate all the links,
but more importantly, when it comes to enumerate all the addresses, it
will still have the link dump in progress, so the address enumeration
will fail with -EBUSY.
[1]: http://www.infradead.org/~tgr/libnl/doc/core.html#core_msg_types
[tomegun: sequence -> serial]
|
| | |
|
| |
|
|
|
| |
Still keep the non-socket activation code around for starting from the commandline, but
will likely drop that too in the future.
|
| | |
|
| |
|
|
|
|
| |
As in sd-bus, simply log at debug level when a callback fails, but don't fail the event handler.
Otherwise any error returned by any callback will disable the rtnl event handler. We should
only do that on serious internal errors in sd-rtnl that we know cannot be recovered from.
|
| |
|
|
| |
This does not make a difference, but the code was confusing.
|
| |
|
|
| |
This exposes an IP port on the container as local port using DNAT.
|
| |
|
|
| |
Only a minor change as the timeout would be hit soon thereafetr at the next loop.
|
| |
|
|
| |
This caused rtnl_poll to always return true immediately in sd_rtnl_call().
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
We got the following error when running systemd on a device with many ports:
"rtnl: kernel receive buffer overrun
Event source 'rtnl-receive-message' returned error, disabling: No buffer space
available"
I think the kernel socket receive buffer queue should be increased. The default
value is taken from:
"/proc/sys/net/core/rmem_default", but we can overwrite it using SO_RCVBUF
socket option.
This is already done in networkd for other sockets.
For example, the bus socket (sd-bus/bus-socket.c) has a receive queue of 8MB.
In our case, the default is 208KB.
Increasing the buffer receive queue for manager socket to 512KB should be enough
to get rid of the above error.
[tomegun: bump the limit even higher to 8M]
|
| |
|
|
|
| |
To mirror the recent name change of the concept for sd_bus objects,
follow the same logic for sd_event_source objects, too.
|
| |
|
|
|
|
|
|
|
| |
It is redundant to store 'hash' and 'compare' function pointers in
struct Hashmap separately. The functions always comprise a pair.
Store a single pointer to struct hash_ops instead.
systemd keeps hundreds of hashmaps, so this saves a little bit of
memory.
|
| | |
|
| |
|
|
| |
This should help in debugging failing event sources.
|
| | |
|
| | |
|
| |
|
|
|
| |
The bitmask is deprecated in the kernel, so move to the new interface. At the moment
this does not make a difference for us, but it avoids having to change the API in the future.
|
| | |
|
| | |
|
| |
|
|
|
|
| |
Rather than allocating/freeing memory for each message read, keep a global read buffer
in the rtnl object. Also, rather than using a fixed size, peek at the pending message
header to get the message size and reallocate as necessary.
|
| |
|
|
| |
This unifies the socket handling with other sd-* libraries.
|
| |
|
|
| |
We still only return the first message part in callback/synchronous calls.
|
| | |
|
| | |
|
| |
|
|
|
|
| |
The object is not currently used, so just drop the refenence. If/when we end up
using the object in the future, we must make sure to deal with possible mutual
references between rtnl busses and their queued messages; as is done in sd-bus.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Extend rta_offset_tb into a stack of offset tables, one for each parent of the
current container, and make sd_rtnl_message_{enter,exit}_container() pop/push
to this stack.
Also make sd_rtnl_message_rewind() parse the top-level container, and use this
when reading a message from the socket.
This changes the API by dropping the now redundant sd_rtnl_message_read()
method.
|
| |
|
|
| |
CLOCK_BOOTTIME_ALARM, too
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Like sd-bus, sd-rtnl can have self-references through queued messages. In
particular, each queued message has the following self-ref loop:
rtnl->wqueue[i]->rtnl == rtnl
Same is true for "rqueue".
When sd_rtnl_unref() gets called, we must therefore make sure we correctly
consider each self-reference when deciding to destroy the object. For each
queued message, there _might_ be one ref. However, rtnl-messages can be
created _without_ a bus-reference, therefore we need to verify the
actually required ref-count.
Once we know exactly how many self-refs exist, and we verified none of the
queued messages has external references, we can destruct the object.
We must immediately drop our own reference, then flush all queues and
destroy the bus object. Otherwise, each sd_rtnl_message_unref() call would
recurse into the same destruction logic as they enter with the same
rtnl-refcnt.
Note: We really should verify _all_ queued messages have m->rtnl set to
the bus they're queued on. If that's given, we can change:
if (REFCNT_GET(rtnl->n_ref) <= refs)
to
if (REFCNT_GET(rtnl->n_ref) == refs)
and thus avoid recalculating the required refs for each message we
remove from the queue during destruction.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
safe_close() automatically becomes a NOP when a negative fd is passed,
and returns -1 unconditionally. This makes it easy to write lines like
this:
fd = safe_close(fd);
Which will close an fd if it is open, and reset the fd variable
correctly.
By making use of this new scheme we can drop a > 200 lines of code that
was required to test for non-negative fds or to reset the closed fd
variable afterwards.
|
| |
|
|
|
| |
Otherwise the sequence number of a broadcast may match the sequence number of a
pending unicast message and cause confusion.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
first (or second)
Previously the returned object of constructor functions where sometimes
returned as last, sometimes as first and sometimes as second parameter.
Let's clean this up a bit. Here are the new rules:
1. The object the new object is derived from is put first, if there is any
2. The object we are creating will be returned in the next arguments
3. This is followed by any additional arguments
Rationale:
For functions that operate on an object we always put that object first.
Constructors should probably not be too different in this regard. Also,
if the additional parameters might want to use varargs which suggests to
put them last.
Note that this new scheme only applies to constructor functions, not to
all other functions. We do give a lot of freedom for those.
Note that this commit only changes the order of the new functions we
added, for old ones we accept the wrong order and leave it like that.
|
| |
|
|
|
|
|
|
|
| |
The "sd_" prefix is supposed to be used on exported symbols only, and
not in the middle of names. Let's drop it from the cleanup macros hence,
to make things simpler.
The bus cleanup macros don't carry the "sd_" either, so this brings the
APIs a bit nearer.
|
| | |
|
|
|
We still only produce on .so, but let's keep the sources separate to make things a bit
less messy.
|
