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: <CAJ3xEMjrLgJspjY-Aqd68GzWMrFuHHiAOjoazi9p1T8BhuPP=w@mail.gmail.com>
Date:   Sun, 27 Jan 2019 18:39:51 +0200
From:   Or Gerlitz <gerlitz.or@...il.com>
To:     Tonghao Zhang <xiangxia.m.yue@...il.com>
Cc:     Saeed Mahameed <saeedm@...lanox.com>,
        Linux Netdev List <netdev@...r.kernel.org>,
        Or Gerlitz <ogerlitz@...lanox.com>
Subject: Re: [PATCH net v4 2/2] net/mlx5e: Don't overwrite pedit action when
 multiple pedit used

On Sun, Jan 27, 2019 at 1:06 PM <xiangxia.m.yue@...il.com> wrote:
> From: Tonghao Zhang <xiangxia.m.yue@...il.com>
>
> In some case, we may use multiple pedit actions to modify packets.
> The command shown as below: the last pedit action is effective.

> @@ -2073,7 +2076,8 @@ static int alloc_mod_hdr_actions(struct mlx5e_priv *priv,
>         if (!parse_attr->mod_hdr_actions)
>                 return -ENOMEM;
>
> -       parse_attr->num_mod_hdr_actions = max_actions;
> +       parse_attr->max_mod_hdr_actions = max_actions;
> +       parse_attr->num_mod_hdr_actions = 0;

why would we want to do this zeroing? what purpose does it serve?

On a probably related note, I suspect that the patch broke the caching
we do for modify header contexts, see mlx5e_attach_mod_hdr where we
look if a given set of modify header operations already has hw modify header
context and we use it.

To test that, put two tc rules with different matching but same set of
modify header
(pedit) actions and see that only one modify header context is used.

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ