From mboxrd@z Thu Jan 1 00:00:00 1970
Return-Path: <stable-bounces@dpdk.org>
Received: from dpdk.org (dpdk.org [92.243.14.124])
by inbox.dpdk.org (Postfix) with ESMTP id 1B1F4A04C2
for <public@inbox.dpdk.org>; Fri, 15 Nov 2019 09:48:37 +0100 (CET)
Received: from [92.243.14.124] (localhost [127.0.0.1])
by dpdk.org (Postfix) with ESMTP id F37FA1F5;
Fri, 15 Nov 2019 09:48:36 +0100 (CET)
Received: from mail-wm1-f68.google.com (mail-wm1-f68.google.com
[209.85.128.68]) by dpdk.org (Postfix) with ESMTP id 71C2E1F5
for <stable@dpdk.org>; Fri, 15 Nov 2019 09:48:35 +0100 (CET)
Received: by mail-wm1-f68.google.com with SMTP id l1so8807627wme.2
for <stable@dpdk.org>; Fri, 15 Nov 2019 00:48:35 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=6wind.com; s=google;
h=date:from:to:cc:subject:message-id:references:mime-version
:content-disposition:in-reply-to:user-agent;
bh=LfvGbMzU9DZldDqisMIIB4aBvjNUJwOEB5vJg8wthvw=;
b=h1yx+wxqT6M77czXPS8LU5Twk9Ii+977yroaFDl2jjtK3jIov4SHPqrOv+joSs3DUP
aFaR2fS17m/ZRueuc6njwFb1xqELWqVRWnk13MpkjK449Pc0d+1NIagc/yq8sU33fhhX
N1MzDz8kwl0yF46du8gIxSAvdeVHzMxCcionlPXwMYBtHoAvgDukYfaKSSBbAbDMBkAj
O5A81lbkLpAIbPXeCF1y2hI87RfowY7jJgktFYufR+RQOtiMNYu1uveQdSI36y5YUa3c
5KfytC0i+hO8WPTRLFWcXOJ6+q0INZfqWmID78A9Z19d75OYMbrfDhGY/RisKgYZfum8
nJ0Q==
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:user-agent;
bh=LfvGbMzU9DZldDqisMIIB4aBvjNUJwOEB5vJg8wthvw=;
b=PCIYs37nTTbE5Ovt2r6OVYndhx1SWhl4pY2iOMQWYt5Kyx7i2iUlMtJ7FL8FWWfu6+
M8GqqEaxleOxqRuqOf3Xki3CRFME+MYYFKI6rSzI58tJzvtKyyJ+tLIX1sNJLXyxod3v
MSwhs/REZufZddhVJ7ENBeDGU2S32blK4mTw4kClgKgsWai9oYKFEaiLIr7e4Zv6hfiU
4q/pwrFTtALVC1k3p4Zg8G6bv/kIZf/pS2P0+Gi/PehYef74yBaxhFcvntTk+x5LrcN+
cgpOss2vqALTZqQUNxeFHhh9wNfCBent4IWDvH68bv7ocJkVpORdR4pL38YO88e05lfo
IPwg==
X-Gm-Message-State: APjAAAXEcCEYRsvxoTSSyDyCkrK8rvZ7T6Gayew9IPsNsWqWRYt+gZDB
wujR33VQyP5oHRfYIKEHmT4sIHUZOZU=
X-Google-Smtp-Source: APXvYqzjyH/lPKS6d2E+aKOqZ23H8TN6aAT0pJP6LJBBIrt1rndvWf48ciJg+vBpK9MzKupDAXrzVg==
X-Received: by 2002:a1c:9d4a:: with SMTP id g71mr14025936wme.66.1573807715206;
Fri, 15 Nov 2019 00:48:35 -0800 (PST)
Received: from 6wind.com (2a01cb0c0005a6000226b0fffeed02fc.ipv6.abo.wanadoo.fr.
[2a01:cb0c:5:a600:226:b0ff:feed:2fc])
by smtp.gmail.com with ESMTPSA id y17sm11014351wrs.58.2019.11.15.00.48.34
(version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
Fri, 15 Nov 2019 00:48:34 -0800 (PST)
Date: Fri, 15 Nov 2019 09:48:34 +0100
From: Olivier Matz <olivier.matz@6wind.com>
To: Anatoly Burakov <anatoly.burakov@intel.com>
Cc: dev@dpdk.org, Andrew Rybchenko <arybchenko@solarflare.com>,
david.marchand@redhat.com, stable@dpdk.org
Message-ID: <20191115084834.GG4841@platinum>
References: <825d02ef7f7b6ab65a36d9fa4719847228537384.1573739893.git.anatoly.burakov@intel.com>
<d541158e2c590c0d3e1a985e2bbea4c236da1f9f.1573739893.git.anatoly.burakov@intel.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <d541158e2c590c0d3e1a985e2bbea4c236da1f9f.1573739893.git.anatoly.burakov@intel.com>
User-Agent: Mutt/1.10.1 (2018-07-13)
Subject: Re: [dpdk-stable] [PATCH 2/2] mempool: remove check for bad IOVA
when populating
X-BeenThere: stable@dpdk.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: patches for DPDK stable branches <stable.dpdk.org>
List-Unsubscribe: <https://mails.dpdk.org/options/stable>,
<mailto:stable-request@dpdk.org?subject=unsubscribe>
List-Archive: <http://mails.dpdk.org/archives/stable/>
List-Post: <mailto:stable@dpdk.org>
List-Help: <mailto:stable-request@dpdk.org?subject=help>
List-Subscribe: <https://mails.dpdk.org/listinfo/stable>,
<mailto:stable-request@dpdk.org?subject=subscribe>
Errors-To: stable-bounces@dpdk.org
Sender: "stable" <stable-bounces@dpdk.org>
On Thu, Nov 14, 2019 at 01:58:21PM +0000, Anatoly Burakov wrote:
> Currently, mempool will check if IOVA is bad for a segment, and reject
> the IOVA if hugepages are also enabled. This check is wrong because now
> that we have external memory segments, they are allowed to have their
> IOVA's to be invalid. This check also doesn't make much sense in the
> first place, because the following code can handle bad IOVA's perfectly
> well (and in fact, this check is not triggering a failure when
> --no-huge option is enabled), so there is not much sense to check for
> this in the first place.
>
> Fixes: 950e8fb4e194 ("mem: allow registering external memory areas")
> Cc: stable@dpdk.org
>
> Signed-off-by: Anatoly Burakov <anatoly.burakov@intel.com>
Acked-by: Olivier Matz <olivier.matz@6wind.com>