From: Nicolas Dichtel <nicolas.dichtel@6wind.com>
To: Thomas Graf <tgraf@suug.ch>
Cc: bhutchings@solarflare.com, netdev@vger.kernel.org,
davem@davemloft.net, David.Laight@ACULAB.COM
Subject: Re: [PATCH v2] netlink: align attributes on 64-bits
Date: Tue, 18 Dec 2012 23:07:26 +0100 [thread overview]
Message-ID: <50D0E91E.3050702@6wind.com> (raw)
In-Reply-To: <20121218170853.GH27746@casper.infradead.org>
Le 18/12/2012 18:08, Thomas Graf a écrit :
> On 12/18/12 at 05:23pm, Nicolas Dichtel wrote:
>> Le 18/12/2012 13:57, Thomas Graf a écrit :
>>> -static inline int nla_padlen(int payload)
>>> -{
>>> - return nla_total_size(payload) - nla_attr_size(payload);
>>> + if (!IS_ALIGNED(len, NLA_ATTR_ALIGN))
>>> + len = ALIGN(len + NLA_HDRLEN, NLA_ATTR_ALIGN);
>> Two comments:
>> 1/ should it be ALIGN(len, NLA_ATTR_ALIGN)? If we want to add a __u64:
>> => nla_attr_size(sizeof(__u64)) = 12
>> => NLA_ALIGN(nla_attr_size(sizeof(__u64))) => 12 (= len)
>> => ALIGN(len + NLA_HDRLEN, NLA_ATTR_ALIGN) = 0 but it should be 4
>
> We can't add 1-3 bytes of padding, therefore we need to add
> NLA_HDRLEN to len before aligning it to enforce a minimal
> padding. We can't hit it right now because 4 byte alignment
> of the previous attribute is a given but if we ever change
> the alignment it could become an issue and the above should
> be bullet proof.
>
> Your example would come out like this:
> nla_attr_size(8) = 12
> ALIGN(12 + 4, 8) = 16
Got it, right.
>
>> 2/ Suppose that the attribute is:
>>
>> struct foo {
>> __u64 bar1;
>> __u32 bar2;
>> }
>> => sizeof(struct foo) = 12 (= payload)
>> => nla_attr_size(payload) = 16
>> => NLA_ALIGN(nla_attr_size(payload)) = 16 (= len)
>> => IS_ALIGNED(len, NLA_ATTR_ALIGN) = true
>> => extra room is not reserved
>> But it's not guaranteed that bar1 is aligned on 8 bytes, only on 4 bytes.
>
> That's correct, that's why I have added the additional
> NLA_ATTR_ALIGN of room in nlmsg_new(). It will account
> for the one time padding that is needed before we add
> the very first attribute.
>
> If all attributes after that have a size aligned to 8
> bytes no padding is needed. Padding will only be needed
> again if a struct is missized in which case we reserve
> room with the above. Correct?
Seems good ;-)
>
>>> + offset = (size_t) skb_tail_pointer(skb);
>>> + if (!IS_ALIGNED(offset + NLA_HDRLEN, NLA_ATTR_ALIGN)) {
>> With the previous struct foo, this test may be true even if we don't
>> have reserved extra room. This test depends on previous attribute.
>> I think the exact size of the netlink message depends on the order
>> of attributes, not only on the attribute itself.
>> What about taking the assumption that the start will never be
>> aligned and always allocating extra room: ALIGN(NLA_ALIGNTO,
>> NLA_ATTR_ALIGN) (= 4)?
>
> See my explanation above. I think this works. The order does not
> matter, the sum of all padding required will always be the same.
I will do more test.
>
>>> +static bool nla_insufficient_space(struct sk_buff *skb, int attrlen)
>>> +{
>>> + size_t needed = nla_pre_padlen(skb) + nla_total_size(attrlen);
>> If nla_total_size() was right, nla_pre_padlen(skb) should already be
>> included. Am I wrong?
>
> No, nla_pre_padlen() contains the number of bytes needed to align
> skb_tail_pointer() to an alignment of 8. If that is > 0 but the
> attribute to follow is already aligned.
>
> The tricky part here is that accounting for padding in
> nla_total_size() only works for the sum of all attributes.
> It does not account for the specific padding required for the
> previous attribute.
>
> Therefore the above check. The above could be changed to
> nla_attr_size() theoretically as we don't need space for the
> final padding eventually but we checked for space before so I
> kept it that way.
>
> I realize it's slightly confusign and needs better documentation
> and please double check my thinking :-)
Ok, you convince me ;-)
next prev parent reply other threads:[~2012-12-18 22:07 UTC|newest]
Thread overview: 45+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-12-04 11:13 [PATCH net-next 0/7] Allow to monitor multicast cache event via rtnetlink Nicolas Dichtel
2012-12-04 11:13 ` [PATCH net-next 1/7] netconf: advertise mc_forwarding status Nicolas Dichtel
2012-12-04 11:13 ` [PATCH net-next 2/7] ip6mr: use nla_nest_* helpers Nicolas Dichtel
2012-12-04 11:13 ` [PATCH net-next 3/7] ipmr/ip6mr: advertise mfc stats via rtnetlink Nicolas Dichtel
2012-12-04 11:13 ` [PATCH net-next 4/7] ipmr/ip6mr: report origin of mfc entry into rtnl msg Nicolas Dichtel
2012-12-04 11:13 ` [PATCH net-next 5/7] ipmr/ip6mr: allow to get unresolved cache via netlink Nicolas Dichtel
2012-12-04 11:13 ` [PATCH net-next 6/7] ipmr: advertise new mfc entries via rtnl Nicolas Dichtel
2012-12-04 11:13 ` [PATCH net-next 7/7] ip6mr: " Nicolas Dichtel
2012-12-04 18:09 ` [PATCH net-next 0/7] Allow to monitor multicast cache event via rtnetlink David Miller
2012-12-04 20:02 ` Nicolas Dichtel
2012-12-05 11:02 ` Nicolas Dichtel
2012-12-05 11:41 ` David Laight
2012-12-05 17:54 ` David Miller
2012-12-06 8:43 ` Nicolas Dichtel
2012-12-06 17:49 ` Thomas Graf
2012-12-06 21:49 ` Nicolas Dichtel
2012-12-07 10:38 ` David Laight
2012-12-07 10:58 ` Thomas Graf
2012-12-11 15:03 ` Nicolas Dichtel
2012-12-11 18:40 ` Thomas Graf
2012-12-12 17:30 ` Nicolas Dichtel
2012-12-14 13:16 ` [PATCH] netlink: align attributes on 64-bits Nicolas Dichtel
2012-12-14 15:49 ` Ben Hutchings
2012-12-14 16:04 ` Nicolas Dichtel
2012-12-17 16:49 ` [PATCH v2] " Nicolas Dichtel
2012-12-17 17:06 ` David Laight
2012-12-17 17:35 ` Nicolas Dichtel
2012-12-18 9:19 ` David Laight
2012-12-18 10:18 ` Nicolas Dichtel
2012-12-18 12:57 ` Thomas Graf
2012-12-18 16:23 ` Nicolas Dichtel
2012-12-18 16:50 ` David Laight
2012-12-18 17:11 ` Thomas Graf
2012-12-19 9:17 ` David Laight
2012-12-19 17:20 ` Thomas Graf
2012-12-20 9:37 ` David Laight
2012-12-20 9:40 ` David Laight
2012-12-18 17:08 ` Thomas Graf
2012-12-18 22:07 ` Nicolas Dichtel [this message]
2012-12-19 11:22 ` Nicolas Dichtel
2012-12-19 17:09 ` Thomas Graf
2012-12-19 18:07 ` Nicolas Dichtel
2012-12-17 9:59 ` [PATCH] " David Laight
2012-12-17 16:53 ` Nicolas Dichtel
2012-12-05 17:53 ` [PATCH net-next 0/7] Allow to monitor multicast cache event via rtnetlink David Miller
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=50D0E91E.3050702@6wind.com \
--to=nicolas.dichtel@6wind.com \
--cc=David.Laight@ACULAB.COM \
--cc=bhutchings@solarflare.com \
--cc=davem@davemloft.net \
--cc=netdev@vger.kernel.org \
--cc=tgraf@suug.ch \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.