netdev - Re: [patch net-next v3 05/10] net: sched: keep track of offloaded filters and check tc offload feature

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: <20171214104941.2f051af1@cakuba.netronome.com>
Date:   Thu, 14 Dec 2017 10:49:41 -0800
From:   Jakub Kicinski <jakub.kicinski@...ronome.com>
To:     Jiri Pirko <jiri@...nulli.us>
Cc:     netdev@...r.kernel.org, davem@...emloft.net, jhs@...atatu.com,
        xiyou.wangcong@...il.com, mlxsw@...lanox.com, andrew@...n.ch,
        vivien.didelot@...oirfairelinux.com, f.fainelli@...il.com,
        michael.chan@...adcom.com, ganeshgr@...lsio.com,
        saeedm@...lanox.com, matanb@...lanox.com, leonro@...lanox.com,
        idosch@...lanox.com, simon.horman@...ronome.com,
        pieter.jansenvanvuuren@...ronome.com, john.hurley@...ronome.com,
        alexander.h.duyck@...el.com, ogerlitz@...lanox.com,
        john.fastabend@...il.com, daniel@...earbox.net
Subject: Re: [patch net-next v3 05/10] net: sched: keep track of offloaded
 filters and check tc offload feature

On Thu, 14 Dec 2017 14:10:45 +0100, Jiri Pirko wrote:
> >Why? Just a namechange?
> >
> >  
> >>IIUC the problem is we don't know whether the driver/callee of the new
> >>port is aware of previous callbacks/filters and we can't replay them.  
> 
> Well, the problem is a bit different.
> There are 2 scenarios when we need to fail here:
> 1) tc offload feature is turned off, there are some filters offloaded in
>    the block. That is what I commented above.
> 2) tc offload feature is turned on, there are some filters offloaded in
>    the block but the block is not accounted by the driver. This is
>    because of the lack or replay. This is taken care of in the beginning
>    of __tcf_block_cb_register function - see below, there is a comment
>    there.

Restating in code terms, shouldn't this:

+	tcf_block_offload_cmd(block, dev, ei, TC_BLOCK_BIND);
+	return 0;

return the error like this:

	return tcf_block_offload_cmd(block, dev, ei, TC_BLOCK_BIND);

We expect simple drivers to do this:

	case TC_BLOCK_BIND:
		return tcf_block_cb_register(f->block, mycb,
					     priv, priv);

Which will return an error for shared offloaded block, just need to
propagate it.