[libvirt] [PATCHv3 2/2] Add support for multi-part netlink messages.

[Maxim Perevedentsev]

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