nlmsg_len and NLMSG_ALIGN

[Thomas Haller]

On Mon, 2016-05-09 at 11:48 -0500, Joel Cunningham wrote:
> Hi,
> 
> I'm working on gaining an understanding of the libnl implementation
> and one thing I've found confusing is the usage of the nlmsg_len
> member of struct nlmsghdr.  It's my understanding that this member
> represents the currently reserved/used space in the struct nlmsgmdr,
> including padding.

I think it represents the currently used space for that nlmsg
(including header).

nlmsg_len is the length of the message that is valid/reserved.
NLMSG_ALIGN(nlmsg_len) is where the next message start (when reading
from the socket).


I don't think this includes "padding".
There is padding ~inside a message between individual attributes~. Yes,
nlmsg_len entails that kind padding, but it doesn't really know
anything about what is inside the message, whether that is padding or
data.
But nlmsg_len does not entail ~padding between the current message and
the next~.



> Throughout the libnl code, various places use nlmsg_len with
> NLMSG_ALIGN wrapped around it and other places without.  If nlmsg_len
> is supposed to already include the padding, why use NLMSG_ALIGN?
> 
> Here are a couple of examples of each:
> 
> With NLMSG_ALIGN:
> nlmsg_next

This jumps over the current message and returns the next one. Messages
must be aligned between each other, thus it uses NLMSG_ALIGN.

> nlmsg_tail
> nla_nest_end
> nla_reserve

Attributes inside a message must also be aligned with NLMSG_ALIGN().


> Without:
> nlmsg_reserve (assignment of buf)

This only reserves "len" bytes (including optional padding).
Afterwards, nlmsg_len points to the end of ALIGN(len,pad).
But nlmsg_len is not necessarily aligned with NLMSG_ALIGN().

Also, it reserves data at the current end. This end, may not be
aligned, thus it reserves it after nlmsg_len, and not
NLMSG_ALIGN(nlmsg_len).


> nl_send

nl_send sends the part of the message that is reserved and initialized.
The length of one message may not be aligned.



Thomas
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: This is a digitally signed message part
URL: <http://lists.infradead.org/pipermail/libnl/attachments/20160512/fec47cd4/attachment.sig>