From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wr0-f175.google.com (mail-wr0-f175.google.com [209.85.128.175]) by dpdk.org (Postfix) with ESMTP id EB5FC9E3 for ; Fri, 31 Mar 2017 15:44:34 +0200 (CEST) Received: by mail-wr0-f175.google.com with SMTP id w43so106640626wrb.0 for ; Fri, 31 Mar 2017 06:44:34 -0700 (PDT) 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:in-reply-to:references :mime-version:content-transfer-encoding; bh=a+sdhn5SN2UW0ZOA73cczCmryW0r1YwTPPT+HjLjma8=; b=UINBjlNFMUyqI7BBKjJtFYVbC/6c7pnawPmpjCEQzzBr7SwA2jbPDdVtlXfNNJ9QHA KnmYUKfS/RmnRmzjBT+eQlavR2+k4ke46yPJmUHlpj/pDiLOTjM/fNNaj6hreGPxV+bk vAHo7eDqNcW7c7yM8ehX1RtticozaR3qkJOS1+Il5xhJHBEmYKP622tvgP/s5FradaB0 9eBBf9oHE48QwSG15jLF0Cft/6HuTKenD2xv08vXQCqUuMWYHOHXDm4vvnAws+78I5CZ 0RqYwH9/uy/L0/0ZiurT1frXsrWdJ+DPXIZC83ODf7Tc+N5tBvmBcwNPMUFuoZYAKNpS O+8A== 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=a+sdhn5SN2UW0ZOA73cczCmryW0r1YwTPPT+HjLjma8=; b=Bd9AWM5M+gxYBw3zuen3+1iTCLw2ywye8wUFcIeRzCLALtS9HBJpM5buJg0Nym9P3D G8PPAY8rxecLmYFLjRF6wq2w8KrlKA7+xCSidXhMzEPNfS/U6SQGwHkzpkSbz6i7y1h1 NTF6W3TryGFHCpg51g68a/Fg4LR/TUDSDOKSljeUlOiQvvQNei+ZktkTohiz56E+3qnC HI2Db2EAxAZHx+X1NN61NS2frG1uMK7J4VBQqVXbUkqGGB3LzQWtD5U6BB/6AHAjBLmP js7Ktu5O7wLYmXOaODT7hRaaT/Xhjbp1UuiV2HzHdCs26s/6RfOw9ngXf9h5B4SK8ybT icVA== X-Gm-Message-State: AFeK/H0JbUcV2yQMG/4WPrhDWU1LZ0hys48qbUgRWVrtqIWETaqDrcBbl+7axqmGpvnCR3Hz X-Received: by 10.28.69.72 with SMTP id s69mr3442639wma.85.1490967874574; Fri, 31 Mar 2017 06:44:34 -0700 (PDT) Received: from platinum (2a01cb0c03c651000226b0fffeed02fc.ipv6.abo.wanadoo.fr. [2a01:cb0c:3c6:5100:226:b0ff:feed:2fc]) by smtp.gmail.com with ESMTPSA id p38sm6809221wrb.31.2017.03.31.06.44.34 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Fri, 31 Mar 2017 06:44:34 -0700 (PDT) Date: Fri, 31 Mar 2017 15:44:31 +0200 From: Olivier Matz To: Shreyansh Jain Cc: , , , Message-ID: <20170331154431.61fb0793@platinum> In-Reply-To: <3b7b65f5-aa8b-fa4a-de8e-8458ec78ce87@nxp.com> References: <11490938158-936-1-git-send-email-shreyansh.jain@nxp.com> <1490938537-1177-1-git-send-email-shreyansh.jain@nxp.com> <3b7b65f5-aa8b-fa4a-de8e-8458ec78ce87@nxp.com> X-Mailer: Claws Mail 3.14.1 (GTK+ 2.24.31; x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Subject: Re: [dpdk-dev] [PATCH v3 1/3] mempool: fix segfault when shared mempool handler not linked 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: Fri, 31 Mar 2017 13:44:35 -0000 Hi Shreyansh, On Fri, 31 Mar 2017 11:11:19 +0530, Shreyansh Jain wrote: > On Friday 31 March 2017 11:05 AM, Shreyansh Jain wrote: > > Fixes: 449c49b93a6b ("mempool: support handler operations") > > > > In case the stack or ring mempool handler are compiled as shared > > library and not linked in with test binary, segfault is reported. > > This is because return value of rte_mempool_set_ops_byname is not > > being checked in rte_mempool_ops_alloc. > > > > This patch handles error returned from rte_mempool_set_ops_byname > > when a mempool is not found. > > > > Signed-off-by: Shreyansh Jain > > --- > > $ devtools/check-git-log.sh > Is it candidate for Cc: stable@dpdk.org backport? > mempool: fix segfault when shared mempool handler not linked > > I am not sure this needs to be in stable. Previous versions never had > an external mempool handler and ring/stack are statically linked in > always. > Though, if a new handler is added (out of tree) over 16.11, and somehow > and application requests for it without linking the library, this > segfault would occur. > > Any suggestions? > > And just to add to this patch, this segfault is in 'test' binary. It may > not necessarily be the case for other application if they are > handling the error well. > I think it's not needed to backport in stable. As you said, the crash cannot occur because ring handler is always registered (it's part of the same mempool lib). Thanks, Olivier