Re: [libvirt] [PATCHv3 2/2] Add support for multi-part netlink messages.
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