summaryrefslogtreecommitdiff
path: root/src/shared/calendarspec.c
diff options
context:
space:
mode:
authorAlin Rauta <alin.rauta@intel.com>2015-03-18 05:06:19 -0700
committerTom Gundersen <teg@jklm.no>2015-03-23 22:36:17 +0100
commitea342a99fd4bbdb25e690186b25a8f1c88ed61b3 (patch)
tree695cf8081d30ef1047922195cd1590cd39825cbc /src/shared/calendarspec.c
parenteaa5251d9167027275d8275862e23e0b7dc8866e (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/shared/calendarspec.c')
0 files changed, 0 insertions, 0 deletions