diff options
author | Alin Rauta <alin.rauta@intel.com> | 2015-03-18 05:06:19 -0700 |
---|---|---|
committer | Tom Gundersen <teg@jklm.no> | 2015-03-23 22:36:17 +0100 |
commit | ea342a99fd4bbdb25e690186b25a8f1c88ed61b3 (patch) | |
tree | 695cf8081d30ef1047922195cd1590cd39825cbc /src/tmpfiles | |
parent | eaa5251d9167027275d8275862e23e0b7dc8866e (diff) |
sd-rtnl: handle empty multi-part message from the kernel
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]
Diffstat (limited to 'src/tmpfiles')
0 files changed, 0 insertions, 0 deletions