From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from dpdk.org (dpdk.org [92.243.14.124]) by inbox.dpdk.org (Postfix) with ESMTP id ECE3EA046B for ; Wed, 21 Aug 2019 15:24:08 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id C1B181BEFD; Wed, 21 Aug 2019 15:24:08 +0200 (CEST) Received: from mga12.intel.com (mga12.intel.com [192.55.52.136]) by dpdk.org (Postfix) with ESMTP id BB42D1BEFD; Wed, 21 Aug 2019 15:24:06 +0200 (CEST) X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from fmsmga008.fm.intel.com ([10.253.24.58]) by fmsmga106.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 21 Aug 2019 06:24:05 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.64,412,1559545200"; d="scan'208";a="178501924" Received: from aburakov-mobl1.ger.corp.intel.com (HELO [10.237.220.108]) ([10.237.220.108]) by fmsmga008.fm.intel.com with ESMTP; 21 Aug 2019 06:24:04 -0700 To: Chaitanya Babu Talluri , dev@dpdk.org Cc: reshma.pattan@intel.com, jananeex.m.parthasarathy@intel.com, stable@dpdk.org References: <1566392575-7965-1-git-send-email-tallurix.chaitanya.babu@intel.com> <1566392575-7965-3-git-send-email-tallurix.chaitanya.babu@intel.com> From: "Burakov, Anatoly" Message-ID: Date: Wed, 21 Aug 2019 14:24:03 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.8.0 MIME-Version: 1.0 In-Reply-To: <1566392575-7965-3-git-send-email-tallurix.chaitanya.babu@intel.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Subject: Re: [dpdk-stable] [PATCH 2/3] lib/eal: fix vfio unmap that succeeds unexpectedly 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: , Errors-To: stable-bounces@dpdk.org Sender: "stable" On 21-Aug-19 2:02 PM, Chaitanya Babu Talluri wrote: > Un-map of page with valid virtual address and > another page's IOVA succeeds unexpectedly. > An entry in user_mem_maps can refer multiple pages. > Currently in such case to unmap single page, VA > and IOVA related to entry in user_mem_maps is > checked but not based on page (based on the > page size), this is the cause. > > The solution is that in find_user_mem_maps, > check whether user input iova is in relation with > input virtual address of the page which is to be > unmapped. The description could be clearer. Suggested rewording: Unmapping page with a VA that is found in the list of current mappings will succeed even if the IOVA for the chunk that is being unmapped, is mismatched. Fix it by checking if IOVA address matches the expected IOVA address exactly. -- Thanks, Anatoly