[dpdk-dev] [PATCH v2] net/tap: fix promiscuous rules double insersions

[Ophir Munk]

Hi,
Regarding your question:
> Are we sure the previous rule is still in the registered implicit flows?

It is confirmed. 

After running several "port stop/start" commands in testpmd I am executing 
testpmd> flow isolate <port id> 1 
and notice that promiscuous rule is removed from remote device.

Regards,
Ophir

> -----Original Message-----
> From: Ophir Munk
> Sent: Wednesday, February 14, 2018 1:24 PM
> To: 'Pascal Mazon' <pascal.mazon at 6wind.com>; dev at dpdk.org
> Cc: Thomas Monjalon <thomas at monjalon.net>; Olga Shern
> <olgas at mellanox.com>; stable at dpdk.org
> Subject: RE: [PATCH v2] net/tap: fix promiscuous rules double insersions
> 
> Please see inline.
> I will send updated v3
> 
> > -----Original Message-----
> > From: Pascal Mazon [mailto:pascal.mazon at 6wind.com]
> > Sent: Wednesday, February 14, 2018 10:51 AM
> > To: Ophir Munk <ophirmu at mellanox.com>; dev at dpdk.org
> > Cc: Thomas Monjalon <thomas at monjalon.net>; Olga Shern
> > <olgas at mellanox.com>; stable at dpdk.org
> > Subject: Re: [PATCH v2] net/tap: fix promiscuous rules double
> > insersions
> >
> > Hi Ophir,
> >
> > Typo in title: s/insersions/insertions/
> >
> 
> Fixed in v3
> 
> > I'm ok on principle, I have just a few comments inline.
> >
> > Regards,
> > Pascal
> >
> > On 13/02/2018 19:35, Ophir Munk wrote:
> > > Running testpmd command "port stop all" followed by command "port
> > > start all" may result in a TAP error:
> > > PMD: Kernel refused TC filter rule creation (17): File exists
> > >
> > > Root cause analysis: during the execution of "port start all"
> > > command testpmd calls rte_eth_promiscuous_enable() while during the
> > > execution of "port stop all" command testpmd does not call
> > > rte_eth_promiscuous_enable().
> > Shouldn't it be rte_eth_promiscuous_disable()?
> 
> Yes it should. Fixed in v3
> 
> > > As a result the TAP PMD is trying to add tc (traffic control
> > > command) promiscuous rules to the remote netvsc device
> > > consecutively. From the kernel point of view it is seen as an
> > > attempt to add the same rule more than once. In recent kernels (e.g.
> > > version 4.13) this attempt is rejected with a "File exists" error. In less
> recent kernels (e.g.
> > > version 4.4) the same rule may have been accepted twice
> > > successfully,
> > which is undesirable.
> > >
> > > In the corrupted code every tc promiscuous rule included a different
> > > handle number parameter. If instead an identical handle number
> > > parameter is used for all tc promiscuous rules - all kernels will
> > > reject the second rule with a "File exists" error, which is easy to
> > > identify and to silently ignore.
> > >
> > > Fixes: 2bc06869cd94 ("net/tap: add remote netdevice traffic
> > > capture")
> > > Cc: stable at dpdk.org
> > >
> > > Signed-off-by: Ophir Munk <ophirmu at mellanox.com>
> > > ---
> > > v2: add detailed commit message
> > >
> > >  drivers/net/tap/tap_flow.c | 11 +++++++++++
> > >  1 file changed, 11 insertions(+)
> > >
> > > diff --git a/drivers/net/tap/tap_flow.c b/drivers/net/tap/tap_flow.c
> > > index 65657f0..d1f4a52 100644
> > > --- a/drivers/net/tap/tap_flow.c
> > > +++ b/drivers/net/tap/tap_flow.c
> > > @@ -123,6 +123,7 @@ enum key_status_e {  };
> > >
> > >  #define ISOLATE_HANDLE 1
> > > +#define REMOTE_PROMISCUOUS_HANDLE 2
> > >
> > >  struct rte_flow {
> > >  	LIST_ENTRY(rte_flow) next; /* Pointer to the next rte_flow
> > > structure */ @@ -1692,9 +1693,15 @@ int
> > > tap_flow_implicit_create(struct
> > pmd_internals *pmd,
> > >  	 * The ISOLATE rule is always present and must have a static
> > > handle,
> > as
> > >  	 * the action is changed whether the feature is enabled (DROP) or
> > >  	 * disabled (PASSTHRU).
> > > +	 * There is just one REMOTE_PROMISCUOUS rule in all cases. It
> > should
> > > +	 * have a static handle such that adding it twice will fail with EEXIST
> > > +	 * with any kernel version. Remark: old kernels may falsely accept the
> > > +	 * same REMOTE_PREMISCUOUS rules if they had different handles.
> > s/PREMISCUOUS/PROMISCUOUS/
> > >  	 */
> > >  	if (idx == TAP_ISOLATE)
> > >  		remote_flow->msg.t.tcm_handle = ISOLATE_HANDLE;
> > > +	else if (idx == TAP_REMOTE_PROMISC)
> > > +		remote_flow->msg.t.tcm_handle =
> > REMOTE_PROMISCUOUS_HANDLE;
> > >  	else
> > >  		tap_flow_set_handle(remote_flow);
> > >  	if (priv_flow_process(pmd, attr, items, actions, NULL, @@ -1709,12
> > > +1716,16 @@ int tap_flow_implicit_create(struct pmd_internals *pmd,
> > >  	}
> > >  	err = tap_nl_recv_ack(pmd->nlsk_fd);
> > >  	if (err < 0) {
> > > +		/* Silently ignore re-entering remote promiscuous rule */
> > > +		if (errno == EEXIST && idx == TAP_REMOTE_PROMISC)
> > > +			goto success;
> > >  		RTE_LOG(ERR, PMD,
> > >  			"Kernel refused TC filter rule creation (%d): %s\n",
> > >  			errno, strerror(errno));
> > >  		goto fail;
> > >  	}
> > >  	LIST_INSERT_HEAD(&pmd->implicit_flows, remote_flow, next);
> > Are we sure the previous rule is still in the registered implicit flows?
> 
> I will run tests to verify that.
> 
> > > +success:
> > >  	return 0;
> > >  fail:
> > >  	if (remote_flow)