[ovs-discuss] compile problem with 3.13.0-83-generic (was: installing datapath-dkms deb package fails on 3.13.0-83-generic kernel)

Russell Bryant russell at ovn.org
Mon Mar 21 12:56:12 UTC 2016


I believe this is caused by backports done for this bug:

https://bugs.launchpad.net/nova/+bug/1463911

-- 
Russell Bryant

On Mon, Mar 21, 2016 at 5:16 AM, Russell Bryant <russell at ovn.org> wrote:

> FWIW, this issue has broken OpenStack CI with OVN.  It was also reported
> here:
>
> http://openvswitch.org/pipermail/dev/2016-March/067987.html
>
> On Thu, Mar 17, 2016 at 9:27 AM, Ben Pfaff <blp at ovn.org> wrote:
>
>> Hi Zoltán.  It looks like this is really a build problem against a
>> particular kernel instead of anything to do with Debian packaging.  I'm
>> concerned that the kernel developers might skip over it because it
>> sounds packaging-specific, so I'm following up with an updated subject
>> line.
>>
>> On Thu, Mar 17, 2016 at 04:03:54PM +0000, Zoltán Balogh wrote:
>> > Hi,
>> >
>> > Recently, I upgraded to Linux kernel version 3.13.0-83-generic from
>> version 3.13.0-79-generic. Then I rebuilt the debian packages and tried to
>> install them. Installing the datapath-dkms package failed.
>> >
>> > make -C /lib/modules/3.13.0-83-generic/build
>> M=/var/lib/dkms/openvswitch/2.5.0.dpdk2.2/build/datapath/linux modules
>> > make[1]: Entering directory `/usr/src/linux-headers-3.13.0-83-generic'
>> >   CC [M]
>> /var/lib/dkms/openvswitch/2.5.0.dpdk2.2/build/datapath/linux/actions.o
>> > /var/lib/dkms/openvswitch/2.5.0.dpdk2.2/build/datapath/linux/actions.c:
>> In function 'ovs_fragment':
>> >
>> /var/lib/dkms/openvswitch/2.5.0.dpdk2.2/build/datapath/linux/actions.c:730:3:
>> warning: passing argument 1 of 'v6ops->fragment' from incompatible pointer
>> type [enabled by default]
>> >    v6ops->fragment(skb->sk, skb, ovs_vport_output);
>> >    ^
>> >
>> /var/lib/dkms/openvswitch/2.5.0.dpdk2.2/build/datapath/linux/actions.c:730:3:
>> note: expected 'struct sk_buff *' but argument is of type 'struct sock *'
>> >
>> /var/lib/dkms/openvswitch/2.5.0.dpdk2.2/build/datapath/linux/actions.c:730:3:
>> warning: passing argument 2 of 'v6ops->fragment' from incompatible pointer
>> type [enabled by default]
>> >
>> /var/lib/dkms/openvswitch/2.5.0.dpdk2.2/build/datapath/linux/actions.c:730:3:
>> note: expected 'int (*)(struct sk_buff *)' but argument is of type 'struct
>> sk_buff *'
>> >
>> /var/lib/dkms/openvswitch/2.5.0.dpdk2.2/build/datapath/linux/actions.c:730:3:
>> error: too many arguments to function 'v6ops->fragment'
>> > make[2]: ***
>> [/var/lib/dkms/openvswitch/2.5.0.dpdk2.2/build/datapath/linux/actions.o]
>> Error 1
>> > make[1]: ***
>> [_module_/var/lib/dkms/openvswitch/2.5.0.dpdk2.2/build/datapath/linux]
>> Error 2
>> > make[1]: Leaving directory `/usr/src/linux-headers-3.13.0-83-generic'
>> > make: *** [default] Error 2
>> > make: Leaving directory
>> `/var/lib/dkms/openvswitch/2.5.0.dpdk2.2/build/datapath/linux'
>> >
>> > I compared the include/linux/netfilter_ipv6.h files of  the two kernel
>> sources:
>> >
>> > diff
>> /usr/src/linux-headers-3.13.0-83-generic/include/linux/netfilter_ipv6.h
>> /usr/src/linux-headers-3.13.0-79-generic/include/linux/netfilter_ipv6.h
>> > 28d27
>> > <       int (*fragment)(struct sk_buff *skb, int (*output)(struct
>> sk_buff *));
>> >
>> > It seems the new struct member fragment was introduced in nf_ipv6_ops
>> in version 3.13.0-83-general:
>> >
>> > /*
>> >  * Hook functions for ipv6 to allow xt_* modules to be built-in even
>> >  * if IPv6 is a module.
>> >  */
>> > struct nf_ipv6_ops {
>> >       int (*chk_addr)(struct net *net, const struct in6_addr *addr,
>> >                       const struct net_device *dev, int strict);
>> >       int (*fragment)(struct sk_buff *skb, int (*output)(struct sk_buff
>> *));
>> > };
>> >
>> > While the ovs code defines fragment with three arguments in
>> netfilter_ipv6.h and ip6_route.h:
>> >
>> > #ifndef HAVE_NF_IPV6_OPS_FRAGMENT
>> > /* Try to minimise changes required to the actions.c code for calling
>> IPv6
>> >  * fragmentation. We can keep the fragment() API mostly the same,
>> except that
>> >  * the callback parameter needs to be in the form that older kernels
>> accept.
>> >  * We don't backport the other ipv6_ops as they're currently unused by
>> OVS. */
>> > struct ovs_nf_ipv6_ops {
>> >       int (*fragment)(struct sock *sk, struct sk_buff *skb,
>> >                       int (*output)(OVS_VPORT_OUTPUT_PARAMS));
>> > };
>> > #define nf_ipv6_ops ovs_nf_ipv6_ops
>> >
>> > #if defined(OVS_FRAGMENT_BACKPORT)
>> > static struct ovs_nf_ipv6_ops ovs_ipv6_ops = {
>> >       .fragment = ip6_fragment,
>> > };
>> >
>> > static inline struct ovs_nf_ipv6_ops *ovs_nf_get_ipv6_ops(void)
>> > {
>> >       return &ovs_ipv6_ops;
>> > }
>> > #else /* !OVS_FRAGMENT_BACKPORT */
>> > static inline const struct ovs_nf_ipv6_ops *ovs_nf_get_ipv6_ops(void)
>> > {
>> >       return NULL;
>> > }
>> > #endif
>> > #define nf_get_ipv6_ops ovs_nf_get_ipv6_ops
>> >
>> > ---
>> >
>> > #ifndef HAVE_NF_IPV6_OPS_FRAGMENT
>> > #ifdef OVS_FRAGMENT_BACKPORT
>> > int rpl_ip6_fragment(struct sock *sk, struct sk_buff *skb,
>> >                    int (*output)(OVS_VPORT_OUTPUT_PARAMS));
>> > #else
>> > static inline int rpl_ip6_fragment(struct sock *sk, struct sk_buff *skb,
>> >                                  int (*output)(struct sk_buff *))
>> > {
>> >       kfree_skb(skb);
>> >       return -ENOTSUPP;
>> > }
>> > #endif /* OVS_FRAGMENT_BACKPORT */
>> > #define ip6_fragment rpl_ip6_fragment
>> > #endif /* HAVE_NF_IPV6_OPS_FRAGMENT */
>> >
>> > Best regards,
>> > Zoltán
>> >
>> > _______________________________________________
>> > discuss mailing list
>> > discuss at openvswitch.org
>> > http://openvswitch.org/mailman/listinfo/discuss
>> _______________________________________________
>> discuss mailing list
>> discuss at openvswitch.org
>> http://openvswitch.org/mailman/listinfo/discuss
>>
>
>
>
> --
> Russell Bryant
>



-- 
Russell Bryant
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://openvswitch.org/pipermail/ovs-discuss/attachments/20160321/7eb67c02/attachment-0002.html>


More information about the discuss mailing list