netdev - Re: [PATCH 0/8 net] the indirect flow

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: <8f1a3b9a-6a60-f1b3-0fc1-f2361864c822@solarflare.com>
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