From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pf1-f194.google.com (mail-pf1-f194.google.com [209.85.210.194]) by dpdk.org (Postfix) with ESMTP id 4DDB014EC for ; Wed, 7 Nov 2018 19:15:05 +0100 (CET) Received: by mail-pf1-f194.google.com with SMTP id j13-v6so8028712pff.11 for ; Wed, 07 Nov 2018 10:15:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=networkplumber-org.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:subject:message-id:in-reply-to:references :mime-version:content-transfer-encoding; bh=9MoRb8bBGrZ61q43uxWCnJWcioye5054uC+J3x6udu4=; b=SMwULYyBqF/TDMdwn+YROggdVtNj8s4aM5hjbgxZyaMD+RDq8WJsN2K6/KrPNSVITb oYJC3omV3xNQ5JXwLhw63Mkg7XIoVG1xnTmSMcijyUGeHigU18lK5LMYGjrgWlDXjthh EiOH+EIo6+Ts9aDdnR6N1C8wKs03++FBYxDUs7uP5LiacZkSkapxTK/JL0BvCCuAyGyH ViTWFdYfrfErPc0uHFq/forBWfVRI0MFdMgLptE1eISzEdcTMfxXOk8+JWN7rZHqrQ3b +QpSWF5T3rL/yVW8CGzfyaoRFVHrRgu3mlqK1S2/tGFaHMAunejy9w2yvz5Fl8Ozauq/ lHrA== 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:in-reply-to :references:mime-version:content-transfer-encoding; bh=9MoRb8bBGrZ61q43uxWCnJWcioye5054uC+J3x6udu4=; b=i6PoX7rxe3mr3kAexuXW4Mlb+eE3ehfI2nx/MHmP+diQwNFDKagln2hK8rWaQ4DmaO DWLWSHzjRhcvTUwbRBzSvj7y8WbbX5UDBDbMbbmVVKWJ1Jy3EQ9oS1zIXRO1FcpRHJOD aRg7ZUNIgNdSBFzcEL7O1/oNAF793F8H/rC3NfgKHehmp2y4OeyCgwv3mYRw779s/Y20 lAq4S0aviH40mlUE7FZROlGbIA6bvNiWTLNNEwOhaP3mR7mHAVmCmqvEQ5DUeRO4dYX8 jYNAxugkS5RWEtL2xgq9mOaUhOTFw9UWVORUADcNkdPGNAq9fwJD/AzTtJ+lmh2v1xVE ao5g== X-Gm-Message-State: AGRZ1gIaPM2YeREU25d5e3XKfg/RK8+bFd3klJA0OtlunG2mzvwuqm8m MmazNaf/oJaUnUBOl4tCRL3EksJytzs= X-Google-Smtp-Source: AJdET5etoEGqujd2nb9MRm8Vm6b6EqPeR6p1wEQpHX+w86idMfDV8OxMdxL9P1FsG5u8iVV6Lo7T9Q== X-Received: by 2002:a63:eb42:: with SMTP id b2-v6mr1037684pgk.348.1541614504317; Wed, 07 Nov 2018 10:15:04 -0800 (PST) Received: from shemminger-XPS-13-9360 ([167.220.60.43]) by smtp.gmail.com with ESMTPSA id x123-v6sm1425735pfb.124.2018.11.07.10.15.04 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Wed, 07 Nov 2018 10:15:04 -0800 (PST) Date: Wed, 7 Nov 2018 10:15:02 -0800 From: Stephen Hemminger To: Andrew Rybchenko Cc: Message-ID: <20181107101502.2cbaffde@shemminger-XPS-13-9360> In-Reply-To: <5d2c4750-b418-c4fe-4e20-d7cc7ca4efe7@solarflare.com> References: <20181106193005.5383-1-stephen@networkplumber.org> <20181106193005.5383-2-stephen@networkplumber.org> <5d2c4750-b418-c4fe-4e20-d7cc7ca4efe7@solarflare.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Subject: Re: [dpdk-dev] [PATCH 1/4] net/failsafe: avoid rte_memcpy if rte_realloc fails X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Nov 2018 18:15:05 -0000 On Wed, 7 Nov 2018 09:30:13 +0300 Andrew Rybchenko wrote: > On 11/6/18 10:30 PM, Stephen Hemminger wrote: > > There is a potential issue seen by static tools if number of multicast > > addresses is zero, and rte_realloc of zero size fails (ie returns NULL). > > This won't happen in real world for a couple of reasons: Azure doesn't > > support multicast (ie this is dead code); > > Is it guaranteed that Azure is the only user of the code? > Sorry, it does not sound like an argument at all. There are no guarantees in life... Failsafe in DPDK is probably only useful with Azure. AWS, GCP, and other clouds handle virtual networking differently. There has been some talk of doing similar things with KVM, but the device model is different there. Failsafe makes some assumptions about device layering that are specific to Azure. It also has some generalizations about cases that will never matter. Vdev_netvsc is definitely Azure specific. It will be deprecated once netvsc PMD is more widely supported. > > > and rte_realloc of zero size > > will never fail, but safe to just always return -ENOMEM of realloc fails. > > It is false statement. If ptr is NULL, rte_malloc() is used which explicitly > returns NULL if size is 0. > > > Coverity issue: 323487 > > It is 100% false alarm from Coverity. rte_memcpy() does nothing > if size is 0 and it is zero if number of addresses is zero. > If we really want to cope with it (I'm not sure), just do rte_memcpy() > in else branch. And it should explained in the comment that it is > required to address false issue from static analysis tool only. > > Other option is to add check for dummy set (zero number of addresses > when it is already zero, but it is extra lines of code and extra logic which > is not actually required here. So, more harm from my point of view. We are in agreement, it is a false alarm because: * Coverity assumes that memcpy and rte_memcpy have same semantics. * the case can't never happen Any solution is fine because of that. You could flag it as false in Coverity or change code to avoid warning. Just want to get it fixed, don't care how.