From patchwork Thu Jul 20 16:13:29 2023 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Richard Gobert X-Patchwork-Id: 12354 Return-Path: Delivered-To: ouuuleilei@gmail.com Received: by 2002:a59:c923:0:b0:3e4:2afc:c1 with SMTP id j3csp3253592vqt; Thu, 20 Jul 2023 09:56:40 -0700 (PDT) X-Google-Smtp-Source: APBJJlHFwRTScjl/fA0jPQgfnskXbj+w7R74UJcm03MuO/FM8newYxTF6G5gjOJlqVU/AzXQE8/s X-Received: by 2002:aa7:dccf:0:b0:521:a973:a82c with SMTP id w15-20020aa7dccf000000b00521a973a82cmr2421797edu.30.1689872200150; Thu, 20 Jul 2023 09:56:40 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1689872200; cv=none; d=google.com; s=arc-20160816; b=uTb/YjbMmHBaIF3cYRlzEDKVmv+6qtu5J6pDrBg7+WDVvoQUGvwaD5lH5UvrBgtVcF XNwnSuWTqNdtfDkEUEh6414lkz38E5oebnvLDqzZDcI9HqubJXKLbpoLym849kUX9+Zy bPnBfoAUNZPS+5nlLKmumOp3W9YOinHt2EOy/VmuIue+RFKLGXs8XW17yaxOOgojShTC hxLxWHhd4TJ0e7xP0eOeY6ca36h+613oi0DGdQhg1X5TtBxTMmfI+c70A9t5SMTjUYIw sGKs8VBWBkeWQX6389ZnrsMAl+YzKcPCHJSV+lFpQp2bld9AC4vCWPuv0UYTizjyBXEI sZxQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:user-agent:content-disposition:mime-version :message-id:subject:to:from:date:dkim-signature; bh=KT5zlUFLt+9ArlY0df84sUttPCw70QBkOyPQwBnF6co=; fh=NfPdGD6Y/fUukMnDQdv+EWH4vc0MgRZIMcW8czEW4Rs=; b=bVmCBolh3df2pSOT/35fFq3Dz7/zL5wdHjMiN5TSiEmIq5KSDvPoSq8sJcnfLZyiG5 jTafWaTHo3h5tEjYdVXqphIQ+a+LRQE2lb0RBJZaSzyueNDoJPAOSzG14s5FxCI35J/u Gz+8L0MkuvI6IjqyEdspqFZT3Ag7Y41z9Q7D1yThOozDoDSUTv6RAK9VPuWKjGdBvXtz bhD5XSK4qxHdSxFKxhCty1sEmMEFMA63d3KA0mOc8msrVMNlMGAaPl+wL8QO+Ars9V7o 09MOQd/G8oEZ6zhGBhWBwFQJ51jkZ7vOpBcvqjbqNG9SdPC+N8KOvex2ZB82df7MPnE7 BXPQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20221208 header.b=oHa7mMa9; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id q17-20020a056402033100b0051e029c13efsi988923edw.365.2023.07.20.09.56.16; Thu, 20 Jul 2023 09:56:40 -0700 (PDT) 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; Authentication-Results: mx.google.com; dkim=pass header.i=@gmail.com header.s=20221208 header.b=oHa7mMa9; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229707AbjGTQNt (ORCPT + 99 others); Thu, 20 Jul 2023 12:13:49 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:45116 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229451AbjGTQNs (ORCPT ); Thu, 20 Jul 2023 12:13:48 -0400 Received: from mail-wm1-x334.google.com (mail-wm1-x334.google.com [IPv6:2a00:1450:4864:20::334]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 71E7A114; Thu, 20 Jul 2023 09:13:47 -0700 (PDT) Received: by mail-wm1-x334.google.com with SMTP id 5b1f17b1804b1-3fbc5d5742eso8626145e9.3; Thu, 20 Jul 2023 09:13:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1689869626; x=1690474426; h=user-agent:content-disposition:mime-version:message-id:subject:to :from:date:from:to:cc:subject:date:message-id:reply-to; bh=KT5zlUFLt+9ArlY0df84sUttPCw70QBkOyPQwBnF6co=; b=oHa7mMa9P/+axKz8/wBwndBn2idcqf9865ECO1Cwbyboc/4T21mBVyI8Z9z+jJUip4 IK/2ADlZDTDyI+uTVrxosfkJW+mlEZwMnraDmi8h10mkhj4v8F71Dr0m01PfAEB4nDnT SNGrsAyCroCQveWWC60g9tvPL1uqTqcauYPktSqU81QMjMWSUtO9enUvCBQL9lqK4PtS YzZhO5qB0Sr61J9OueuS6o40OrQoI2TMzQO8RDXTyxXtSs3xOfPVCTtD5FrFrCUMYeLU N9QCbLIXoyuWPbtIVDqkvucEeEsS8ukpHBHJZqncQGVC2G9wIoAgOyvmi9SeiQD+U8yM yO8g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1689869626; x=1690474426; h=user-agent:content-disposition:mime-version:message-id:subject:to :from:date:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=KT5zlUFLt+9ArlY0df84sUttPCw70QBkOyPQwBnF6co=; b=Cbx19XRT24XT/ch0+nmayIs4Hs6/n1K3SCwBsvGSkFQ/OGUeFHv05B5GyI9F45T44l Bze6qwgrj7uIWRHt8fp2njihe0oRAtUBRQRJ3gi4RKRg99qT2oLvTru9c91tvvQ1PYgj hy/IUDt/S3dWrX9LUiqCvCJXdOATegW67k1pud3MDZK0DttAyBQx4zuuN8ismWZzncBR WXncUU4NKmwM3aKSbglOP4Ln58hEqibUCsVU6u37qcod1gzWji5fhe2aOT5lLEVkO4Mi 2lJnXgpx3wDIhxruFLoLCARAs27/G0Zss9zv5KU0XRKU7DuYsz8uZupRgBMU5W4RI4j2 n2rA== X-Gm-Message-State: ABy/qLYLiyMU4Cz2zlpP2jtXahGj2wfXixaX1hq//cqZQbVP4HlWfiC2 7ScP8W19PQkkLiANZqYZK0c= X-Received: by 2002:adf:e404:0:b0:313:f4e2:901d with SMTP id g4-20020adfe404000000b00313f4e2901dmr2090525wrm.22.1689869625717; Thu, 20 Jul 2023 09:13:45 -0700 (PDT) Received: from debian ([89.238.191.199]) by smtp.gmail.com with ESMTPSA id t15-20020a5d49cf000000b003143765e207sm1746892wrs.49.2023.07.20.09.13.38 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 20 Jul 2023 09:13:45 -0700 (PDT) Date: Thu, 20 Jul 2023 18:13:29 +0200 From: Richard Gobert To: davem@davemloft.net, edumazet@google.com, kuba@kernel.org, pabeni@redhat.com, willemdebruijn.kernel@gmail.com, dsahern@kernel.org, tom@herbertland.com, netdev@vger.kernel.org, linux-kernel@vger.kernel.org, gal@nvidia.com Subject: [PATCH v2 0/1] net: gro: fix misuse of CB in udp socket lookup Message-ID: <20230720161322.GA16323@debian> MIME-Version: 1.0 Content-Disposition: inline User-Agent: Mutt/1.10.1 (2018-07-13) X-Spam-Status: No, score=-2.1 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM, RCVD_IN_DNSWL_BLOCKED,SPF_HELO_NONE,SPF_PASS,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: X-Mailing-List: linux-kernel@vger.kernel.org X-getmail-retrieved-from-mailbox: INBOX X-GMAIL-THRID: 1771958066009597304 X-GMAIL-MSGID: 1771959432148956064 GRO stack uses `udp_lib_lookup_skb` which relies on IP/IPv6 CB's info, and at the GRO stage, CB holds `napi_gro_cb` info. Specifically, `udp_lib_lookup_skb` tries to fetch `iff` and `flags` information from the CB, to find the relevant udp tunnel socket (GENEVE/VXLAN/..). Up until a patch I submitted recently [0], it worked merely by luck, due to the layouts of `napi_gro_cb` and IP6CB. AFAIU it worked because: `IP6CB(skb)->flags` is at offset 16 inside IP6CB: - Before the patch: `flags` was mapped to `flush`. - After the patch: `flags` was mapped to `data_offset`. `IP6CB(skb)->iff` is at offset 0 inside IP6CB: - Before the patch: `iif` was mapped to `frag0`. - After the patch: `iif` was mapped to a union of `frag0` and `last`. After my patch, on the receive phase, while `data_offset` is 40 (since IPv6 header is 40 bytes), `inet_iif` calls `ipv6_l3mdev_skb`, which checks whether `IP6CB(skb)->flags`'s `IP6SKB_L3SLAVE` bit is on or off (in our case its off). If it is off, `inet_iif` returns `IP6CB(skb)->iif`, which is mapped to `napi_gro_cb->frag0`, making `inet_iif` return 0 most of the times. `inet_sdif` returns zero due to a similar reason caused by `data_offset` being equal to 40 (and less than 64). On the other hand, the complete phase behaves differently. `data_offset` is usually greater than 64 and less than 128 so the `IP6SKB_L3SLAVE` flag is on. Thus, `inet_sdif` returns `IP6CB(skb)->iif`, which is mapped to `last` which contains a pointer. This causes `udp_sk_bound_dev_eq` to fail, which leads to `udp6_lib_lookup2` failing and not returning a socket. This leads the receive phase of GRO to find the right socket, and on the complete phase, it fails to find it and makes the throughput go down to nearly zero. Before [0] `flags` was mapped to `flush`. `flush`'s possible values were 1 and 0, making `inet6_iff` always returning `skb->skb_iif` and `inet6_sdif` returning 0, and leading to `udp_sk_bound_dev_eq` returning true. A fix is to not rely on CB, and get `iff` and `sdif` using skb->dev. l3mdev case requires special attention since it has a master and a slave device. [0] https://lore.kernel.org/netdev/20230601160924.GA9194@debian/ Changelog: v1 -> v2: * make functions inline * fix logical bug * add a comment when we can use the new functions * checkpatch fixes Richard Gobert (1): net: gro: fix misuse of CB in udp socket lookup include/net/udp.h | 2 ++ net/ipv4/udp.c | 28 ++++++++++++++++++++++++++-- net/ipv4/udp_offload.c | 7 +++++-- net/ipv6/udp.c | 29 +++++++++++++++++++++++++++-- net/ipv6/udp_offload.c | 7 +++++-- 5 files changed, 65 insertions(+), 8 deletions(-)