From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wm0-f41.google.com (mail-wm0-f41.google.com [74.125.82.41]) by dpdk.org (Postfix) with ESMTP id 01E271D7 for ; Mon, 26 Feb 2018 10:32:02 +0100 (CET) Received: by mail-wm0-f41.google.com with SMTP id a20so16071111wmd.1 for ; Mon, 26 Feb 2018 01:32:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=6wind-com.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=yzMLve16Shwov0IGHWNmQ9fd7dOLZ4v4f9ZfxRSU6yc=; b=oymvyqe5mFsmrU7N1wF7oI4JqzO4Lvc5yv+lX3/YDeu/i7cQJpbsIa8em8QUxQeYsB oFufSUYLg0wq53Sb2KXEG1DYDjavxDuZzdLIn3kfvxwOcuYBcoqENIhUF8arCeHQErwe YS5l+gsV/BsArwHXfeONvHAFG+yhYNhrOmvZKmnNyb8aqE6MBberUkaaEhz15Wu0yqdo Nd7HoyJ31KeL2CF/X8SKV8UKgLSYJLQiRATthZkbIWK5KTTisIkUoGAMSsGkn0AOO435 pqyV9QnN7IO67QPmLcP4JBDJOZhHu4ac0osZE7KtVsxxHvVN8QRou/BJ0SGpc00z0IM9 Yfqw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=yzMLve16Shwov0IGHWNmQ9fd7dOLZ4v4f9ZfxRSU6yc=; b=jJB2QKoQb1E1Hm9EbY5qnsQAjmxFmCDewAybr6CnhbwXl1Z+VCX5wEsRLz+yCsxg1U ltK9tSY4q0cE3KBktkT9EZhMUttmK9E4RxdobuAj+LnjGp0AyY1rO4QEbCC0xRNXDril KIB1dgBFx9qn+NETmOjGCVmZm8wA59rS9PMPM8Kcr6pGc18/tg03K9B8Eg2MjbXpiNCa cDL4dgvo7M/hMQe3T0cRFFs1GVFU+fgqkJZ4CuwhXva+RLLDO7J/Q1DIEuc5y3icc6gI xn206M8D7N4rn0ZgTmQt0mS89Zo0+9Kn/MMzwaooxRz7CxUHR9rZms5LY2BB1YNx+dIS fv3g== X-Gm-Message-State: APf1xPAED6cLTV0IhtXsCxfRM/Bb++t6RYdgmlmRk3XlTsF2QoWi9lrH 0ownRcNfAGdSZ7LEOOqEOHXbpw== X-Google-Smtp-Source: AG47ELtMoOOVp6TpAwiL4oF3dbAZoekYI6I+pOL9YN0P9AKSol+WFWja2HLwUXgdewkXig1zukIo6w== X-Received: by 10.28.18.2 with SMTP id 2mr2771316wms.108.1519637522422; Mon, 26 Feb 2018 01:32:02 -0800 (PST) Received: from 6wind.com (host.78.145.23.62.rev.coltfrance.com. [62.23.145.78]) by smtp.gmail.com with ESMTPSA id 47sm7850965wrb.48.2018.02.26.01.32.01 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 26 Feb 2018 01:32:01 -0800 (PST) Date: Mon, 26 Feb 2018 10:31:48 +0100 From: Adrien Mazarguil To: Ophir Munk Cc: "dev@dpdk.org" , Thomas Monjalon , Olga Shern , "stable@dpdk.org" Message-ID: <20180226093148.GO4256@6wind.com> References: <1519220318-19328-1-git-send-email-ophirmu@mellanox.com> <20180223165239.GL4256@6wind.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Subject: Re: [dpdk-stable] [PATCH v1] net/mlx4: fix RSS actions with no parameters X-BeenThere: stable@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: patches for DPDK stable branches List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Feb 2018 09:32:03 -0000 On Sat, Feb 24, 2018 at 11:18:54PM +0000, Ophir Munk wrote: > Hi, > Please see below > > > -----Original Message----- > > From: Adrien Mazarguil [mailto:adrien.mazarguil@6wind.com] > > Sent: Friday, February 23, 2018 6:53 PM > > To: Ophir Munk > > Cc: dev@dpdk.org; Thomas Monjalon ; Olga Shern > > ; stable@dpdk.org > > Subject: Re: [PATCH v1] net/mlx4: fix RSS actions with no parameters > > > > On Wed, Feb 21, 2018 at 01:38:38PM +0000, Ophir Munk wrote: > > > When creating an RSS flow with missing actions parameters, for example: > > > flow create 0 ingress pattern / end actions rss / > > > end > > > > > > testpmd aborts with segmentation fault. > > > In the corrupted code mlx4_flow_prepare() accesses RSS action->conf > > > pointer without verifying its validity. > > > In case of missing RSS actions parameters this pointer is NULL and > > > must not be accessed. > > > > Problem is that testpmd is far from perfect and shouldn't feed PMDs with > > invalid pointers in the first place. The configuration structure is not > > documented as optional with actions that take one. > > > > > The fix is to return an error in such cases "missing rss actions". > > > > > > Fixes: 078b8b452e6b ("net/mlx4: add RSS flow rule action support") > > > Cc: stable@dpdk.org > > > > > > Signed-off-by: Ophir Munk > > > > I suggest to fix this at once for all present and future PMDs in testpmd > > directly. It may be added as a workaround in mlx4 but not as a fix since the > > cause is not in that PMD. > > > > I am not sure if missing rss queues in testpmd is not by design. For example a PMD can theoretically > interpreted it as an rss default action to split traffic over all existing device queues, or giving it any other meaning. > The lack of rss queues should be left to the interpretation of the PMD. No, the API must leave nothing open for interpretation, otherwise it's mis-defined or not properly documented and needs to be fixed. The accepted behavior to avoid a million unnecessary NULL checks is that pointers are valid unless stated otherwise (e.g. providing NULL parameters to memcpy() is undefined and will most likely cause a crash). Unlike item->{spec,last,mask} [1], action->conf [2] is not documented as optional for actions that require one. [1] http://dpdk.org/doc/guides/prog_guide/rte_flow.html#pattern-item [2] http://dpdk.org/doc/guides/prog_guide/rte_flow.html#actions > For example: > * ixgbe PMD seems to handle an NULL rss configuration pointer in its own way > * mlx5 PMD checks for this and return an error in such a case Because it's undefined behavior territory, however PMDs do not have to be nice when not required to. Keep in mind NULL checks are a waste of CPU cycles if not described by a given API; the role of catching programming mistakes should be left to assert() (for complex checks to avoid clutter ideally, since NULL-related crashes are easily debugged). > Changes to testpmd will have to be coordinated and accepted by all dpdk PMDs. Why? Testpmd implements APIs as described in order to validate PMDs and that's it. The fact it may feed them invalid pointers is its fault. > > > --- > > > drivers/net/mlx4/mlx4_flow.c | 4 ++++ > > > 1 file changed, 4 insertions(+) > > > > > > diff --git a/drivers/net/mlx4/mlx4_flow.c > > > b/drivers/net/mlx4/mlx4_flow.c index 2d55bfe..7a127a8 100644 > > > --- a/drivers/net/mlx4/mlx4_flow.c > > > +++ b/drivers/net/mlx4/mlx4_flow.c > > > @@ -735,6 +735,10 @@ mlx4_flow_prepare(struct priv *priv, > > > if (flow->rss) > > > break; > > > rss = action->conf; > > > + if (!rss) { > > > + msg = "missing rss actions"; > > > + goto exit_action_not_supported; > > > + } > > > > This message may be understood as a lack of RSS action, while it is in fact > > present. This error can be more accurately described as: > > > > "RSS action configuration wasn't provided" > > > > mlx5 PMD printout for missing rss queues is: "no valid queues" > > I suggest that both mlx4 and mlx5 print the same error for the same rss flow w/o queues. > Do you confirm using mlx5 message printed above? It's inexact, in this case the entire configuration structure (struct rte_flow_action_rss) is missing. Also, as described below, the same occurs with the QUEUE action, e.g.: testpmd> flow create 1 ingress pattern eth / end actions queue / end Segmentation fault Because testpmd can feed a NULL pointer for struct rte_flow_action_queue as well. In short, not providing a configuration on the testpmd command line makes it feed NULL pointers to PMDs. Since doing so is invalid, testpmd should not do it. Also I don't think it makes sense for a queue action to not provide a destination queue, same as a RSS action without configuration. > > Note the same issue exists with the QUEUE action handled just prior to this > > one and probably affects other PMDs as well. You really should consider > > fixing testpmd instead. -- Adrien Mazarguil 6WIND