From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-2.8 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id A736CC433EF for ; Wed, 22 Sep 2021 05:29:55 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 81B52611B0 for ; Wed, 22 Sep 2021 05:29:55 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232207AbhIVFbY (ORCPT ); Wed, 22 Sep 2021 01:31:24 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:44054 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232060AbhIVFbX (ORCPT ); Wed, 22 Sep 2021 01:31:23 -0400 Received: from mail-wr1-x431.google.com (mail-wr1-x431.google.com [IPv6:2a00:1450:4864:20::431]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id D137FC061574 for ; Tue, 21 Sep 2021 22:29:53 -0700 (PDT) Received: by mail-wr1-x431.google.com with SMTP id d21so3035458wra.12 for ; Tue, 21 Sep 2021 22:29:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=pFXvTtOISyIVnaTrC4TqcPHAMbH5+YnOEdGA0JAXIJE=; b=JroXW0YEVu64Ao0ORDOGN/OMFaTukX72QGsgj2mNlLguto/OPxzyQ/Bcp7JG0xjLZL laWDKysmG25xml4BP5hKDpJKfPHu60Ork+ewXcabzFB11KtAgLM69YM4ZV88/hnmK1ef g8Dwh9ViLXfnjm/f7Rv3Yqi2JwkDSozr/bvGrzxtebBRdiETxL+8g8+DCERfYE/rAOtS Ipxu4tigTWrP1HvuIeY64DkwKnm5fzyHY7Bds/tJVPVupEEgL10e0S7Ez7ia55HOPcug eyRTrrZ1qSvANFYDe5CiuJO4rHCFb5rpSDswQKYQby9Wl9Wt8MKXXc3rDY49naVH9HWF ZGYw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=pFXvTtOISyIVnaTrC4TqcPHAMbH5+YnOEdGA0JAXIJE=; b=c8iy6Vw2baWtiOkdwmXT7q4UVsl2XITWSP4WFIF1aMhnSQ6hZ/p5Y5nxBZfbNpq+SI pU6ysAXusKjWQhOvFoEtcD5MGIHglKcUbTxN8mwr+yRPhnnA3Lq7sz+nvsNsiFKVtyvb hzxvzXdAM3yoP7dZVWKZVDWjNMfFnOwb8SX+e8rBoBRd1lweRS7Na+rQZ3dt40IsiPWR uxVK8fR0U0NtdtOiSBTihiCunyKOXdTvhm7J8ZtM4Oz9CheZaq1N2skWPRD70cuG2TKY CMj0eAkfKsxUvuKwvEpyU8q+lc4biqRj8Z/PEWU/rGi/6nTAOl8tpMiSVMVKxcPIRcGt ekMQ== X-Gm-Message-State: AOAM53138w/cfOOWGg5BvvAKK3viwa2Sx71NcNHvCg1VnIxAemq6Ckjd mdypSzxNjQTnpsm1/MK1r039vS+0iojp31Ym2AVOJqs2lUg= X-Google-Smtp-Source: ABdhPJzf/8VU+zBL1W4rRrjORT5k3qwfSzrUrvPJ7fYLVS7hbe9hWEQh4xfLZyyMi0E1zWYnzpGRgFLxjUEx/O5HCSc= X-Received: by 2002:a1c:4486:: with SMTP id r128mr8530978wma.8.1632288592493; Tue, 21 Sep 2021 22:29:52 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Xin Long Date: Wed, 22 Sep 2021 13:29:41 +0800 Message-ID: Subject: Re: [PATCH net 2/2] net: sched: also drop dst for the packets toward ingress in act_mirred To: Cong Wang Cc: network dev , David Miller , Jakub Kicinski , Marcelo Ricardo Leitner , Davide Caratti , Hangbin Liu , Jamal Hadi Salim , Jiri Pirko Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: netdev@vger.kernel.org On Wed, Sep 22, 2021 at 11:53 AM Cong Wang wrote: > > On Tue, Sep 21, 2021 at 12:02 AM Xin Long wrote: > > > > On Tue, Sep 21, 2021 at 2:34 AM Cong Wang wrote: > > > > > > On Mon, Sep 20, 2021 at 7:12 AM Xin Long wrote: > > > > > > > > Without dropping dst, the packets sent from local mirred/redirected > > > > to ingress will may still use the old dst. ip_rcv() will drop it as > > > > the old dst is for output and its .input is dst_discard. > > > > > > > > This patch is to fix by also dropping dst for those packets that are > > > > mirred or redirected to ingress in act_mirred. > > > > > > Similar question: what about redirecting from ingress to egress? > > We can do it IF there's any user case needing it. > > But for now, The problem I've met occurred in ip_rcv() for the user case. > > I think input route is different from output route, so essentially we need > a reset when changing the direction, but I don't see any bugs so far, > except this one. Yes, this one seems more reasonable to do this reset when changing the direction. Maybe because in common env, it rarely redirects an egress pkt to ingress by TC. OVS does flow control quite flexibly(complicatedly), when it offloads NAT to TC, this problem starts showing up.