netdev - Re: [PATCH net-next,v4 08/12] drivers: net: use flow block API

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: <20190710080123.GE2282@nanopsycho>
Date:   Wed, 10 Jul 2019 10:01:23 +0200
From:   Jiri Pirko <jiri@...nulli.us>
To:     Pablo Neira Ayuso <pablo@...filter.org>
Cc:     netdev@...r.kernel.org, davem@...emloft.net,
        thomas.lendacky@....com, f.fainelli@...il.com,
        ariel.elior@...ium.com, michael.chan@...adcom.com,
        madalin.bucur@....com, yisen.zhuang@...wei.com,
        salil.mehta@...wei.com, jeffrey.t.kirsher@...el.com,
        tariqt@...lanox.com, saeedm@...lanox.com, jiri@...lanox.com,
        idosch@...lanox.com, jakub.kicinski@...ronome.com,
        peppe.cavallaro@...com, grygorii.strashko@...com, andrew@...n.ch,
        vivien.didelot@...il.com, alexandre.torgue@...com,
        joabreu@...opsys.com, linux-net-drivers@...arflare.com,
        ogerlitz@...lanox.com, Manish.Chopra@...ium.com,
        marcelo.leitner@...il.com, mkubecek@...e.cz,
        venkatkumar.duvvuru@...adcom.com, maxime.chevallier@...tlin.com,
        cphealy@...il.com, phil@....cc, netfilter-devel@...r.kernel.org
Subject: Re: [PATCH net-next,v4 08/12] drivers: net: use flow block API

Tue, Jul 09, 2019 at 10:55:46PM CEST, pablo@...filter.org wrote:

[...]	
	
> static int
> mlxsw_sp_setup_tc_block_flower_bind(struct mlxsw_sp_port *mlxsw_sp_port,
>-				    struct tcf_block *block, bool ingress,
>-				    struct netlink_ext_ack *extack)
>+			            struct flow_block_offload *f, bool ingress)
> {
> 	struct mlxsw_sp *mlxsw_sp = mlxsw_sp_port->mlxsw_sp;
> 	struct mlxsw_sp_acl_block *acl_block;
>-	struct tcf_block_cb *block_cb;
>+	struct flow_block_cb *block_cb;
>+	bool register_block = false;
> 	int err;
> 
>-	block_cb = tcf_block_cb_lookup(block, mlxsw_sp_setup_tc_block_cb_flower,
>-				       mlxsw_sp);
>+	block_cb = flow_block_cb_lookup(f, mlxsw_sp_setup_tc_block_cb_flower,
>+					mlxsw_sp);
> 	if (!block_cb) {
>-		acl_block = mlxsw_sp_acl_block_create(mlxsw_sp, block->net);
>+		acl_block = mlxsw_sp_acl_block_create(mlxsw_sp, f->net);
> 		if (!acl_block)
> 			return -ENOMEM;
>-		block_cb = __tcf_block_cb_register(block,
>-						   mlxsw_sp_setup_tc_block_cb_flower,
>-						   mlxsw_sp, acl_block, extack);
>+		block_cb = flow_block_cb_alloc(f->net,
>+					       mlxsw_sp_setup_tc_block_cb_flower,
>+					       mlxsw_sp, acl_block,
>+					       mlxsw_sp_tc_block_flower_release);
> 		if (IS_ERR(block_cb)) {
>+			mlxsw_sp_acl_block_destroy(acl_block);
> 			err = PTR_ERR(block_cb);
> 			goto err_cb_register;
> 		}
>+		register_block = true;
> 	} else {
>-		acl_block = tcf_block_cb_priv(block_cb);
>+		acl_block = flow_block_cb_priv(block_cb);
> 	}
>-	tcf_block_cb_incref(block_cb);
>+	flow_block_cb_incref(block_cb);
> 	err = mlxsw_sp_acl_block_bind(mlxsw_sp, acl_block,
> 				      mlxsw_sp_port, ingress);
> 	if (err)
>@@ -1622,28 +1634,31 @@ mlxsw_sp_setup_tc_block_flower_bind(struct mlxsw_sp_port *mlxsw_sp_port,
> 	else
> 		mlxsw_sp_port->eg_acl_block = acl_block;
> 
>+	if (register_block) {
>+		flow_block_cb_add(block_cb, f);
>+		list_add_tail(&block_cb->driver_list, &mlxsw_sp_block_cb_list);
>+	}

What prevents you from doing these 2 above right after
flow_block_cb_alloc?

More than that, what prevents you do maintain the same flow as was there
originally? You just need struct flow_block as a replacement of
struct tcf_block and have it contained in both struct nft_base_chain
and struct tcf_block.

And you would push pointer to struct flow_block down to drivers
in struct flow_block_offload.


[...]