Netdev List
 help / color / mirror / Atom feed
From: Pablo Neira Ayuso <pablo@netfilter.org>
To: Jakub Kicinski <kuba@kernel.org>
Cc: netfilter-devel@vger.kernel.org, davem@davemloft.net,
	netdev@vger.kernel.org, pabeni@redhat.com, edumazet@google.com
Subject: Re: [PATCH net 7/7] netfilter: nf_tables: bail out early if hardware offload is not supported
Date: Wed, 8 Jun 2022 08:03:00 +0200	[thread overview]
Message-ID: <YqA7lOw8CKNMaQ28@salvia> (raw)
In-Reply-To: <20220607180025.6bd26267@kernel.org>

Hi Jakub,

On Tue, Jun 07, 2022 at 06:00:25PM -0700, Jakub Kicinski wrote:
> On Mon,  6 Jun 2022 23:20:55 +0200 Pablo Neira Ayuso wrote:
> > If user requests for NFT_CHAIN_HW_OFFLOAD, then check if either device
> > provides the .ndo_setup_tc interface or there is an indirect flow block
> > that has been registered. Otherwise, bail out early from the preparation
> > phase. Moreover, validate that family == NFPROTO_NETDEV and hook is
> > NF_NETDEV_INGRESS.
> 
> The whole series is pretty light on the "why".

  - [net,1/7] netfilter: nat: really support inet nat without l3 address
    https://git.kernel.org/netdev/net/c/282e5f8fe907

  This is a fix, otherwise NAT with the inet family (which allows both
  IPv4 and IPv6 traffic) remains broken. It's a datapath fix, the
  control plane was accepting the rule, however NAT was not applied if
  user specified no layer 4 address, which might happen for, eg. redirect.

  - [net,2/7] netfilter: nf_tables: use kfree_rcu(ptr, rcu) to release hooks in clean_net path
    https://git.kernel.org/netdev/net/c/ab5e5c062f67

  This is an incremental fix for f9a43007d3f7 ("netfilter: nf_tables:
  double hook unregistration in netns path"), it is using kfree_rcu(ptr)
  variant which works but it has some limitations. Use of free_rcu(ptr)
  was not intentional, hence free_rcu(ptr, rcu)

  - [net,3/7] netfilter: nf_tables: delete flowtable hooks via transaction list
    https://git.kernel.org/netdev/net/c/b6d9014a3335

  Deleting twice the same device on the flowtable might lead to ENOENT
  since hook->inactive is not honored. Instead of honoring such flag,
  this patch is fixing up this by using a flowtable hook list in the
  transaction object to convey the hook that are going to be deleted
  which looks cleaner to me.

  - [net,4/7] netfilter: nf_tables: always initialize flowtable hook list in transaction
    https://git.kernel.org/netdev/net/c/2c9e4559773c

  This is a oneliner, not urgent but Florian already reported in the
  past that the flowtable hook list in the transaction object was not
  initialized (even if not used). This patch initializes it to
  increase robustness, this list is going to be empty/unused for the
  non-update path anyway. Arguably I could have postpone this
  oneliner.

  - [net,5/7] netfilter: nf_tables: release new hooks on unsupported flowtable flags
    https://git.kernel.org/netdev/net/c/c271cc9febaa

  This is a fix. nft_flowtable_parse_hook() populates the hook list,
  but the flowtable flags update logic was not releasing these objects
  from the error path, hence, leading to a memleak.

  - [net,6/7] netfilter: nf_tables: memleak flow rule from commit path
    https://git.kernel.org/netdev/net/c/9dd732e0bdf5

  kmemleak reported this memleak while running a series of test with
  nf_tables hardware offload support for these objects, this is a fix.

> This patch is particularly bad, no idea what the user visible bug
> was here.

  Are you refering to this?

  - [net,7/7] netfilter: nf_tables: bail out early if hardware offload is not supported
    https://git.kernel.org/netdev/net/c/3a41c64d9c11

  Arguably, I could have postponed this patch, but quite recently
  there was a silly bug in the hardware offload infrastructure, see
  b1a5983f56e3 ("netfilter: nf_tables_offload: incorrect flow offload
  action array size. The reporter triggered the bug with the _loopback
  interface_, he wondered why this infrastructure is exposed to all
  devices while only a dozen of NICs support hardware offload, hence
  this patch to disable hardware offload earlier in the control plane
  path.

      reply	other threads:[~2022-06-08  7:29 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-06-06 21:20 [PATCH net 0/7] Netfilter fixes for net Pablo Neira Ayuso
2022-06-06 21:20 ` [PATCH net 1/7] netfilter: nat: really support inet nat without l3 address Pablo Neira Ayuso
2022-06-08  1:20   ` patchwork-bot+netdevbpf
2022-06-06 21:20 ` [PATCH net 2/7] netfilter: nf_tables: use kfree_rcu(ptr, rcu) to release hooks in clean_net path Pablo Neira Ayuso
2022-06-06 21:20 ` [PATCH net 3/7] netfilter: nf_tables: delete flowtable hooks via transaction list Pablo Neira Ayuso
2022-06-06 21:20 ` [PATCH net 4/7] netfilter: nf_tables: always initialize flowtable hook list in transaction Pablo Neira Ayuso
2022-06-06 21:20 ` [PATCH net 5/7] netfilter: nf_tables: release new hooks on unsupported flowtable flags Pablo Neira Ayuso
2022-06-06 21:20 ` [PATCH net 6/7] netfilter: nf_tables: memleak flow rule from commit path Pablo Neira Ayuso
2022-06-06 21:20 ` [PATCH net 7/7] netfilter: nf_tables: bail out early if hardware offload is not supported Pablo Neira Ayuso
2022-06-08  1:00   ` Jakub Kicinski
2022-06-08  6:03     ` Pablo Neira Ayuso [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=YqA7lOw8CKNMaQ28@salvia \
    --to=pablo@netfilter.org \
    --cc=davem@davemloft.net \
    --cc=edumazet@google.com \
    --cc=kuba@kernel.org \
    --cc=netdev@vger.kernel.org \
    --cc=netfilter-devel@vger.kernel.org \
    --cc=pabeni@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox