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]
Date:   Tue, 21 Sep 2021 15:01:48 +0800
From:   Xin Long <lucien.xin@...il.com>
To:     Cong Wang <xiyou.wangcong@...il.com>
Cc:     network dev <netdev@...r.kernel.org>,
        David Miller <davem@...emloft.net>,
        Jakub Kicinski <kuba@...nel.org>,
        Marcelo Ricardo Leitner <marcelo.leitner@...il.com>,
        Davide Caratti <dcaratti@...hat.com>,
        Hangbin Liu <liuhangbin@...il.com>,
        Jiri Pirko <jiri@...nulli.us>,
        Jamal Hadi Salim <jhs@...atatu.com>
Subject: Re: [PATCH net 1/2] net: sched: drop ct for the packets toward
 ingress only in act_mirred

On Tue, Sep 21, 2021 at 2:31 AM Cong Wang <xiyou.wangcong@...il.com> wrote:
>
> On Mon, Sep 20, 2021 at 7:12 AM Xin Long <lucien.xin@...il.com> wrote:
> >
> > nf_reset_ct() called in tcf_mirred_act() is supposed to drop ct for
> > those packets that are mirred or redirected to only ingress, not
> > ingress and egress.
>
> Any reason behind this? I think we at least need to reset it when
> redirecting from ingress to egress as well? That is, when changing
> directions?
For the reason why ct should be reset, it's said in
d09c548dbf3b ("net: sched: act_mirred: Reset ct info when mirror").
The user case is OVS HWOL using TC to do NAT and then redirecting
the NATed skb back to the ingress of one local dev, it's ingress only, this
patch is more like to minimize the side effect of d09c548dbf3b IF there is.

Not sure if it's too much to do for that from ingress to egress.
What I was thinking is this should happen on rx path(ingress), like it
does in internal_dev_recv() in the OVS kernel module. But IF there is
any user case needing doing this for ingress to egress, I would add it.

>
> Thanks.

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ