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]
Date:   Mon, 8 Jul 2019 19:42:06 +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, netfilter-devel@...r.kernel.org
Subject: Re: [PATCH net-next,v3 07/11] net: sched: use flow block API

Mon, Jul 08, 2019 at 06:06:09PM CEST, pablo@...filter.org wrote:
>This patch adds tcf_block_setup() which uses the flow block API.
>
>This infrastructure takes the flow block callbacks coming from the
>driver and register/unregister to/from the cls_api core.
>
>Signed-off-by: Pablo Neira Ayuso <pablo@...filter.org>

[...]


>+static int tcf_block_bind(struct tcf_block *block,
>+			  struct flow_block_offload *bo)
>+{
>+	struct flow_block_cb *block_cb, *next;
>+	int err, i = 0;
>+
>+	list_for_each_entry(block_cb, &bo->cb_list, driver_list) {
>+		err = tcf_block_playback_offloads(block, block_cb->cb,
>+						  block_cb->cb_priv, true,
>+						  tcf_block_offload_in_use(block),
>+						  bo->extack);
>+		if (err)
>+			goto err_unroll;
>+
>+		list_add(&block_cb->list, &block->cb_list);
>+		i++;
>+	}
>+	list_splice(&bo->cb_list, bo->driver_block_list);

This cl/driver_block list magic is really very hard to follow. Could you
please make it more clear?



>+
>+	return 0;
>+
>+err_unroll:
>+	list_for_each_entry_safe(block_cb, next, &bo->cb_list, driver_list) {
>+		if (i-- > 0) {
>+			list_del(&block_cb->list);
>+			tcf_block_playback_offloads(block, block_cb->cb,
>+						    block_cb->cb_priv, false,
>+						    tcf_block_offload_in_use(block),
>+						    NULL);
>+		}
>+		flow_block_cb_free(block_cb);
>+	}
>+
>+	return err;
>+}
>+
>+static void tcf_block_unbind(struct tcf_block *block,
>+			     struct flow_block_offload *bo)
>+{
>+	struct flow_block_cb *block_cb, *next;
>+
>+	list_for_each_entry_safe(block_cb, next, &bo->cb_list, driver_list) {
>+		list_del(&block_cb->driver_list);
>+		tcf_block_playback_offloads(block, block_cb->cb,
>+					    block_cb->cb_priv, false,
>+					    tcf_block_offload_in_use(block),
>+					    NULL);
>+		list_del(&block_cb->list);
>+		flow_block_cb_free(block_cb);
>+	}
>+}

[...]

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ