Received: by 2002:a25:ab43:0:0:0:0:0 with SMTP id u61csp1297006ybi; Thu, 30 May 2019 15:08:37 -0700 (PDT) X-Google-Smtp-Source: APXvYqwrOGZ0G8APPZ4wjJZHSQQT4cHYmkc5OoMnxa3N/xaJ7ls/JXrfwbLKuy/ofZN6hWB0VUbZ X-Received: by 2002:a65:4544:: with SMTP id x4mr5773185pgr.323.1559254117508; Thu, 30 May 2019 15:08:37 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1559254117; cv=none; d=google.com; s=arc-20160816; b=CXbBpkxPVciZ5wYBYE24FIRT5j8Xk4DTg6iRAewzzZBPPqKcia7On+VPfjsWiFeQmR EDEuh0dJAFYD5cAACGm2/ImE+v4xJG9mdJvrZUfZOrewkGXDMyhBkK5SOcvU76V7KiAE vPXT9ZSnRq/EGUvcFbfpapYUtAiLAH4rjvBXK5PVbl70ywjx7Rwq7zvtqwb+tmLEBF8U pqHXz59yGBALWXwVo4DVx8b7ZdORS1CZT8Qz0qA1TMuQtgZd5kqf8/Np3BQbGyglzNbK wZImSI56mwCCMVNGz5lB1DCmuuguQ4acHklxgroQSp90NFoRCwqyBdObEFPuvfhZjmJW eGpw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:mime-version :references:in-reply-to:from:subject:cc:to:message-id:date; bh=23s7fxE+1BpVtof2D5KLXxKs6X871dfaehQRzRMvi5A=; b=ghDYurcEAsHyKj60yTaym+0uSvYdnjdwbTjxzkiMsg1s1rrli8s+12VB/cY8ADwqkh 0C2DSXumz2L62nPiOaQBgmrtgRDMi+v5MPMzvqlJuhRpwIhPIxkTvprMoTVofnl4Bdow AiJ49xsirvvsJw7lW4wk74FMeGf0SQN638zjO98orBeteaFXA6J1JZxH2zw+4LzTZMR5 QwxpEW2p2Kc6vSSkzMAPBBkOulL/vRiih3nDiJs76z+C50Y0zObjeeMctknYlzjETCQC 2aA+3VK3+p4rTX2cJBFBpr0AGQ96zNqxFL/v6ZPhtxW3LhrmQriMkwDCCXeb4RIJq9m7 1HnQ== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id o4si4546322pfb.274.2019.05.30.15.08.21; Thu, 30 May 2019 15:08:37 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726676AbfE3WGA (ORCPT + 99 others); Thu, 30 May 2019 18:06:00 -0400 Received: from shards.monkeyblade.net ([23.128.96.9]:32942 "EHLO shards.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726328AbfE3WF7 (ORCPT ); Thu, 30 May 2019 18:05:59 -0400 Received: from localhost (unknown [IPv6:2601:601:9f80:35cd::3d5]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) (Authenticated sender: davem-davemloft) by shards.monkeyblade.net (Postfix) with ESMTPSA id EA57214DD36E9; Thu, 30 May 2019 15:05:58 -0700 (PDT) Date: Thu, 30 May 2019 15:05:58 -0700 (PDT) Message-Id: <20190530.150558.1424400488308311629.davem@davemloft.net> To: maxime.chevallier@bootlin.com Cc: pablo@netfilter.org, f.fainelli@gmail.com, jiri@mellanox.com, jakub.kicinski@netronome.com, netdev@vger.kernel.org, linux-kernel@vger.kernel.org, antoine.tenart@bootlin.com, thomas.petazzoni@bootlin.com Subject: Re: [PATCH net] ethtool: Check for vlan etype or vlan tci when parsing flow_rule From: David Miller In-Reply-To: <20190530140840.741-1-maxime.chevallier@bootlin.com> References: <20190530140840.741-1-maxime.chevallier@bootlin.com> X-Mailer: Mew version 6.8 on Emacs 26.1 Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.5.12 (shards.monkeyblade.net [149.20.54.216]); Thu, 30 May 2019 15:05:59 -0700 (PDT) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org From: Maxime Chevallier Date: Thu, 30 May 2019 16:08:40 +0200 > When parsing an ethtool flow spec to build a flow_rule, the code checks > if both the vlan etype and the vlan tci are specified by the user to add > a FLOW_DISSECTOR_KEY_VLAN match. > > However, when the user only specified a vlan etype or a vlan tci, this > check silently ignores these parameters. > > For example, the following rule : > > ethtool -N eth0 flow-type udp4 vlan 0x0010 action -1 loc 0 > > will result in no error being issued, but the equivalent rule will be > created and passed to the NIC driver : > > ethtool -N eth0 flow-type udp4 action -1 loc 0 > > In the end, neither the NIC driver using the rule nor the end user have > a way to know that these keys were dropped along the way, or that > incorrect parameters were entered. > > This kind of check should be left to either the driver, or the ethtool > flow spec layer. > > This commit makes so that ethtool parameters are forwarded as-is to the > NIC driver. > > Since none of the users of ethtool_rx_flow_rule_create are using the > VLAN dissector, I don't think this qualifies as a regression. > > Fixes: eca4205f9ec3 ("ethtool: add ethtool_rx_flow_spec to flow_rule structure translator") > Signed-off-by: Maxime Chevallier Applied, thank you.