Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Message-ID: <44eeb550-3310-d579-91cc-ec18b59966d2@nvidia.com>
Date:   Mon, 14 Mar 2022 20:33:09 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:99.0) Gecko/20100101
 Thunderbird/99.0
Subject: Re: [PATCH net-next v2] net: openvswitch: fix uAPI incompatibility
 with existing user space
Content-Language: en-US
To:     Aaron Conole <aconole@redhat.com>,
        Ilya Maximets <i.maximets@ovn.org>
Cc:     Jakub Kicinski <kuba@kernel.org>,
        "David S. Miller" <davem@davemloft.net>,
        Pravin B Shelar <pshelar@ovn.org>,
        Toms Atteka <cpp.code.lv@gmail.com>, netdev@vger.kernel.org,
        dev@openvswitch.org, linux-kernel@vger.kernel.org,
        Johannes Berg <johannes@sipsolutions.net>,
        Maor Dickman <maord@nvidia.com>
References: <20220309222033.3018976-1-i.maximets@ovn.org>
 <f7ty21hir5v.fsf@redhat.com>
From:   Roi Dayan <roid@nvidia.com>
In-Reply-To: <f7ty21hir5v.fsf@redhat.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
MIME-Version: 1.0
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?amlzZE1mdGFHQlhNYzMwOHlkVm11ZFhDMkdEZFordWFVR2UxcVJEWmIwWG1B?=
 =?utf-8?B?ZXFVaW1vd0FvM3piS3dmaGtHNkhaZkxFQml3VGtkclVUaEVlaDJLT3FWM1E0?=
 =?utf-8?B?cDcvdHJNVTlaZzRpTHM5SFpBQnpXZnVUTHBkYWtPUkVpQUtmaFoyeXJ3MXlt?=
 =?utf-8?B?MWcwTGNhT0VLRWV2RGhOZ0g1bWwzVXBnR2NQYVJpK3l5VzA2QkdaeHJBb1pR?=
 =?utf-8?B?Qmo5SFVqdElqZmNXSnhleVJaNEk0M2ZrK0dONGxySnRSazdzL3EyQVdieHZC?=
 =?utf-8?B?dGpESi9NaUNUSFhQMmpmcThrL2JKeW9ieSt3LzVkYXVtS1A5Z0NEYkhYNXFZ?=
 =?utf-8?B?ZzAyOE1uV1U4MS9IdWRpcTRxNHVvaDZmLzJRZ0Z0ZW41OU5Vemc3NU5udU5V?=
 =?utf-8?B?cTVSSHZIR1U4cS92WmpiV0p0c1FmMStaVUV5MURVQW5jSEJQeG1ldXNGbUtZ?=
 =?utf-8?B?Y3A0ZE5hK2F1R091UkRPOWZrUkpEOFZETW81bzFHakVXWmtuOFpTTWROQnlu?=
 =?utf-8?B?dytERHZCeGdyY3ZpU1NnMjh4b1NYSWhqMDhyMEJpTUEvSWJET01DcTJkYVgz?=
 =?utf-8?B?ZzRNUGs2dmVqZ05QNDA2QUxERjVpZ2RUbDFGRUdkMC9nSzFOZDlZU3NVcEo0?=
 =?utf-8?B?SGdqeW55c2F5cXJDOWgvRjdpNXJId3dJbkttcVRGOFB1ZWVMNkVkWU1tVFJp?=
 =?utf-8?B?djVyK1RPTUk4SHM2Z1VkWFdLRUdhRXJIVXpXYkZrUXZoTWw1enJKeDB0QS94?=
 =?utf-8?B?eUVseEdpSVRhNEVZek9oOHNGc1h5Ty9BQzNFQmE4TitTa3NCV0R6aEp3VkRw?=
 =?utf-8?B?cW8wWVlhTm1yTHVmUW5ldWVYWlFQVDBqUTNheFF4NzdnU2xydlE5WHJwaE9x?=
 =?utf-8?B?UmptMGMwMHM1MG5Ycm9zVWN3OUR6c3BQeXU0TUZtM1pocG1vVVA2OEZkZ2hU?=
 =?utf-8?B?c21tRjRzQTdpK0g2aDZCNlhwb2xySnpLWEQ3cGpZa3pHYmpaYXFBUGpLd0VS?=
 =?utf-8?B?MWxyQUJjdm9YNnNjaUZMK3NLWUpQUnovcjVqdUZSUnRRaDAvbHFGNDZ3cStG?=
 =?utf-8?B?dGc1YTZvbk5pSnNIT0xhSEZBdWRMbytaYXVqMEtmRVVpWEtCaFFPNWtJYzJT?=
 =?utf-8?B?ODF6QWFTYnBYZEdwOEZlc2VianNaT015c2haOXo3bVRWdXc1LzBqNWZydjkz?=
 =?utf-8?B?ZlJPYzhmT1lPcUNyc3R2NmhXTmh3TmtTT0YrOUdKTmZNbjh4a1VKWlJ0SHoz?=
 =?utf-8?B?S09HV0lEbXorOHZ1YWFnN0JKWkpFQ3A3VzZxRk9xQm0ySitIQVVNdjlmc1g2?=
 =?utf-8?B?UXVjRHlSUTdIQ2RDN0tCVDdwUUJvU0N5RCtVd2xuR1g3dEhPOEZNc3pmSUw0?=
 =?utf-8?B?YktVWVZoR1AwZHVFT0pXWE9tc0ZEVUVWQXpNSUVnV3dxYjJkcTR6ejdGazJn?=
 =?utf-8?B?dUdWMzNhZGU3K0haNEJCUUVZTDMxRWFGOVgzV1pxTDNhUzRNQ1FLODJxSUdW?=
 =?utf-8?B?L3FJQ3VEWVlOTUQvT2xtSHh4YnJtQVpMbVJHbkphbTByRWpjbG0vV3FnR2E2?=
 =?utf-8?B?Tmk5UldJYzNaU2xaeC9XQzlrMHJBcDlOVXozNHlvWmM2d2gyMGU3RDB5K1VQ?=
 =?utf-8?B?SEI5OUY5SERmMWJWU0hwVHBXMmh0UnVsS1l3Ykd6TFBXWkkxMllranBZYnZp?=
 =?utf-8?B?Lytod0RlaUcrdnUwdjMzMzAvRTRnMjM5VXg2czI5TUhWK05BSXBvaExoaWp1?=
 =?utf-8?B?aXZUQm9zYWs2MHQwRndDN1lTcWhMdjN1SzFqYXAxZXNyTEIzM1ZJdG5JQWZD?=
 =?utf-8?B?MWJtMlZ2alBjK2VJRmxhZnUvVG9ldVNBTStud3hReGtYRkRQOEV5NGZGbk1N?=
 =?utf-8?B?RnZCa3daMkFTL2lzVWJ1dUt1U3JmcGIvc0VaeGx4eFl0Y09zQ1FRWUpidXps?=
 =?utf-8?Q?PIyecXuXYav7yfEUJxdKTzV6sQzT9fg+?=
X-OriginatorOrg: Nvidia.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 36e51c2d-4633-44eb-5c2f-08da05e91b06
X-MS-Exchange-CrossTenant-AuthSource: CH0PR12MB5330.namprd12.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 14 Mar 2022 18:33:17.1528
 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: 43083d15-7273-40c1-b7db-39efd9ccc17a
X-MS-Exchange-CrossTenant-MailboxType: HOSTED
X-MS-Exchange-CrossTenant-UserPrincipalName: oGU2ZzvECreoC3VT+/KqsFLSeeipHFMQrWLO/6QnkII7U3GsVXZulJPdB3A9Md8b
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR12MB4153
X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH,
        DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FORGED_SPF_HELO,
        NICE_REPLY_A,RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H2,SPF_HELO_PASS,
        SPF_NONE,T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no
        version=3.4.6
X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on
        lindbergh.monkeyblade.net
Precedence: bulk
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org


On 2022-03-10 8:44 PM, Aaron Conole wrote:
> Ilya Maximets <i.maximets@ovn.org> writes:
> 
>> Few years ago OVS user space made a strange choice in the commit [1]
>> to define types only valid for the user space inside the copy of a
>> kernel uAPI header.  '#ifndef __KERNEL__' and another attribute was
>> added later.
>>
>> This leads to the inevitable clash between user space and kernel types
>> when the kernel uAPI is extended.  The issue was unveiled with the
>> addition of a new type for IPv6 extension header in kernel uAPI.
>>
>> When kernel provides the OVS_KEY_ATTR_IPV6_EXTHDRS attribute to the
>> older user space application, application tries to parse it as
>> OVS_KEY_ATTR_PACKET_TYPE and discards the whole netlink message as
>> malformed.  Since OVS_KEY_ATTR_IPV6_EXTHDRS is supplied along with
>> every IPv6 packet that goes to the user space, IPv6 support is fully
>> broken.
>>
>> Fixing that by bringing these user space attributes to the kernel
>> uAPI to avoid the clash.  Strictly speaking this is not the problem
>> of the kernel uAPI, but changing it is the only way to avoid breakage
>> of the older user space applications at this point.
>>
>> These 2 types are explicitly rejected now since they should not be
>> passed to the kernel.  Additionally, OVS_KEY_ATTR_TUNNEL_INFO moved
>> out from the '#ifdef __KERNEL__' as there is no good reason to hide
>> it from the userspace.  And it's also explicitly rejected now, because
>> it's for in-kernel use only.
>>
>> Comments with warnings were added to avoid the problem coming back.
>>
>> (1 << type) converted to (1ULL << type) to avoid integer overflow on
>> OVS_KEY_ATTR_IPV6_EXTHDRS, since it equals 32 now.
>>
>>   [1] beb75a40fdc2 ("userspace: Switching of L3 packets in L2 pipeline")
>>
>> Fixes: 28a3f0601727 ("net: openvswitch: IPv6: Add IPv6 extension header support")
>> Link: https://lore.kernel.org/netdev/3adf00c7-fe65-3ef4-b6d7-6d8a0cad8a5f@nvidia.com
>> Link: https://github.com/openvswitch/ovs/commit/beb75a40fdc295bfd6521b0068b4cd12f6de507c
>> Reported-by: Roi Dayan <roid@nvidia.com>
>> Signed-off-by: Ilya Maximets <i.maximets@ovn.org>
>> ---
> 
> Acked-by: Aaron Conole <aconole@redhat.com>
> 


I got to check traffic with the fix and I do get some traffic
but something is broken. I didn't investigate much but the quick
test shows me rules are not offloaded and dumping ovs rules gives
error like this

recirc_id(0),in_port(enp8s0f0_1),ct_state(-trk),eth(),eth_type(0x86dd),ipv6(frag=no)(bad 
key length 2, expected -1)(00 00/(bad mask length 2, expected -1)(00 
00), packets:2453, bytes:211594, used:0.004s, flags:S., 
actions:ct,recirc(0x2)