11 Aug
2015
11 Aug
'15
9:06 a.m.
On 08/11/2015 12:15 AM, Laine Stump wrote: > On 08/10/2015 01:08 PM, Maxim Perevedentsev wrote: >> Such messages do not have NLMSG_ERROR or NLMSG_DONE type >> but they are valid responses. We test 'multi-partness' >> by looking for NLM_F_MULTI flag. >> --- >> src/util/virnetlink.c | 4 +++- >> 1 file changed, 3 insertions(+), 1 deletion(-) >> >> diff --git a/src/util/virnetlink.c b/src/util/virnetlink.c >> index 0052ef9..f02bb59 100644 >> --- a/src/util/virnetlink.c >> +++ b/src/util/virnetlink.c >> @@ -386,7 +386,9 @@ virNetlinkGetErrorCode(struct nlmsghdr *resp, unsigned int recvbuflen) >> break; >> >> default: >> - goto malformed_resp; >> + /* We allow multipart messages. */ >> + if (!(resp->nlmsg_flags & NLM_F_MULTI)) >> + goto malformed_resp; > 1) It's interesting that they don't seem to define what type the message > will be in these cases (it's not NLMSG_DONE or NLMSG_ERROR, and the only > other standard types are NLMSG_NOOP and NLMSG_OVERRUN.) So what *is* the > type in the case of a multipart message. I tried it myself (centos7) and the type was 20 (I don't remember, hex or decimal) which is unspecified so we should not rely on particular type. > 2) Doesn't the presence of the NLM_F_MULTI flag indicate that we need to > look for another packet, rather than just returning? It's been a long > time since I looked at the details of the netlink message handling, but > won't this "constipate" the socket? > At the time we get there all parts of multipart message are received. This is handled internally (http://www.infradead.org/~tgr/libnl/doc/core.html). We might parse all parts but I think this is cumbersome and redundant work since it is unlikely for message to be broken in submessages. -- Your sincerely, Maxim Perevedentsev