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  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:   Thu, 14 May 2020 12:44:48 +0100
From:   Edward Cree <ecree@...arflare.com>
To:     Pablo Neira Ayuso <pablo@...filter.org>,
        <netfilter-devel@...r.kernel.org>
CC:     <davem@...emloft.net>, <netdev@...r.kernel.org>,
        <paulb@...lanox.com>, <ozsh@...lanox.com>, <vladbu@...lanox.com>,
        <jiri@...nulli.us>, <kuba@...nel.org>, <saeedm@...lanox.com>,
        <michael.chan@...adcom.com>
Subject: Re: [PATCH 0/8 net] the indirect flow_block offload, revisited

On 13/05/2020 17:41, Pablo Neira Ayuso wrote:
> Hi,
>
> This patchset fixes the indirect flow_block support for the tc CT action
> offload. Please, note that this batch is probably slightly large for the
> net tree, however, I could not find a simple incremental fix.
>
> = The problem
>
> The nf_flow_table_indr_block_cb() function provides the tunnel netdevice
> and the indirect flow_block driver callback. From this tunnel netdevice,
> it is not possible to obtain the tc CT flow_block. Note that tc qdisc
> and netfilter backtrack from the tunnel netdevice to the tc block /
> netfilter chain to reach the flow_block object. This allows them to
> clean up the hardware offload rules if the tunnel device is removed.
>
> <snip>
>
> = About this patchset
>
> This patchset aims to address the existing TC CT problem while
> simplifying the indirect flow_block infrastructure. Saving 300 LoC in
> the flow_offload core and the drivers.
This might be a dumb question, but: what is the actual bug being fixed,
 that makes this patch series needed on net rather than net-next?
>From your description it sounds like a good and useful cleanup/refactor,
 but nonetheless still a clean-up, appropriate for net-next.

-ed

Powered by blists - more mailing lists