[ovs-dev] [PATCH] Allow OVS_USERSPACE_ATTR_USERDATA to be variable length.
jesse at nicira.com
Tue Feb 19 19:04:12 UTC 2013
On Fri, Feb 15, 2013 at 6:20 PM, Ben Pfaff <blp at nicira.com> wrote:
> On Fri, Feb 15, 2013 at 05:36:00PM -0800, Jesse Gross wrote:
>> On Fri, Feb 15, 2013 at 4:48 PM, Ben Pfaff <blp at nicira.com> wrote:
>> > I tested this just now and found a bug: OVS_USERSPACE_ATTR_USERDATA in
>> > the action has to be translated to OVS_PACKET_ATTR_USERDATA in the
>> > kernel->user Netlink message, otherwise it gets interpreted as
>> > OVS_PACKET_ATTR_KEY. So I applied the following incremental:
>> > diff --git a/datapath/datapath.c b/datapath/datapath.c
>> > index bc0b906..0920a30 100644
>> > --- a/datapath/datapath.c
>> > +++ b/datapath/datapath.c
>> > @@ -392,8 +392,9 @@ static int queue_userspace_packet(struct net *net, int dp_ifindex,
>> > nla_nest_end(user_skb, nla);
>> > if (upcall_info->userdata)
>> > - nla_append(user_skb, NLA_ALIGN(upcall_info->userdata->nla_len),
>> > - upcall_info->userdata);
>> > + __nla_put(user_skb, OVS_PACKET_ATTR_USERDATA,
>> > + upcall_info->userdata->nla_len - NLA_HDRLEN,
>> Is there a reason to not use nla_len() here?
> Apologies, I should have put this out for another review cycle, and I
> ordinarily would have except that I really didn't want to leave it
> dangling while I'm off on vacation for a week.
> Please feel free to apply the obvious fix/improvement.
OK, I pushed a patch to do that.
More information about the dev