netdev - Re: [ovs-dev] [PATCH net-next v8] net: openvswitch: IPv6: Add IPv6 extension header support

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20220307122638.215427b5@kicinski-fedora-pc1c0hjn.dhcp.thefacebook.com>
Date:   Mon, 7 Mar 2022 12:26:38 -0800
From:   Jakub Kicinski <kuba@...nel.org>
To:     Roi Dayan <roid@...dia.com>
Cc:     Eelco Chaudron <echaudro@...hat.com>,
        patchwork-bot+netdevbpf@...nel.org,
        Toms Atteka <cpp.code.lv@...il.com>, dev@...nvswitch.org,
        netdev@...r.kernel.org, linux-kernel@...r.kernel.org,
        davem@...emloft.net
Subject: Re: [ovs-dev] [PATCH net-next v8] net: openvswitch: IPv6: Add IPv6
 extension header support

On Mon, 7 Mar 2022 10:49:31 +0200 Roi Dayan wrote:
> >> I think there is a missing userspace fix. didnt verify yet.
> >> but in ovs userspace odp-netlink.h created from datapath/linux/compat/include/linux/openvswitch.h
> >> and that file is not synced the change here.
> >> So the new enum OVS_KEY_ATTR_IPV6_EXTHDRS is missing and also struct
> >> ovs_key_ipv6_exthdrs which is needed in lib/udp-util.c
> >> in struct ovs_flow_key_attr_lens to add expected len for
> >> OVS_KEY_ATTR_IPV6_EXTHDR.  
> > 
> > I guess if this is creating backward compatibility issues, this
> > patch should be reverted/fixed. As a kmod upgrade should not break
> > existing deployments. 
> 
> it looks like it does. we can't work with ovs without reverting this.
> can we continue with reverting this commit please?

Sure, can someone ELI5 what the problem is?

What's "kmod upgrade" in this context a kernel upgrade or loading 
a newer module in older kernel? 

How can adding a new nl attr break user space? Does the user space
actually care about the OVS_KEY_ATTR_TUNNEL_INFO wart?