[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20200514223627.GA3170@salvia>
Date: Fri, 15 May 2020 00:36:27 +0200
From: Pablo Neira Ayuso <pablo@...filter.org>
To: Edward Cree <ecree@...arflare.com>
Cc: netfilter-devel@...r.kernel.org, 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 Thu, May 14, 2020 at 12:44:48PM +0100, Edward Cree wrote:
> 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?
The TC CT action crashes the kernel with an indirect flow_block in place:
https://lore.kernel.org/netfilter-devel/db9dfe4f-62e7-241b-46a0-d878c89696a8@ucloud.cn/
Powered by blists - more mailing lists